#php

Jacob Paris Your headers are being added twice. When this happens they get merged together and that's probably creating an invalid final value. I'm guessing you've tried to configure the same CORS setup in both Laravel and in Nginx/OpenResty. Removing one of these should fix it When you check your request in the network tab of your browser, you want to see these headers and no duplicates ``` Access-Control-Allow-Origin: https://elkj-pos.vercel.app Access-Control-Allow-Credentials: true ``` Alternatively: the easiest way to get around CORS is to not make any cross-origin requests in the first place. - If you're using a full stack framework like Next.js, you can route your requests through the same-origin Next.js backend toward your API. This might feel like an extra step, but server -> server requests are much faster than client -> server as they're between (or within) datacenters. - You could also use proxy rewrites to route traffic from your app domain to your Laravel Server. We use this to mix Next.js pages into the Discourse platform on this website. https://vercel.com/blog/how-we-run-vercels-cdn-in-front-of-discourse#vercel-as-a-cdn Both of those solutions mean your website is only ever sending requests to its own domain, which eliminates CORS and allows you to use more secure authentication methods like HttpOnly SameSite cookies.

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.

Josh Dunsterville Hey there @ranjeet-techimoin! I'm like 99% sure that Vercel doesn't support php execution. You could still host your fronted on vercel, but you'd need to host Laravel elsewhere. I don't have any direct experience with these, but have heard good things about fly .io and railway.

Pauline P. Narvas We do have this supported by the community: https://community.vercel.com/t/vercel-php/31428?u=pawlean

elnadar @ranjeet-techimoin of course you can use, see https://github.com/vercel-community/php