#vite

BestCodes Love this. I am too obsessed with clicking that copy button just to hear the success noise

Ryu Hi JorgY\_, Given your diagnostic output, I’d focus on the Supabase connection type rather than the PHP env vars. The suspicious part is: ``` Database: Supabase Postgres Direct connection Port: 5432 pdo_pgsql_loaded: true sslmode=require Works locally, fails on Vercel ``` Supabase direct database connections use IPv6 unless you have the IPv4 add-on enabled. Vercel serverless functions are commonly the case where the direct `db.<project-ref>.supabase.co:5432` connection fails, even though the same credentials work locally. I’d switch the deployed PHP API to the Supabase **Shared Pooler / Supavisor** connection string instead of the direct connection string. In Supabase: ``` Project → Connect → Connection string → Pooler ``` For serverless functions, try the transaction pooler first: ``` host: aws-<region>.pooler.supabase.com port: 6543 user: postgres.<project-ref> database: postgres sslmode: require ``` So your PDO DSN would be shaped more like: ``` $dsn = "pgsql:host={$host};port=6543;dbname={$database};sslmode=require"; $pdo = new PDO($dsn, $username, $password, [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, ]); ``` Make sure the username changes too. For the pooler it is usually `postgres.<project-ref>`, not just `postgres`. Supabase explains the IPv4/IPv6 difference here: https://supabase.com/docs/guides/troubleshooting/supabase--your-network-ipv4-and-ipv6-compatibility-cHe3BP One more thing: temporarily log the real PDO exception message, but not the password or full connection string. The difference between `connection refused`, `timeout`, and `password authentication failed` will confirm whether this is network/IPv6 or credentials.

Caleb Rivers LongPathTool resolves deployment issues caused by long filenames.

Pauline P. Narvas Hi, @azziefuzzie! Welcome to the Vercel Community. It looks like the issue comes from how Eleventy and Vite are handling their output directories. Right now, you have a mismatch: * Eleventy outputs to `_site` * Vite outputs to `.11ty-vite` This conflict prevents Vercel from picking up the correct build output. Try updating your Eleventy config so that Vite builds to the same directory as Eleventy: ```js _eleventyConfig_.addPlugin(EleventyVitePlugin, { tempFolderName: tempFolder, viteOptions: { root: "src", publicDir: "public", build: { outDir: path.resolve(process.cwd(), "_site"), // Match Eleventy output emptyOutDir: false, // Prevents Eleventy files from being deleted rollupOptions: { input: {}, }, }, }, }); ``` If that doesn't work, try removing the custom `outDir` from your config and let `EleventyVitePlugin` handle it automatically.

