Move a Bot Off a VPS: What Changes

·4 min read·Updated
vpsmigrationbotsoperationshow-to

If your bot is the only reason you maintain a VPS, moving it to a container can remove host patching, systemd setup and reverse-proxy work. You still maintain the bot, its container image, data backups and monitoring. Check those responsibilities alongside the loss of host access and private networking before moving.

What stops being your job

The process manager. The platform restarts your container process when it exits, so you usually do not need a systemd unit or pm2 for one bot. It does not detect a process that stays up but stops answering events. Check your bot's behavior and crash-loop logs.

OS patching. No apt upgrade, no reboot window, no unattended-upgrades config you set up once and never verified. Your container's base image is your concern, and you update it by rebuilding — a deploy rather than an ssh session.

TLS certificates. If your bot exposes an HTTP service, an HTTPS port binding gets a platform hostname and automatic certificate. Custom domains are not currently supported.

Reverse proxy config. No nginx site files, no proxy_pass, no reloading after an edit. You bind a port and the routing happens.

Firewall rules. A bot that only makes outbound connections needs no bound port. Every port you do bind is public; there is no per-app firewall or private network here.

What actually moves

Three things, and only one is fiddly:

Your code. Push a repository with a Dockerfile, deploy an image, or upload a supported project as a ZIP. Check its build and start command before stopping the VPS bot.

Your environment variables. They're currently in a systemd Environment= line, an EnvironmentFile, or a .env next to your code. They become env vars on the app, with the same names.

Your data. Inventory any SQLite database, uploaded files and generated state. Create a consistent backup before copying them; copying a live SQLite file can miss recent writes. Mount a volume at the path your bot uses, restore the data there, then test that it survives a redeploy. Files outside a volume are lost when the container is replaced. Keep a separate off-platform backup of important data.

At cutover, stop the VPS bot before enabling the new one with the same token. Two active copies can answer the same event twice. Check the new bot's logs and behavior before retiring the VPS.

What you give up

Check which of these VPS capabilities your bot depends on:

  • Root. You can't install system packages at runtime. Anything your app needs goes in the image — which is more reproducible and less convenient.
  • Many services on one box. A VPS can share one resource pool across a bot, database and other tools. Here each service is an app with its own resource allocation and charge.
  • Cron. There's no scheduler service; schedules live in your process.
  • Private networking. Separate apps talk over public endpoints with credentials rather than a private interface. A bound database port is public, so check whether that exposure fits your requirements.
  • Arbitrary resources. A VPS gives you its whole RAM for anything you like. Here you're inside per-account quotas.

Compare the full monthly cost

A VPS usually charges for the whole server allocation, whether the bot uses it or not. Here each app is billed for its allocated CPU, RAM and volume disk per minute. Use the pricing calculator with a full month of runtime, and count any database as a separate app. Include backup storage, domain needs and the time you spend maintaining each option.

A continuously running bot needs a funded allocation. A short first-app trial stops when it ends unless you add credit.

When a VPS is still the right answer

Keep the VPS if you need capabilities that this platform does not offer:

  • You run several unrelated things and one box is the efficient way to do it.
  • You need an allocation outside the current account limits or several processes sharing one server's resources.
  • You need kernel or system-level access, custom networking, or a service that assumes it owns the machine.
  • You want one flat bill regardless of what you add to it.
  • You prefer full control of the operating system and its configuration.

For a single bot, compare the monthly allocation and migration work with the host maintenance you currently do.

FAQ

Do I still need a systemd service or pm2?

No. The platform supervises your process and restarts it on exit, so the unit file and process manager both go away.

What happens to my certbot setup?

It's unnecessary. An HTTPS port binding gets a certificate issued and renewed for you.

Where does my bot's data go?

On a mounted volume. Take a consistent backup, restore it to the mounted path, and test the bot after a redeploy. Keep another copy off the platform.

Can I install system packages?

Not at runtime. They go in your Dockerfile, which is more reproducible but means a rebuild rather than an apt install.

Is it cheaper than a VPS?

It depends on the bot's CPU, RAM and disk allocation, plus any other services sharing your VPS. Compare a full month in the pricing calculator against your actual VPS bill.

Should I keep my VPS for other things?

If you're running several services on it, quite possibly. Move the bot and keep the box for the rest.

Wrapping up

Move the bot only after its data has been restored, its token is active in one place, and its events and logs look right. You can then stop maintaining a host for that one process while continuing to maintain the bot and its backups.