How to Move a Vercel App to a VPS

You like Vercel until the bill, limits, or lack of control starts to feel like someone else owns the front door to your app.

Short version: to move a Vercel app to your own server, you need to rebuild the parts Vercel handled for you: the app runtime, environment variables, domain routing, HTTPS, deployments, and backups. The safest move is to set up the new server first, test it on a temporary address, then switch DNS only when the app is already working.

What changes when you move from Vercel to your own server?

Vercel is like a serviced apartment. You bring the furniture — your code — and Vercel handles the locks, lights, heating, mail, and repairs.

Your own server is more like owning the building. You get more control, but you also need to know where the fuse box is. That does not mean you need to become a full-time sysadmin, but it does mean the hidden parts become visible.

The big mental shift is this: Vercel hides operations. A server makes operations part of the project.

If your app is small, that can be perfectly fine. If you want a broader beginner path, this guide pairs well with deploying a small web app without DevOps.

What do you need before you move a Vercel app?

Start with a list of what Vercel currently knows about your app. Think of it as emptying your pockets before changing coats.

You need your environment variables. These are the secret notes your app reads at runtime: database URLs, API keys, auth secrets, payment keys, and public values such as NEXT_PUBLIC_API_URL. Missing one can make the app boot but fail in strange ways.

You need to know how your app builds and starts. A Next.js app, for example, may have a build step and then a server process. A static app may only need files served by a web server. A background worker or queue is a separate moving part, not a detail.

You also need to know where the database lives. If you used an external database with Vercel, you may keep it there. If the database also moves, treat that as a separate migration with its own backup and restore plan.

Finally, write down your domains. Include the main domain, www, preview domains if you used them, and any API subdomains. Domain mistakes are one of the most common reasons a moved app looks “down” even when the app itself is fine.

How do you move the app without breaking it?

Do not move the domain first. That is like changing your shop sign before checking whether the new shop has shelves.

Set up the app on the new server while Vercel is still serving real visitors. Get the code running, add the environment variables, connect the database, and test the app through a temporary address or test domain.

Then check the boring pages, not just the homepage. Log in. Submit a form. Trigger an email. Upload a file. Visit an API route. If your app uses server-side rendering, test pages that fetch data on each request.

Watch for the literal error string 502 Bad Gateway. It usually means the front door is working, but the app behind it is not answering. Common causes are a crashed Node.js process, a wrong port, a missing environment variable, or the app taking too long to start.

When the app works, point the domain at the new server. DNS is the internet’s address book, and changes can take time to spread. Keep the old Vercel project alive during the change so late-arriving visitors still have somewhere to go.

After the domain points correctly, set up HTTPS. A valid SSL certificate is what turns browser warnings into a normal lock icon. If you want the plain-English version, read how to get free HTTPS on your own server.

What usually goes wrong after leaving Vercel?

The first trap is missing environment variables. Your app may build successfully, then fail only when a user clicks “Sign in” or “Pay.” Copying names is not enough; values and production-safe settings matter.

The second trap is treating deploys as a one-time event. Vercel gave you a path from Git to production. On your own server, you need a repeatable path so the next update is not a guessing game.

The third trap is forgetting files that users create. If your app accepts uploads and stores them locally, they live on the server. That means they need storage planning and backups.

The fourth trap is performance. A server with too little memory can look fine at idle, then fall over during a build or a traffic spike. If you are unsure about sizing, start with what size server you need and adjust based on real use.

Backups are not optional. Before the cutover, know how you would restore the app if a deploy goes wrong, a database import fails, or you delete the wrong folder. A backup you have never tested is closer to a wish than a plan.

FAQ

Can I move a Next.js app from Vercel? Yes. You need a server that can run the built Next.js app, plus the same environment variables and domain setup Vercel used.

Will my Vercel environment variables move automatically? No. You need to copy them into the new hosting setup yourself and keep secrets private.

Do I need Docker? Not always. Docker can make the app easier to package, but a simple app can also run without it if the runtime is clear.

Can I keep my database where it is? Often, yes. Moving the app and moving the database are separate decisions.

**Why do I see 502 Bad Gateway after the move?** The web server can be reachable while the app process behind it is crashed, misconfigured, or listening in the wrong place.

The shortcut

Server Manager helps you move the app without turning the setup into a pile of forgotten notes. The outcome is simple: your domain, HTTPS, app process, and environment are kept visible enough that you can understand them later, not just on migration day.

That matters for the exact problems that show up after leaving Vercel: a missing secret, a wrong domain target, an expired or wrong certificate, one project breaking another, or a deploy path nobody remembers three months later.

The real benefit is not avoiding every technical detail. It is keeping the moving parts legible, so fixing a broken login or 502 Bad Gateway does not start with “where did we put that?”

What is the win when the move is done?

A good move from Vercel to your own server is not dramatic. Visitors keep reaching the same domain. HTTPS works. Login works. Deploys are repeatable. Backups exist.

You gain control without turning the app into a mystery box. That is the quiet win: your app runs in a place you control, and the setup still makes sense when you come back to it later.