// Migration Guide · 2026
Migrate from Vercel to Runsite
Vercel is unbeatable for frontend. But backends are a different story: the moment you need a long-running API in the EU, with no cold starts and GDPR you can actually sign off on, the serverless model gets in the way. Runsite runs your whole app as an always-on container in Frankfurt, built by Railpack with zero config or straight from your own Dockerfile.
- ~20 min
- typical migration
- Same git push
- keep your workflow
- Keep Vercel running
- until you cut over
// the mental model
Every Vercel concept has a Runsite home
Most Vercel projects ship with little more than a vercel.json, and plenty ship with none at all, just framework auto-detection. Runsite rebuilds the same app a different way: Railpack detects your framework and builds it with no config, or you point us at a Dockerfile you already trust. Either way it runs as one always-on container, not a spread of serverless functions. Honest about what's automatic and what you handle once.
{
"framework": "nextjs",
"buildCommand": "next build",
"functions": {
"api/*.ts": { "maxDuration": 60 }
},
"crons": [
{ "path": "/api/digest", "schedule": "0 8 * * *" }
]
} - →vercel deploy / git pushvercelgit push → Railpack build autoNext.js, Astro, SvelteKit, Remix and Vite detected with zero config
- →Framework preset & buildvercelRailpack build, or your Dockerfile autoNo config required; bring a Dockerfile when you want full control
- →Serverless Functions (/api)vercelRoutes in one always-on server autoNo cold starts and no maxDuration timeout; the process just stays up
- →Edge Functions & MiddlewarevercelRun inside the Node container you doStandard Node runtime; check any edge-only Web APIs you used
- →Vercel Postgres / KV / BlobvercelManaged Postgres, Redis & S3 storage you doProvision in Frankfurt, then pg_dump → restore; Blob → S3-compatible bucket
- →vercel.json crons & envvercelScheduled services & env vars you doRecreate crons as jobs; vercel env pull → paste once, encrypted
// step by step
From Vercel to live in the EU
Six steps. Most of them take seconds. Vercel keeps serving traffic until you flip your DNS.
- 1
Create a Runsite project
~30 secSign in at runsite.app and create an empty project. No credit card, and no per-invocation meter ticking in the background.
- 2
Connect your Git repo
Railpack · or your DockerfileAuthorize GitHub, GitLab or Bitbucket. Railpack auto-detects your framework and builds it, or you drop in a Dockerfile and Runsite builds exactly that. It's the same git push you used on Vercel.
- 3
Recreate your data in Frankfurt
Postgres · RedisProvision a managed PostgreSQL and Redis with one click each. They replace Vercel Postgres and KV, run in the EU, and come with connection strings ready to wire into your env.
- 4
Copy your environment variables
vercel env pullRun vercel env pull to export your variables, then paste them into Runsite. Secrets are encrypted at rest and never logged.
- 5
Move your database
pg_dump → pg_restorepg_dump from Vercel Postgres (or your Neon or Supabase origin) and restore into Runsite with pg_restore. Your DATABASE_URL is already wired to the new database.
- 6
Deploy & cut over DNS
Live in < 2 mingit push, verify on your Runsite URL, then point your custom domain when ready. Vercel keeps serving until you flip DNS, so you can roll back any time.
// no surprises
What moves on its own — and what you touch
Honest about the boundaries. The supported stack is recreated in one click; a short list needs a human, and Runsite flags every item.
Imported automatically
- ✓ git push deploys — framework auto-detected by Railpack (Next.js, Astro, SvelteKit, Remix, Vite)
- ✓ Your own Dockerfile, built as-is when you want full control
- ✓ Serverless & API routes → one always-on container, no cold starts or timeouts
- ✓ Custom domains & automatic TLS certificates
- ✓ Always-on compute in Frankfurt — EU data residency by default
You handle once
- → Environment variables — vercel env pull, then paste once
- → Vercel Postgres & KV data — move with pg_dump / pg_restore
- → Edge Functions & Middleware — run on Node, review edge-only Web APIs
- → vercel.json crons — recreate as scheduled services
- → Vercel Blob — point uploads at S3-compatible object storage
- → Global edge caching — single Frankfurt region, add a CDN if you need it
// vercel problems → runsite solutions
Common Vercel frustrations — sound familiar?
Every Vercel frustration, solved.
Vercel problem
"Vercel is frontend-only"
Need to deploy a Python API or Go service? Vercel's serverless model doesn't support long-running backend processes.
Runsite solution
Full container hosting, any stack
Deploy Django, FastAPI, Express, Go, or Rust in persistent containers. No cold starts, no function timeouts.
Vercel problem
"Origin servers are in the US"
Vercel's edge caches content globally, but your serverless functions and data origin are US-based.
Runsite solution
EU-only infrastructure
Compute, storage, and databases all run in EU data centers. True data residency, not just edge caching.
Vercel problem
"Surprise bills from function invocations"
Serverless pricing is unpredictable. A traffic spike can lead to unexpected charges.
Runsite solution
Fixed pricing + hard spending caps
Predictable monthly bills. Set a cap, get alerts. No pay-per-request surprises.
// comparison
Runsite vs Vercel
Side-by-side. No marketing fluff — just facts.
| Feature | Runsite | Vercel |
|---|---|---|
| Backend Hosting | ✓ Full containers, any stack | Serverless functions only |
| EU Data Centers | ✓ Frankfurt (eu-central) | Edge only, origin = US |
| GDPR Compliance | ✓ EU entity, full compliance | ✗ US company |
| Managed PostgreSQL | ✓ From €5/mo | Via Vercel Postgres (Neon) |
| Docker Support | ✓ Any Dockerfile | ✗ Not supported |
| Spending Limits | ✓ Hard cap + alerts | Soft limits only |
| Frontend Hosting | Static files via S3 | ✓ Best-in-class CDN |
| Free Tier | ✓ Permanent | ✓ With limits |
// migration questions
Migrating from Vercel, answered
Do I have to rewrite my app to leave Vercel?
For most frameworks, no. Railpack detects Next.js, Astro, SvelteKit, Remix or a plain Vite build and runs it with the same git push workflow. If you'd rather own the build yourself, bring a Dockerfile and Runsite builds exactly that. The only code you revisit is anything that leaned on a Vercel-specific edge API.
How do my serverless API routes work without serverless?
They run inside one always-on container instead of a function per request. For Next.js, next start serves your /api routes in the same process as your pages. There are no cold starts, and no maxDuration limit, so a slow request just runs to completion.
Does Next.js fully work, including ISR and image optimization?
Yes. Runsite runs your Next.js app with next start, so server rendering, API routes, ISR and on-demand revalidation all behave the same. Image optimization runs inside the container. You don't need the Vercel runtime for any of it.
Where do my Vercel Postgres and KV data go?
Into managed PostgreSQL and Redis on Runsite, provisioned in Frankfurt. Move Postgres data with pg_dump and pg_restore, and the new connection string is auto-wired into DATABASE_URL. KV maps to Redis, and Vercel Blob maps to S3-compatible object storage.
I rely on Vercel's global edge network. What changes?
Runsite runs in a single EU region, Frankfurt. You trade global edge distribution for simplicity, fixed pricing and guaranteed EU data residency. For European-facing apps that's usually a win. If you serve a worldwide audience and need low latency everywhere, put a CDN in front of Runsite, or keep Vercel for the static frontend and run only your backend on Runsite.
Will my app go down during the migration?
No. Your Vercel deployment keeps serving traffic while you build and verify on Runsite. You cut over by switching DNS only once you're happy, and you can point DNS back at Vercel to roll back.
Leave Vercel behind
Bring your vercel.json. We'll handle the rest — in Frankfurt.
Start your migration →