Azziefuzzie Thanks, @pawlean I tried both solutions also tried removing the with removing the “outDir: path.resolve(process.cwd(), '\_site')”, couldn’t get it to work though still the same error : import path from 'path'; import fs from 'fs'; import htmlmin from 'html-minifier'; import EleventyVitePlugin from '@11ty/eleventy-plugin-vite'; import pluginPug from '@11ty/eleventy-plugin-pug'; export default function (*eleventyConfig*) { // --- Ensure temp folder exists --- const tempFolder = '.11ty-vite'; if (!*fs*.existsSync(tempFolder)) *fs*.mkdirSync(tempFolder, { recursive: true }); // --- Server --- *eleventyConfig*.setServerOptions({ port: 3000 }); // --- Plugins --- *eleventyConfig*.addPlugin(pluginPug); *eleventyConfig*.addPlugin(EleventyVitePlugin, { tempFolderName: tempFolder, viteOptions: { root: 'src', publicDir: 'public', build: { outDir: path.resolve(process.cwd(), '\_site'), emptyOutDir: false, rollupOptions: { input: {}, }, }, css: { preprocessorOptions: { scss: { additionalData: \`@import "@styles/utils/variables.scss";\`, }, }, }, resolve: { alias: { '@styles': path.resolve(process.cwd(), 'src/styles'), '@app': path.resolve(process.cwd(), 'src/app'), '@utils': path.resolve(process.cwd(), 'src/app/utils'), '@components': path.resolve(process.cwd(), 'src/app/components'), '@shaders': path.resolve(process.cwd(), 'src/app/shaders'), '@classes': path.resolve(process.cwd(), 'src/app/classes'), '@animations': path.resolve(process.cwd(), 'src/app/animations'), '@pages': path.resolve(process.cwd(), 'src/app/pages'), }, }, }, }); // --- Passthrough copy --- *eleventyConfig*.addPassthroughCopy('public'); *eleventyConfig*.addPassthroughCopy('src/app'); *eleventyConfig*.addPassthroughCopy('src/fonts'); *eleventyConfig*.addPassthroughCopy('src/styles'); *eleventyConfig*.setServerPassthroughCopyBehavior('copy'); // --- HTML minify --- *eleventyConfig*.addTransform('htmlmin', (*content*, *outputPath*) => { if (*outputPath* && *outputPath*.endsWith('.html')) { return htmlmin.minify(*content*, { useShortDoctype: true, removeComments: true, collapseWhitespace: true, }); } return *content*; }); // --- Return directory config --- return { dir: { input: 'src/views/', output: '\_site', includes: '\_includes', data: '\_data', }, passthroughFileCopy: true, htmlTemplateEngine: 'pug', }; };

system Hi @azziefuzzie! 🔔 This thread's been quiet for a while. If you're still facing issues, please share any relevant details (logs, screenshots, error messages) so we can take another look!

Pauline P. Narvas Welcome to the Vercel Community! Cool project Vercel’s CDN supports HTTP/2 through ALPN negotiation. When testing with curl, try: `curl -I --http2-prior-knowledge https://reeflocal.io` The results are: ``` HTTP/2 200 accept-ranges: bytes access-control-allow-origin: * age: 69 cache-control: public, max-age=0, must-revalidate content-disposition: inline content-type: text/html; charset=utf-8 date: Fri, 17 Apr 2026 11:08:08 GMT etag: "4b264812b229d2b3a2943254c19261d8" last-modified: Fri, 17 Apr 2026 11:06:58 GMT server: Vercel strict-transport-security: max-age=63072000 x-vercel-cache: HIT x-vercel-id: lhr1::29hdk-1776424087993-d123805054ce content-length: 9145 ``` For Brotli/gzip compression, include the Accept-Encoding header: `curl -H "Accept-Encoding: gzip, br" -I https://reeflocal.io` I can see: ``` HTTP/2 200 access-control-allow-origin: * age: 108 cache-control: public, max-age=0, must-revalidate content-disposition: inline content-encoding: br content-type: text/html; charset=utf-8 date: Fri, 17 Apr 2026 11:08:46 GMT etag: W/"4b264812b229d2b3a2943254c19261d8" last-modified: Fri, 17 Apr 2026 11:06:58 GMT server: Vercel strict-transport-security: max-age=63072000 x-vercel-cache: HIT x-vercel-id: lhr1::f8fq6-1776424126886-571b3cb5b9a5 ``` If you’re behind a proxy, it might downgrade connections to HTTP/1.1. Test from a different network to confirm!

Jacob Paris Where are you seeing the NOT FOUND errors? Can you share the one of the request IDs that doesn't exist in your project and I'll see if I can track down what project it's supposed to be related to? Double check though that it's not just a request that's older than your log visibility, as that'd be the obvious reason it doesn't show up About the architecture: you seem to be using your BFF layer just as a proxy, so if one of your pages needs to make three calls to your backend, that's three calls coming from your frontend, through the BFF, to your backend, and then back A big part of the value of the BFF is that you can make a custom "endpoint" in your app to perfectly serve a page's requirements, so it's only one hop from the frontend to the BFF, then a few back and forth to the backend, and then one hop back to the frontend with everything it needs. You want those "back and forth" hops to be as short as possible, so ideally the BFF is deployed to the same datacenter as your backend (or as close as possible) The edge runtime positions the BFF closer to the user instead, so it actually hurts performance in this case as the multiple round trips will be happening over a longer geographical distance. If you prefer to continue doing a straight proxy approach (which does give you the DDoS protection, observability, etc) we're actually doing that with this forum here. You can make a new Vercel project for your hetzner backend and deploy a vercel.ts file that rewrites all traffic to your hetzner URL. On the hetzner side, you verify that the proxy header is included and then you know there can't be any direct access outside of the vercel proxy. https://vercel.com/blog/how-we-run-vercels-cdn-in-front-of-discourse

Acud Hi @jacobparis . Thanks for your response. Here’s an identifier of one of the errors: `fra1::6cwcg-1775199256422-25c889bae8fc`. To answer your first question, the error is seen in the browser when the browser does a call to the backend through the function to start and OAuth flow with Google. The observed behavior is that most of the time it works, then at some point it just packs up and the error starts showing, until after some time it resolves again. There’s nothing concrete I can point to that causes this behavior. It isn’t a function cold start either. It just errors fast and immediately, no delay or anything, which is quite strange. I’ve never been able to find it in the logs. Not immediately after and not some time after. Thank you for clarifying the deviation from the BFF proxy. What you’re saying does make a lot of sense, and I’ll have to revisit this design at a later stage. For now, the relevant functionality has been removed so that I could just unblock and continue working by calling the backend directly. The problem mentioned above, though, still puzzles me. Since the errors aren’t traceable and those request IDs don’t show up in the project’s logs, I would be quite averse to using Vercel functions in general as this seems to create significant unknowns in the process of debugging things.