Resources

Move a Next.js app off Vercel

Moving a Next.js app off Vercel means a container built from your repository replaces Vercel's build and runtime; most of the app is unchanged, and the work is in crons, environment variables, previews, caching and the domain.

What stays the same

Your code. Stackap builds the repository with its own generated Dockerfile (or yours, if you have one), runs the production server, and checks it before sending traffic. A Next.js site with tens of thousands of statically generated pages has been moved this way and builds in about 96 seconds. The app does not need to be rewritten for Stackap.

Feature by feature

On Vercel	On Stackap
Git push builds and deploys	You add the project's Stackap git remote next to your existing one and push the production branch. Only that branch builds.
Preview deployments per branch	Not available. Test on a second project or locally before a change reaches production.
Environment variables	Set per project, encrypted at rest. `NEXT_PUBLIC_` values are baked in at build time; every other value is a placeholder during the build and real only at runtime.
Cron jobs in `vercel.json`	Imported as scheduled jobs. Times are in UTC. A job calls a path on your app, so check that the path authenticates its caller.
Variables Vercel injects, such as `VERCEL_URL`	Not present. Search the code for `VERCEL_` and replace each with your own variable.
Image optimization	Handled by the Next.js server in your container. Remote image hosts must be listed in the Next.js config, as before.
Edge runtime and middleware	Not claimed. These have not been tested here, so verify any edge-specific code on a second project first.
Incremental static regeneration cache	Lives with each server instance. If you scale to several copies, each keeps its own cache.
Analytics and speed insights	Not included. Stackap shows load time per project from its access log.
Domain and HTTPS	Attach the hostname, create the DNS record Stackap shows, and HTTPS switches on once DNS is correct.

The order that keeps you safe

Deploy to Stackap while Vercel still serves production, and test the Stackap address.
Copy environment variables across, replacing any VERCEL_ ones.
Check that cron paths and webhooks work against the Stackap address.
Lower the DNS time-to-live ahead of the change, then switch the record. Keep the Vercel project until you are sure.
Flush any cached DNS on your side after the switch, since a stale answer can make the domain look broken when it is not.

What to decide first

If you rely on preview deployments, edge middleware or Vercel's analytics, decide how you will replace them before moving, because Stackap does not provide them today. If you use a database from another provider, it keeps working: the connection string is just another environment variable. Moving the database itself is a separate task covered in the Supabase migration guide.

Questions

Will my app need code changes?

Usually only the places that read Vercel-specific variables or use edge-only features. Everything else runs as it did.

Is this a one-click migration?

No. It is a sequence you or your agent follows, with Vercel kept running until you switch the domain.

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-04.