migration
How to Move from Render to Your Own VPS
A plain-English guide to moving an app from Render to your own server without losing track of domains, HTTPS, databases, or deployments.
Render got your app online quickly, but now the limits, pricing, cold starts, or missing control are starting to get in your way.
Short version: to move from Render to your own server, you need to recreate the pieces Render handled for you: running the app, storing secrets, exposing it through a domain, securing it with HTTPS, keeping it alive, and backing it up. The risky parts are usually not the code itself, but the hidden glue around it: environment variables, database access, DNS records, certificates, and restart behavior after a crash or reboot.
What changes when you leave Render?
Render is a hosted platform. You give it your code, set a few values, and it takes care of the machinery around that code.
Your own server is more like renting an empty workshop. The space is yours, but you decide where the shelves go, which doors are locked, how the lights turn on, and who has a spare key.
That extra control is the reason many people move. It also means you need to replace the invisible jobs Render was doing in the background.
| Area | On Render | On your own server |
|---|---|---|
| App process | Render starts and restarts it | You need a reliable way to keep it running |
| Domain | Connected inside Render | DNS must point to your server |
| HTTPS | Mostly automatic | Certificates must be issued and renewed |
| Secrets | Stored as environment variables | Must be stored somewhere safe and understandable |
| Database | Often managed or attached | Must be hosted, connected, backed up, or kept external |
| Logs | Built into the dashboard | You need a place to read errors later |
If you are still deciding whether this is the right move, our comparison of self-hosted tools and raw servers may help: Coolify, Dokploy, or a raw server.
What should you copy from Render before you move?
Before touching DNS, make an inventory. This is the part people skip, and it is why migrations feel haunted later.
Write down the app name, runtime, build command, start command, public domain, environment variables, database connection details, background workers, scheduled jobs, and any uploaded files your app depends on.
Think of Render as a furnished apartment. You are not just moving the sofa. You are also checking the cupboards, the fuse box, the mailbox key, and the notes stuck to the fridge.
Pay close attention to environment variables. These are the secret or app-specific values your code reads at runtime, such as DATABASE_URL, REDIS_URL, SECRET_KEY, NODE_ENV, API keys, and mail credentials. A missing variable can make a healthy app look broken.
Also decide what happens to your database. Some migrations keep the database with a managed provider at first, then move it later. That can reduce risk because your app and database are not changing at the same time.
What can break during the migration?
The most common failure is not dramatic. The page just does not load.
Sometimes the domain still points at Render because the DNS record was not changed, or the change has not reached everyone yet. DNS is the internet’s address book, and it can take time for updates to spread.
Sometimes the app is running, but the web server cannot reach it. That often shows up as 502 Bad Gateway, which usually means the front door answered, but the room behind it was empty, locked, or listening in the wrong place.
HTTPS can also trip you up. A wrong or expired certificate makes browsers show scary warnings, even if the app itself is fine. If certificates are new territory, read how to get free HTTPS on your own server.
Databases are another common trap. Your app may connect from Render, but your new server may not be allowed through the database firewall. Or the connection string may still contain an old internal hostname that only worked inside Render.
Finally, do not forget files. If users uploaded images, PDFs, or avatars to local storage on Render, those files may not live in your Git repository. You need to find them before cutting over.
How do you switch over without a messy outage?
Treat the move like opening a new shop before closing the old one.
First, get the app running on the new server under a temporary address or test domain. Confirm the app starts, pages load, login works, background jobs run, email sends, and the database connection is correct.
Then prepare backups. A backup is not just a copy; it is something you know how to restore. If your app has real users or real orders, read how to back up your server before the final switch.
When the new version looks healthy, change the DNS record for your domain so visitors go to the new server. Keep the Render service around for a short while instead of deleting it immediately. That gives you a fallback if you discover a missing file, wrong secret, or unexpected database permission.
After traffic has moved, watch logs and basic behavior. Test the boring things: password reset, checkout, admin login, file upload, webhooks, and scheduled tasks. These are the places where “it loads” can still hide broken parts.
FAQ
Can I move from Render without changing my code? Sometimes, yes. But you still need to recreate the runtime, environment variables, database access, domain, HTTPS, and process management around the code.
Should I move my database at the same time? Only if you have to. Keeping the database where it is during the first move can make the migration easier to debug.
Will my domain have downtime? It can, but it does not have to be long. Most downtime comes from changing DNS before the new server is fully tested.
**What does 502 Bad Gateway mean after moving?** It usually means the public web layer is reachable, but it cannot reach your app process behind it.
The shortcut
Server Manager helps you avoid turning this move into a pile of loose notes. The outcome is a server setup where your app, domain, HTTPS, database connection, and related services stay visible in one understandable place.
That matters because the painful parts of leaving Render are usually the forgotten details: a missing DATABASE_URL, a wrong certificate, a domain pointing at the old host, one project interfering with another, or nobody remembering how the app was started six months later.
The real benefit is that your setup remains legible over time. When something breaks, you are not digging through old terminal history or guessing what past-you meant. You can see the shape of the system and fix the specific piece that failed.
What does a successful Render migration feel like?
A good migration is boring in the best way. Your users visit the same domain, the browser shows a valid HTTPS lock, the app behaves the same, and you know where the important pieces live.
You move from Render to your own server to get more control, not more confusion. If you copy the hidden parts, test before switching DNS, and keep the setup readable, you get that control without turning every future change into a mystery.