Bot Hosting: The Best Servers for Running Bots 24/7

Your bot works. It scrapes, it posts, it answers Discord pings, right up until you close the laptop to catch a train and every task stops mid-run. That is the whole problem with bot hosting on the machine you also use for daily life: the process only stays alive while the lid is open and the home Wi-Fi holds. Leave it running off your home connection around the clock instead and the fix quietly becomes the next bug. Your residential IP is now the one address hammering an API a thousand times an hour, and the rate-limiter memorizes it.

The fix is boring, which is exactly why it holds: a cheap Linux box somewhere else that never sleeps.

What a bot host actually needs

Strip the requirement down and the list is short. The box has to stay up without you babysitting it, which means genuine uptime and a provider that migrates hardware on a maintenance window instead of whenever it feels like it. It needs its own dedicated IPv4, held by your box and nobody else’s. It needs enough RAM to hold your runtime plus headroom, which for a single Python or Node worker is modest. And it needs root, or at least real sudo, so you own the init system and the firewall instead of renting a locked sandbox that argues with you.

The dedicated IP matters more than beginners expect. On a shared or recycled address you inherit whatever the previous tenant did to it, so a target can be blocking your “brand-new” server before your first request even leaves the box. Most providers hand you a dedicated v4 by default now; confirm that instead of assuming it.

The marketing wants you picturing availability zones, load balancers, and managed Kubernetes. For one worker that has to stay online, that is not the job. The job is a Linux box that stays powered, keeps its IP, and answers SSH at 3 a.m.

None of that requires a hyperscaler.

An AWS or GCP bill assumes you have a platform team to tune it and a finance department that enjoys line items named NAT Gateway. For a bot that just needs a pulse, the ~$5 to $6 entry tier at any of the independents (usually 1 vCPU and about a gigabyte of RAM) does the identical job for the price of a coffee, and you can read the invoice without a decoder ring. This piece stops at that box; the proxies, the automation, and the monitoring all live on the rest of the stack I run in production.

The bot hosting ranking

Three providers between them handle everything a bot box needs, from the first one you spin up to the fleet you eventually grow into. Here is how they sort by what actually breaks at 3 a.m., not by what the homepage promises.

Provider	Best for	Price posture	Verdict
DigitalOcean	Your first box, clean docs	~$6 entry, flat and predictable	The safe default. Boring on purpose.
Vultr	Fast spin-ups, region choice	~$5 entry, hourly billing	Best when latency to the target matters.
Contabo	RAM-heavy boxes, worker fleets	Cheapest RAM per dollar	For hungry, multi-worker setups.

Disclosure: the three provider links below are affiliate links. They pay me a bounty if you sign up; they do not pay me to call a bad box a good one, and this is the same ranking you would get from me off the record.

Which one you want depends entirely on what the bot does.

Start with the safe choice. For a first box, DigitalOcean is the droplet every tutorial hands you, and that ubiquity is the actual feature: whatever breaks at 2 a.m., someone has already posted the exact fix on a forum. You pay a small premium over the rock-bottom hosts for documentation that does not cost you an entire evening.

Speed of iteration is a different axis. When your target sits behind a geo-aware rate-limiter, Vultr lets you pin the instance to a region right next to it and has it booting in a minute or two, which turns region placement from a research project into a dropdown.

Scale changes the math again. Once a single box stops being enough because you are running a fleet of hungry workers, Contabo hands you more RAM per dollar than anything else on this list, and the tradeoff is a network that is adequate rather than exceptional. For a queue of scrapers that are memory-bound and not latency-bound, you take that tradeoff every single time.

Spin up a 24/7 bot box in ten minutes

Most of these ten minutes are spent waiting on apt. The sequence below creates a DigitalOcean droplet from your laptop with doctl, hardens the login, and drops your worker onto the box. Swap the provider CLI or click through the control panel if you prefer; the shape is identical everywhere.

# 1. Create the box from your laptop. Or click it in the panel; same result.
doctl compute droplet create bot-01 \
  --region nyc1 \
  --size s-1vcpu-1gb \
  --image ubuntu-24-04-x64 \
  --ssh-keys "$(doctl compute ssh-key list --format ID --no-header | head -n1)"

# 2. First login is root. This is the only time you should use it.
ssh root@203.0.113.10

