How to Migrate from Heroku to Your Own VPS

Heroku made deployment feel simple, and now moving away feels like opening a cupboard you were never meant to see.

Short version: To migrate from Heroku to your own server, move the app code, runtime, environment variables, database, background workers, scheduled jobs, domain, and HTTPS setup. Rebuild those pieces on the server, test the new copy before visitors see it, then switch DNS — the domain address book — when you are confident it works.

Why does moving from Heroku feel so different?

Heroku is like a serviced apartment. You bring your app, and Heroku handles the heating, locks, cleaning, mailroom, and repairs in the background.

Your own server is more like getting the keys to the building. You have more control, but you also need to know where the fuse box is.

On Heroku, a dyno is the small running unit that hosts your app. A Procfile tells Heroku what process to start, like “run the web app” or “run the worker.” Heroku also hides a lot of routine work: restarting crashed processes, collecting logs, attaching databases, handling HTTPS, and routing web traffic.

When you leave, those jobs do not disappear. They just become visible.

That does not mean the move has to be scary. It means you should treat the migration less like “copying a website” and more like moving a small shop: shelves, stock, signs, keys, payment terminal, opening hours, and the list of people who know where to find you.

What do you need to move before you switch traffic?

Start with the obvious piece: your app code. But do not stop there.

A Heroku app usually depends on several things that live around the code:

• Runtime: the language version and package manager your app expects, such as Node.js, Python, Ruby, or PHP.
• Environment variables: Heroku calls these Config Vars. They are secret or app-specific values such as database addresses, API keys, and mail settings.
• Database: for example, Heroku Postgres. This is often the most important part of the move because it contains your users, orders, posts, or settings.
• Add-ons: email, Redis, search, logging, monitoring, object storage, or queues.
• Background workers: separate processes that send emails, resize images, process payments, or run slow jobs outside the main website.
• Scheduled jobs: Heroku Scheduler tasks, cron-style tasks, or recurring maintenance jobs.
• Uploads and files: Heroku’s local filesystem is temporary, so many apps store files elsewhere. Check where user uploads really live.
• Domain and HTTPS: your domain must point to the new server, and the browser must trust the certificate.

The biggest mistake is moving only the web process and forgetting the quiet helpers. A shop can open its front door, but if the stockroom, card machine, and delivery driver are missing, customers still have a bad day.

Before you touch the live domain, make a backup plan. A backup is not just a file you hope works; it is something you know you can restore. If you have not thought this through yet, read how to back up your server before the migration.

Should you use Docker, a platform tool, or a plain server setup?

There is no single right path. The right choice depends on how much you want hidden from you.

Docker is a packaging tool. Think of it as a lunchbox for your app: the app, its expected environment, and its dependencies travel together. That can make a Heroku migration easier because Heroku also trains you to think in app processes.

A platform-style tool gives you buttons and screens around deployment. A plain server setup gives you the fewest moving parts, but you need to understand more of them.

If Docker is new to you, start with Docker on a server for beginners. If your goal is simply to get a small app online without becoming a full-time sysadmin, deploy a web app without DevOps gives a gentler overview.

How do you switch without breaking the site?

Do not make the first version of the new server the live version.

First, build the new setup on a temporary address, such as a test subdomain. This lets you check the homepage, login, database reads, database writes, email sending, background jobs, file uploads, and admin pages without asking real users to trust it yet.

Next, copy the database carefully. If your app accepts user changes — orders, comments, bookings, messages — decide how you will handle the final window. Some teams briefly pause writes on the old app. Others do one full copy, test it, then do a smaller final copy just before the switch.

Then switch DNS. DNS is the internet’s address book: it tells browsers where your domain lives. For a little while, some visitors may still reach Heroku while others reach the new server, so keep the old app available until traffic has clearly moved.

Finally, watch the boring signs: error logs, email delivery, worker queues, disk space, memory use, and response time. A migration is not finished when the homepage loads once. It is finished when the whole app behaves normally under real use.

FAQ

Can I migrate from Heroku without downtime? Often, yes, or close to it. The key is testing the new server first, planning the final database copy, and switching DNS only after the new app is ready.

What happens to Heroku Config Vars? You need to recreate them as environment variables on the new server. Missing or mistyped values are a common cause of broken logins, failed email, and database connection errors.

Do I have to use Docker? No. Docker can make the setup easier to move and repeat, but a simple app can also run directly on a server if the environment is clear and documented.

What is the riskiest part of leaving Heroku? Usually the database and background jobs. If either is forgotten or copied at the wrong time, the app may look fine while silently losing work.

The shortcut

Server Manager helps by keeping the move understandable instead of turning it into a pile of forgotten server decisions. The outcome you want is simple: the app runs, the domain points to the right place, HTTPS stays valid, and each project is separated enough that one app does not accidentally break another.

It also helps with the specific traps that tend to appear after leaving Heroku: a missing environment variable, a wrong database connection, an expired certificate, a worker that was never started, or a setup no one can explain three months later. The real benefit is not avoiding every technical detail; it is keeping the important details visible and legible.

When the migration is done well, Heroku stops being the safety net you are afraid to remove. You know where the app lives, what it depends on, how it is reached, and what to check if something goes wrong.