A Vercel alternative: deploy a Next.js app without managing a server

Vercel made deploying a Next.js app almost trivial: push to Git, and the site is live. Many teams are perfectly happy with that. Others eventually look for an alternative, for reasons that are rarely dramatic: a bill that follows usage and gets hard to predict, a wish to keep the application and its database in one place, a need for processes that run continuously, or simple curiosity. This article describes what changes when you move to a platform that runs your app in a container, with no server to administer, and how to go about it for a Next.js project.

Two hosting models, not two quality levels

A serverless host splits your application into functions that start on demand, at the edge of the network or in a region. Each request may land on a different instance, state does not persist from one call to the next, and billing generally follows consumption.

A container-based platform runs your application as a Node process that stays up. The same Next.js server receives every request, keeps its caches in memory, can hold long-lived database connections and run background tasks. Billing then tends to follow a plan with reserved resources.

Neither is better in the absolute. The first shines for very uneven traffic and content distributed worldwide. The second is simpler to reason about when the application talks to a database, keeps connections open or needs predictability, both technically and on the invoice.

What Pierrr does, concretely

Pierrr is an application hosting platform. You connect a GitHub or GitLab repository, Pierrr detects the framework, builds the application and puts it online in a container with an HTTPS certificate. For a Next.js project there is no Dockerfile to write: the platform's Next.js template handles it, with or without output: 'standalone'. If you prefer to keep control, a Dockerfile at the root of the project is used as is.

Around the application, the platform provides what people usually build themselves:

• a deployment on every push to the chosen branch, with a readable build log;
• one Postgres database per project, isolated from the others, with its connection variables injected into the application;
• database backups you can restore from the dashboard;
• custom domains with an HTTPS certificate managed for you;
• environment variables and secrets stored encrypted;
• health alerts, logs, and CPU and memory metrics;
• roles per organization for teams.

Plans range from Free to Starter, Pro and Business. Every new workspace gets a 14-day trial on Starter or Pro. The Free plan suits testing or a small project, with one trade-off to know about: a Free project sleeps at night and stops after 30 days without activity, while paid plans stay on at all times.

What carries over, what does not

Let us be precise, because a successful migration starts with an honest list of differences.

What carries over: deployment from Git, a full Next.js site with server-side rendering, API routes, environment variables, custom domains and HTTPS.

What you gain: a Postgres database hosted with the application, so one less third-party service to wire in, processes that stay alive, and a plan whose resources are known in advance.

What you lose, or must replace:

• per-branch preview deployments, which do not exist on Pierrr;
• Vercel cron jobs, to be replaced by another scheduling mechanism;
• serverless functions and the edge runtime: your application runs as a single server, not as functions spread around the world;
• variables supplied by the original platform, such as VERCEL_URL: if your code uses them, replace them with your own variables;
• worldwide distribution at the network edge: if your visitors are everywhere and global latency is critical, put a CDN in front of the application.

If any of these is a blocker for your project, better to know before you start. For many applications, they are features that go unused.

Migrating a Next.js project from Vercel

Pierrr offers a migration assistant for Vercel, open to all organizations and currently in beta. The recommended order is designed so that Vercel keeps serving your site until the last moment.

1. Connect Vercel with a token. You create a token yourself in your Vercel account settings, limited to the relevant team and with a one-day expiry. Pierrr uses it to read the project; it is kept encrypted for at most 24 hours and erased when the migration ends.
2. Analyze the project. The assistant lists what will be imported: the repository, the framework, the build commands, the number of production variables, the domains and the detected Postgres database. It also shows warnings, for example what has no equivalent on Pierrr. A project with no Git repository, an unsupported code provider or a repository your organization cannot reach blocks the import until the cause is fixed.
3. Import. Pierrr creates the project, imports the production variables and starts the first deployment. Variables marked sensitive at Vercel are never handed back: the assistant asks you to enter them again.
4. Check on the Pierrr address. Before touching any domain, open the application on its provided address and go through it: pages, sign-in, database calls, email sending.
5. Copy the database. If you use the project's Pierrr database, the assistant copies the contents of your current Postgres database into it, in a single transaction: if it is interrupted, the project database stays as it was. The copy is a snapshot. For an application that writes a lot, do it just before switching the domains.
6. Switch the domains. Pierrr shows the DNS record to set for each address, checks every 20 seconds and puts the address online, certificate included, as soon as DNS points to Pierrr. If your domain uses Vercel's DNS, an automatic switch is offered, with a return to the previous DNS possible for 24 hours. This automatic switch is the least proven part of the journey: if your domain is critical, switching manually at your registrar remains the safer choice.
7. Finish. When everything works, you finish the migration, which erases the token. Your Vercel project stays in place: delete it whenever you like.

The whole process is detailed in the Vercel migration documentation.

A project that does not use Next.js?

The assistant also recognizes single-page apps (Vite, Create React App, Vue, Preact), static site generators (Astro, Gatsby, Docusaurus, Eleventy, VitePress), Node servers (Express, NestJS, Fastify, Hono, Koa), Nuxt, SvelteKit, Remix, Bun and FastAPI. A framework missing from this list works as long as the repository contains a Dockerfile.

Who this suits, and who it does not

This approach suits a team that wants an application and its database in one place, with a predictable bill, without becoming system administrators. It also suits a Next.js app that talks a lot to Postgres, keeps connections open or runs background tasks.

It suits less if your application depends on edge functions, per-pull-request branch previews, or native worldwide distribution. In that case a serverless host remains the right tool, and there is no shame in keeping it.

The simplest step: try it on a test project

The best way to decide is not to read a comparison but to migrate a side project. Create a workspace, run the assistant on a test application and see what you get: the migration writes nothing at Vercel (unless you yourself ask for the automatic DNS switch), and your original project keeps running throughout.

To get started, getting started takes you from sign-up to a first application online, and the pricing page details the plans and their limits.