# 3. Running a bot as root is how a bad dependency becomes a rooted server.
#    Make a plain user, hand it sudo, copy your key across.
adduser --disabled-password --gecos "" botrunner
usermod -aG sudo botrunner
rsync --archive --chown=botrunner:botrunner ~/.ssh /home/botrunner/

# 4. Install only the runtime you need. Python here; use Node if that's your worker.
apt-get update && apt-get install -y python3-venv git

# 5. Become the user and pull the worker down.
su - botrunner
git clone https://github.com/you/your-worker.git
cd your-worker
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt

That gets the code onto a machine that stays on when your laptop does not.

It does not yet survive a reboot, and it will reboot.

Keep it alive: a systemd unit

A process you started by hand dies with your SSH session, or the first time the box reboots for a kernel patch. You want the init system to own it so it restarts on its own, every time, without you present. Write one unit file.

# /etc/systemd/system/bot.service
[Unit]
Description=Long-running worker (scraper, poster, whatever it is)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=botrunner
WorkingDirectory=/home/botrunner/your-worker
ExecStart=/home/botrunner/your-worker/.venv/bin/python worker.py
Restart=always
RestartSec=5
# Cap the worker so one runaway loop can't OOM the entire box.
MemoryMax=768M

[Install]
WantedBy=multi-user.target

Then enable it so it starts immediately and on every boot, and confirm it actually came up:

sudo systemctl daemon-reload
sudo systemctl enable --now bot.service
systemctl status bot.service --no-pager

Restart=always with RestartSec=5 means a crash costs about five seconds of downtime and recovers itself before you would even notice. Reaching for pm2 or a screen session instead is not laziness so much as a missing requirement: neither one comes back after the machine reboots without extra glue you have to write and remember. systemd already is that glue, because restarting services at boot is the entire reason the init system exists. Run pm2 on top when you genuinely want its process dashboard, and keep the systemd unit underneath as the thing that guarantees the lights come back.

Don’t let the box IP get you banned

Here is what the VPS landing page keeps out of the hero shot: the clean IP they sell you is clean the way a rental car is clean. A few thousand people drove it before you, and the ASN is the license plate every anti-bot vendor reads on sight. Point a scraper at a target that fingerprints traffic from that datacenter address and you will be collecting 403s inside the hour, no matter how polite your request headers are.

The box buys you uptime. A believable identity is a second purchase entirely, and it rarely comes from the same vendor. For anything touching a site that profiles its visitors, route the worker’s outbound calls through a pool of rotating residential IPs and let the exit addresses churn while your server sits perfectly still. The datacenter runs the process; the residential layer wears the face.

What the box actually runs is a separate question again. On most of these servers the real payload is some flavor of no-code automation or an AI agent doing the actual work, with the VPS as the unglamorous thing that keeps it breathing between runs. Get the hosting stable and forgettable first, then make the automation on top as clever as you like.

Edge cases & troubleshooting

The OOM killer ate your worker. The service keeps flapping and dmesg is full of Out of memory: Killed process. Your 1 GB box ran out of headroom under load. Either keep the MemoryMax line from the unit above, so systemd restarts the worker cleanly instead of the kernel shooting something at random, or move up one instance size. On a fleet, this is the exact moment those cheap RAM-heavy boxes start paying for themselves.

The process dies on every deploy. You git pull, the old worker is still holding the port or a lockfile, and the new one refuses to start. Stop hand-rolling kill pipelines. Run sudo systemctl restart bot.service as the last line of your deploy, and add an ExecStartPre= step if migrations have to run first. Your unit file is the deploy script whether you treat it like one or not.

Cron jobs fire at the wrong hour. Fresh cloud images ship set to UTC, so the 9 a.m. job you wrote runs whenever UTC feels like it, then drifts by another hour when daylight saving flips. Pin it with sudo timedatectl set-timezone America/New_York, or keep the whole box on UTC and do the conversion inside your code so the clock never surprises you twice a year.

The provider suspends your box. A scraper hammering one host, or outbound spam from a worker somebody compromised, gets flagged fast, and most providers suspend first and read your appeal later. Read the acceptable-use policy before you aim anything aggressive at a third party, throttle your outbound rate, and assume their definition of abuse is stricter than yours. Keep a copy of the unit file and your provisioning script in the repo. A suspended box then costs you a rebuild measured in minutes, and systemctl enable --now bot.service on a fresh instance drops you right back where you were.