Migrating from Vercel

Vercel is optimized for frontend and serverless functions. Atlasflow runs your app as a long-running container on a microVM. This makes Atlasflow a good fit for server-rendered apps, APIs, and anything that benefits from an always-on process rather than serverless functions.

# Is Atlasflow the right move?

Atlasflow is best when your app runs as a server: a Node/Next.js or Nuxt server, an API, or any framework with a long-lived process. If you rely heavily on Vercel-specific edge functions or static-only hosting, plan to run the equivalent inside your container instead.

# What maps over

# Steps

1. Run as a server. Make sure your framework runs as a long-lived server process rather than as serverless functions. For Next.js and Nuxt, use the standard production server build.
2. Create a project from your GitHub repository. Atlasflow auto-detects Node-based frameworks, or add a Dockerfile for full control.
3. Listen on port 3000. Bind to 0.0.0.0:3000 and make sure GET / returns a 2xx status. See Container requirements.
4. Recreate environment variables, splitting build-time and runtime values.
5. Deploy and test the preview URL, then move your domain with DNS verification.

# Things to know

• Atlasflow doesn't provide serverless or edge functions; everything runs in your container.
• There are no per-request charges. You're billed for resource usage by the second.
• Image optimization, ISR, and similar features run inside your app's own server rather than as a platform service.

# Next steps

• Supported frameworks: Next.js, Nuxt, and more.
• Container requirements: the runtime contract.
• Usage and credits: how pricing differs.