Import from Vercel: Move a Vercel Project to Cogny Sites in One Pass
Moving a site off Vercel is rarely hard. It is long. You read the project's build settings, recreate the site, copy every environment variable and decide which ones are secrets, notice that vercel.json was quietly doing rewrites, rebuild the crons somewhere else, and — if the domain lives on Vercel's nameservers — copy every DNS record, mail included, before you switch.
We did this by hand for six of our own sites. Every one took the same steps, and every missed step showed up as something broken after the move: a reverse proxy that stopped working because nobody ran vercel.json anymore, a Next.js app that ran out of memory, a mail record that didn't make it across.
Import from Vercel does those steps for you. It's in Settings → Sites → Import from Vercel.
What it does
You paste a Vercel access token, pick a project, and see a preview before anything is written. Then the import runs five steps, each with its own result. Cogny only reads from Vercel; nothing on Vercel changes.
1. The site, from the project's settings
Cogny creates the site from the project's linked GitHub repository, production branch, root directory, framework, build command and Node version. Imported sites start with 1 GiB of memory, because Next.js apps commonly need more than the 512 MiB default.
The repository has to be connected to your Cogny workspace (Settings → Coding Agent → GitHub). If Cogny can't see it, the preview says so and tells you where to give access. If the repository already has a Cogny site, the import fills that site instead of creating a second one.
Vercel's install command isn't carried over: Cogny Sites runs npm ci. A repository that needs pnpm, yarn or bun builds with its own Dockerfile.
2. Environment variables
The import copies the Production variables — the ones your live site runs on.
- Values the browser needs at build time (
NEXT_PUBLIC_,VITE_,PUBLIC_,REACT_APP_and similar) become plain variables. - Everything else becomes a secret: stored in your workspace's own Google Cloud project, given only to the running site, never shown again.
- Variables marked Sensitive on Vercel can't be read back by anyone, so the import lists them by name for you to paste into the site's Settings.
- Variables Vercel sets itself (
VERCEL_URL,VERCEL_GIT_*…) are skipped. Variables that exist only for Preview or Development are listed so you know they weren't copied. - If your repository has its own Dockerfile, the public values are also passed to it as build arguments. Add an
ARGline for each one your build uses.
Values never appear in the import panel, in the voice agent, or in any log. The preview shows names only.
3. Crons become scheduled jobs
Vercel crons become Cloud Scheduler jobs in your workspace's Google Cloud project. Each job calls the same path on the same UTC schedule, with the same Authorization: Bearer <CRON_SECRET> header Vercel sends, so the check in your route keeps working. If the project has no CRON_SECRET the import can read, Cogny creates one and saves it as a site secret.
Crons need the site's address, so this step waits until the site has deployed once.
4. DNS records, copied to Cloudflare
For a domain whose DNS is on Vercel, switching nameservers without copying the records first takes your email down. The import reads every record from Vercel — MX, SPF, DKIM, _dmarc, verification TXTs, CAA, wildcards, other subdomains — and writes them to the domain's Cloudflare zone, DNS only (grey cloud).
It leaves out the records that point the site itself at Vercel: the site's domain setup in Cogny adds the right ones. If your CAA records would stop Google from issuing the site's certificate, it adds 0 issue "pki.goog" next to them and tells you.
It never changes a record already in Cloudflare on its own. When one is in the way, the step lists it, and Replace these records deletes exactly those after you confirm. When the copy is done, it shows the two Cloudflare nameservers to set at your registrar.
You need the domain added to Cloudflare (the Free plan works) and Cloudflare connected to the workspace, the same connection Cogny Sites uses for custom domains.
5. vercel.json rewrites, redirects and headers
Cloud Run serves your app as it is; it doesn't read vercel.json. Rewrites, redirects and headers there stop working after the move unless the app does them itself. The import reads vercel.json from your repository, lists every rule, and writes the equivalent rewrites(), redirects() and headers() code for next.config, ready to paste.
It also fixes the one conversion that trips people up: a pattern like /~:path* is valid in vercel.json but Next.js refuses it, so the code uses /~:path(.*), which matches the same paths.
On Cloud, File a code ticket puts the change on your board for the code agent, which opens a pull request for you to review.
Re-running is safe
Every step only adds what is missing. Run it again and it skips variables the site already has (including ones you've changed in Cogny since), finds the scheduled jobs it made last time, and leaves DNS records that are already in place. If a step stops — a missing permission, a domain not yet in Cloudflare — fix the cause and run that step again.
When you're done
Delete the token from the import panel, and delete it in Vercel too. The import panel offers this once the steps are done.
Ask the voice agent
The in-app voice agent can read the preview, run each step after you say yes, and read back any DNS record it would replace before replacing it. It never takes the Vercel token by voice: it opens the panel and you paste it there.
What it doesn't do
- Projects deployed from GitLab, Bitbucket or the Vercel CLI: Cogny Sites deploys from a GitHub repository connected to your workspace.
- Vercel's legacy
routesinvercel.jsonare listed but not converted; they need porting by hand. - SRV and HTTPS DNS records are listed for you to add in Cloudflare yourself.
- Edge Config, Vercel KV/Blob/Postgres and other Vercel storage aren't moved. Point the app at their replacements with environment variables.