How to deploy a v0 app to your own VPS

Why this one is different

With most AI builders the hard part is getting your code and data out at all. With v0 that is not the problem: you get real Next.js, real React components, standard Tailwind, and you can copy it into your own repository whenever you like. There is no vendor holding your source hostage.

The difficulty is subtler and catches better engineers. Next.js running on Vercel and Next.js running on a rented server are not quite the same product. Several features that appear to be part of the framework are actually part of the platform, and they stop existing the moment you leave.

Two ways to run it

Node process behind a reverse proxy

Build the app, run it as a long-lived Node process, put nginx or Caddy in front to terminate TLS and serve static files. The most conventional arrangement, the easiest to reason about, and the one most people should pick.

What it needs from you: a process manager so the app comes back after a crash or a reboot, and certificates that renew without anyone remembering to do it.

Containerised, with a standalone build

Next.js can emit a self-contained output that ships only what the app actually needs to run. The resulting image is dramatically smaller than copying the whole project in, which makes deploys faster and rollbacks cheap.

Worth the extra setup if you expect to deploy often or run more than one instance. Overkill for a single app with a handful of users — and choosing it too early is a common way to spend a week on infrastructure instead of on the product.

What has to happen before the domain moves

1. Audit what is actually platform-specific. Every managed database, blob store, cron entry and analytics hook. This list is the migration; everything else is mechanical.
2. Stand up the replacements. Your own Postgres, your own object storage, your own scheduler — and change the code that talks to them.
3. Move the environment variables. They live in a dashboard, not in the repository, and there are always more than anyone remembers.
4. Decide about image optimization. Either install what it needs and give it room, or turn it off deliberately and serve pre-sized images. Both are fine. Discovering the question in production is not.
5. Run it on a temporary hostname first. Click through it as a real user, with TLS working, before anything points at it.
6. Keep a rollback. The old deployment stays reachable until the new one has survived a day of real traffic.

Where it goes wrong

• Image optimization eats the server. A small VPS resizing large images on demand will run out of memory, and it will do it under load rather than during testing.
• Regenerating pages behave oddly behind more than one instance.Each copy keeps its own idea of what is current, so users see different content depending on where they land.
• Middleware assumptions carry over silently. Code written for an edge runtime runs somewhere else now, with different limits and different behaviour around headers and redirects.
• Analytics and error reporting quietly stop. They were wired in by the platform. Nobody notices until something breaks and there is nothing to look at.
• The build is run on the server. A cheap VPS building a Next.js app while also serving it is how a deploy turns into an outage. Build elsewhere, ship the result.

Or have it done

We map what is platform-specific, replace it with services you own, and hand back a running app: your repository, your database, your domain and certificates, plus a pipeline so the next deploy is one command.

From $600 — about a day of work once we have access. The engineering is rarely what takes the time; tracking down who holds the server credentials usually is. Gather those first.

Apps leaning hard on managed storage or heavy background work get quoted after we look — that is a bigger job and pretending otherwise helps nobody.