Earlier today, after your own security advisory about env var exposure, I started rotating all my secrets. One of those rotations touched my Postgres connection, which is managed by the Vercel Neon Marketplace integration. The rotation itself succeeded on the Neon side. The password updated, the new credential worked when I tested it directly against Neon. What your integration did, however, was break production. The Neon integration stores the target database name on the Vercel side at install time. That stored value was “hindsight”, because at some point in the past I had two databases in the same Neon project, “neondb” for the app and “hindsight” for a memory service. When the integration re-injected env vars during the rotation flow, it used that cached database name. So every new POSTGRES_URL that got pushed to production was pointing at …/hindsight?.. even though my application reads and writes to neondb. My site immediately went down with password authentication failures and then database does not exist errors. WHAT I DID TO TRY TO FIX IT I manually overrode POSTGRES_URL at the Vercel project level, pointing it at the correct database. This got the site back online as a band aid. To eliminate the root cause, I migrated the hindsight database out of the main Neon project into a completely separate Neon project. This was a full pg_dump, pg_restore of roughly 700k rows, every index, every foreign key, every extension (pgvector, pg_trgm). I verified row counts match. I pointed my Hindsight service at the new isolated project. That service is healthy on the new database. I then dropped the hindsight database from the original Neon project. Now the only database that exists there is neondb. I verified via SQL: “SELECT datname FROM pg_database” returns only neondb and postgres. I disconnected the Vercel Neon integration from my project, then reconnected it. My expectation was that during reconnect it would detect that only neondb exists and target that. After reconnect, the integration STILL injected POSTGRES_DATABASE=hindsight and POSTGRES_URL=…/hindsight?.. Vercel is caching a database name that literally no longer exists on the provider side. WHAT I HAVE SEARCHED FOR ON YOUR SIDE Storage tab. No editable target database field on the Neon resource page. Integrations page. No database selector. Reconnect dialog. Shows Environments, Required toggle, Create Database Branch checkboxes, and Custom Prefix. No target database field. SSO link from “vercel integration open neon”. Lands in Neon’s integration console. Has a database dropdown (currently showing neondb because hindsight is gone), but no Save button and no action that actually updates what the Vercel integration targets. Vercel CLI “integration-resource” subcommand. Only has “disconnect” and “remove”. Disconnect does not clear the cached database name on reconnect. Remove, I’m unwilling to touch because I cannot afford to lose my production Neon project if the command is actually destructive. Manually adding a Vercel env var override at the project level. Blocked by your own system with “variable has already been added to all Environments” because the integration owns those names. So there is no surface I can reach, UI, CLI, or API, that lets me change the target database of an existing Neon Marketplace resource without reprovisioning. THIS IS A KNOWN BUG YOUR TEAM HAS NOT FIXED This exact issue was reported publicly three months ago: Updating Connection String for Neon Database in a Vercel Application Help I’m working with a Vercel application that was initially set up with Neon DB using the default options. Recently, I created a new database on Neon and was able to run my application locally by updating to the new connection string. Everything works fine locally. Now, I need to update the connection string in my Vercel deployment. However, I encountered an issue where the POSTGRES_URL environment variable is not editable on the Vercel dashboard under environment variables. It seems this field wa… Your team member Amy Egan acknowledged it on January 21, 2025 and prescribed “disconnect and reconnect” as the workaround. Three months later there is no UI fix, no CLI fix, no API fix. And as I described above, Amy’s own workaround does not even work in my specific case. When the cached database has been dropped in Neon, reconnecting silently reuses the dead name. Related threads showing the same caching pathology in other fields: Neon database made with Vercel has env pointing to shadow prisma table Help I set up Neon with Vercel. For some reason, the automatically generated env variables in Vercel are now pointing to a prisma shadow table. I cannot change nor overwrite these. I’ve had to change env names around which works but seems mad that the integration is pointing somewhere completely wrong. Why Vercel-Neon integration uses NOLOGIN roles in preview connection URLs Help Problem After running a Prisma migration that creates a new PostgreSQL role with NOLOGIN for Row-Level Security (RLS) purposes, the Neon-Vercel integration for preview deployments started providing connection URL environment variables (DATABASE_URL / POSTGRES_URL) that reference this new NOLOGIN role instead of the original default owner role. This causes all preview deployment builds to fail at the prisma migrate deploy step with: Error: P1001: Can’t reach database server at ep-XXXXX.us-east… CURRENT BUSINESS IMPACT My production site is live only because the current build has baked in env vars from my earlier manual override, which has since been removed because your own system rejected the conflict with the integration. The next deployment, triggered by any code push or any auto redeploy, will crash immediately at the database migration step with “database hindsight does not exist”. I cannot ship any code change. I cannot patch bugs. I cannot push features. I am frozen. All of this started from your security advisory telling customers to rotate secrets. Following your security guidance caused an outage, and your integration has no way to recover from it. WHAT I NEED Immediate. Someone on your side edit the cached target database for my Neon Marketplace resource from “hindsight” to “neondb”. I have given you the exact resource IDs below. This is a metadata edit, it should take thirty seconds. Short term. Ship a UI, CLI command, or API endpoint that lets customers edit the target database of an existing Marketplace integration resource without destructive reprovisioning. This is a trivial operation that every customer on this integration will eventually need. Short term. Auto reconcile when the cached target database no longer exists in the provider. At a minimum, fall back to the default database or refuse to inject broken env vars. Do not silently break production. RESOURCE IDENTIFIERS Team: automatio-ai Team ID: team_CZHOYZ2wMomVs6aeESnQJrA9 Project: automatio-ai-9 Integration resource name: automatio-ultima-ai-sdk Neon project ID: old-tooth-01649155 integrationConfigurationId: icfg_MfqJe*******qYk8rbmh6w Current cached target database, wrong: hindsight Correct target database: neondb This is urgent. I have been on this single issue for hours today on top of having to do a full database migration because of a bug your integration has had for months. My users see a working site only because the current build is still serving. The moment anything forces a redeploy, production goes down. Please treat this as P1 and give me a real path to resolution, not another “disconnect and reconnect” reply.