Migrate from Vercel
What changes and what carries over when you move a Vercel project to Nitroship.
Move your project's source and routing configuration to Nitroship, then build it with the matching managed preset. The command names are nearly identical, and supported address rules in vercel.json are read as-is. Work through the steps below.
1. Choose a deployment route
Managed presets build your source for Nitroship; they do not convert arbitrary Vercel functions or prebuilt Vercel runtime output. Replace Vercel-specific adapters with the adapter required by your framework guide, then choose the matching route.
| Project | Managed route |
|---|---|
| Next.js | Managed Next.js, with its dedicated adapter |
| Nuxt | Nuxt: managed Node server or static generation |
| Astro | Astro: static output or standalone Node server |
| SvelteKit | SvelteKit: adapter-node server or adapter-static site |
| SolidStart, Analog, TanStack Start | Managed Node builds: SolidStart, Analog, TanStack Start |
| React Router, Remix | React Router: managed Node SSR or static SPA mode; Remix: managed Node server |
| Angular, Qwik | Angular: static or managed Node SSR; Qwik: static or Node adapter |
| NestJS, Express, Fastify, Hono, Koa | Managed Node servers |
| Gatsby, Docusaurus, VitePress, Eleventy | Static generators: managed Node-toolchain static builds |
| Hugo, Jekyll, MkDocs | Static generators: toolchain containers exporting static files |
| Vite, Create React App | Vite and React SPAs: managed static builds |
| Plain HTML or generic static build | Static HTML and static site guidance |
| Laravel, Symfony, WordPress, PHP | Generated server containers: Laravel, Symfony, WordPress, PHP |
| Django, FastAPI, Flask | Generated server containers: Django and Python servers |
| Rails, Phoenix | Generated server containers: Rails, Phoenix |
| Go, Rust, Spring Boot, .NET | Generated server containers: Go, Rust, Spring Boot, .NET |
| Custom server or build not covered by a preset | Your own Dockerfile |
The managed outputs have four shapes:
static: files published to the CDN, with no server.node-server: a managed Node bundle plus client assets served from the CDN.container: a generated non-root OCI image for the server, with public assets copied to/nitroship/staticand served from the CDN.container-static: a toolchain image that exports only the static site, with no compute runtime.
Managed servers bind to 0.0.0.0:$PORT, with port 3000 as the default. Node server presets require a real Node entrypoint from an entry file, start script, or main; TypeScript projects need a build script that emits runnable JavaScript. Database migrations, queue workers, and schedulers are not started automatically.
build.framework in nitroship.json explicitly selects a framework, even if a root Dockerfile exists; it conflicts with build.dockerfile. Otherwise detection checks a configured Dockerfile or root Dockerfile.nitroship/Dockerfile, then the dedicated Next.js adapter, then managed framework presets, and finally generic static files. --local supports static and managed Node builds; container and container-static presets require the remote builder, so drop --local.
2. Check your vercel.json
ntro reads only these keys from vercel.json at the deployment root and applies them as they are:
cleanUrls, trailingSlash, redirects, rewrites, headers, routes, crons, version
Any other key rejects the deployment
Vercel-specific keys such as buildCommand, outputDirectory, framework, functions, regions, and images are not supported and cause an error. Remove them from vercel.json and, where needed, move them to nitroship.json as below.
| What you configured on Vercel | On Nitroship |
|---|---|
| Build command, output folder | build.command, build.outputDirectory in nitroship.json |
| Framework preset | build.framework in nitroship.json, using a Nitroship framework slug |
| Function region and size | compute in nitroship.json, or App Settings > Compute in the console |
| Image optimization | next.config for Next.js, otherwise images in nitroship.json (Image optimization) |
nitroship.json accepts everything vercel.json does, plus build, compute, and images. When both files exist, only nitroship.json is read. Renaming vercel.json to nitroship.json while you migrate is a good idea.
3. Know what is different
- Project → App. A Vercel project is a Nitroship app. Teams are still teams.
- Environment variables have only two targets:
productionandpreview. There is nodevelopmenttarget. For local development, pull preview values withntro env pull. See Environment variables. - CLI deploys default differently. Only the first deployment goes to production; after that, preview is the default. Add
--prodevery time if you deploy straight to production. See Managing deployments.
4. Command mapping
| Vercel CLI | Nitroship CLI |
|---|---|
vercel [path], vercel deploy [path] | ntro [path], ntro deploy [path] |
vercel --prod | ntro --prod |
vercel ls | ntro ls or ntro deployments list |
vercel inspect <deployment> --logs | ntro inspect <deployment> --logs |
vercel logs <deployment> | ntro logs <deployment> |
vercel switch [team] | ntro switch [team] |
vercel project ls | ntro apps list |
vercel env pull [file] | ntro env pull [file] |
vercel upgrade | ntro upgrade or ntro update |
team is an alias for teams, and most command groups also accept short names such as ls, rm, and remove. The full list is in the command reference.
5. Check after deploying
Do not assume behavior matches Vercel exactly. After deploying, open your key addresses, redirects, and APIs to confirm.