Migrate

Migrate from Vercel

Moving an app from Vercel to Stackap, with the database staying where it is, means deploying the code to a new project, recreating its variables and crons, and then changing one DNS record.

Who this is for

This is the shorter move: the app changes host and nothing else does. The database, if there is one, stays with its current provider and the app keeps connecting to it. If your database is on Supabase and you want it to move too, read the combined guide instead.

The deploy half of this was exercised on a copy of a real Next.js site, whose domain now points at Stackap.

Take inventory first

Every environment variable, pulled from the production environment, with public ones (NEXT_PUBLIC_*) noted separately.
Every cron entry in vercel.json.
Every domain and its DNS provider.
Anything configured only in the Vercel dashboard: headers, redirects, rewrites, regional settings, firewall rules and analytics.
Whether the app uses Vercel-specific packages for storage, key-value or edge functions.

What does not move automatically

Preview deployments: There are none. Use a second project as staging.
Edge and serverless functions: Routes that run at the edge or as separate functions have to run inside the app on a container.
Vercel-only storage products: Anything stored in a Vercel product must be moved to the project's own database or storage first.
Dashboard-only rules: Headers, redirects and rewrites defined outside the repository must be recreated in the app's own configuration.
Analytics: Stackap shows server-side load time, not browser analytics.

How to know it worked

The new site matches the old on a sample of real pages.
The app can reach its database and its third-party services from the new server's address, since IP allow-lists may need updating.
Each cron job fires once per schedule after the switch.
Email and webhooks still arrive, since callback URLs may have been tied to the old host.

Going back

Keep the Vercel project until Stackap has carried real traffic for a while. Going back is pointing the DNS record at the old address.

Run only one copy of anything that sends messages or charges money. Two live copies would do it twice.

Steps

Create the project. Create a project on Stackap and add its git remote to your repository.
Set the variables. Set public values first, because they are baked into the build, then secrets, each with stackap env set from standard input.
Deploy to the automatic address. Run stackap deploy and read the build log. Visit <slug>.stackap.com.
Compare. Open the old and new sites side by side and compare pages, including ones that read from the database.
Import crons. Run stackap cron import with your vercel.json. Do not stop the old ones yet.
Attach the domain. Run stackap domains add and create the A record it shows, after lowering the record's cache lifetime a day earlier.
Switch and stop the old schedules. Once traffic is on Stackap, disable the cron jobs on Vercel so jobs run once.

Early-access scope

The domain switch is a DNS edit that you make by hand at your DNS provider.
No preview deployments, edge functions or browser analytics to move to.
The process is operator-assisted, since Stackap is invite-only.
A database that stays elsewhere may add latency, because the app now runs in Germany.

Questions

Does the database need to move too?

No. The app can keep using its current database, though distance to it affects speed.

Will Vercel crons still run after I switch?

Yes, until you disable them. Do that deliberately, or every job runs twice.

Stackap is in early access. Tell us what you run and we will reply with a straight answer about whether it fits.

Ask for an invitation

Last updated 2026-10-03.