< Back to Blog

VPS vs Managed Hosting: Why I Run Everything on a $6 RackNerd Box

TL;DR / Key Takeaways

  • Managed hosting platforms charge 3-10x more than a bare VPS for services you can configure yourself in an afternoon.
  • A $6/month RackNerd VPS running Ubuntu 24, Nginx, PM2, and Postgres handles two live trading bots plus a Next.js blog without breaking a sweat.
  • You lose managed SSL, auto-scaling, and hand-holding support. You gain root access, zero vendor lock-in, and full control over what runs where.
  • The Predict & Profit Weather Bot and Econ Bot both run on this same box, live, right now.

I pay $6.18 a month for the server that runs everything.

Both trading bots. The blog. Nginx. Postgres. The whole thing. One RackNerd KVM VPS with 1 vCPU, 1.5GB RAM, and 40GB SSD. Runs 24/7. Has not gone down in the time I have been using it.

Every time I see someone asking about hosting for a Python side project and the thread fills up with "just use Railway" or "Heroku is so easy" or "Render has a free tier," I feel a specific kind of frustration. The frustration of watching people pay $20-50 a month for something a $6 box handles fine, because they got scared off by the idea of configuring a server themselves.

I am a 60-year-old data engineer. I have been SSH'ing into Linux boxes since before most of those platforms existed. So I have opinions about this.

What Managed Platforms Actually Cost

Let me be specific, because "just use Railway" sounds cheap until you price it out.

Railway's hobby plan is $5/month plus usage. A basic always-on Python service plus a Postgres instance runs closer to $10-15 a month once you account for compute and memory. That's fine for a toy project. Once you have two services running continuously, you're at $20-25 minimum.

Render's free tier puts your service to sleep after inactivity. Their "Starter" plan for persistent services is $7/month per service. Two bots plus a web server: $21/month before you add a managed Postgres instance at another $7. You're at $28 before you've done anything interesting.

Heroku is effectively dead for small projects since they killed the free tier. Their Eco dynos are $5/month but they still sleep. Basic dynos that stay awake are $7 each. A Postgres hobby instance is $5-9 depending on tier. You're at $25-30 for the same two-bot setup.

Fly.io is the current darling. Generous free tier, genuinely good product. But if you want dedicated resources and guaranteed uptime, you're paying per machine. Two bots plus a database gets expensive fast once you need memory headroom.

My RackNerd box: $6.18/month. Everything runs on it. No usage fees. No per-service billing.

The pricing comparison is not even close.

What You Give Up

I want to be honest here, because managed platforms are not stupid products. They exist because the tradeoffs are real.

You give up managed SSL renewal. On Render or Railway, HTTPS just works. On a bare VPS, you set up Certbot yourself and make sure the renewal cron doesn't break. This is a 20-minute task the first time and then you forget about it forever. But it is a task.

You give up auto-scaling. If my trading bot suddenly needed to handle 10,000 concurrent requests, my single VPS would fall over. This has never been a problem for me and probably will not be a problem for you either if you're running a small algo trading operation.

You give up support. When something breaks on a managed platform, you file a ticket and someone else figures it out. On a VPS, you Google it yourself. This is only a problem if you lack the skills or patience for it. If you're reading a blog about Python trading bots, you have the skills.

You give up one-click deploys. Managed platforms often have GitHub integration where pushing to main triggers a deploy. On a VPS, I run a shell script. Same result, more control, no magic.

That is the full list. Everything else is in your favor on a bare VPS.

The Actual Stack

Here is exactly what runs on my RackNerd box.

Ubuntu 24.04 LTS. Standard choice. Well-documented, long support window, every Stack Overflow answer applies to it.

Nginx handles all inbound HTTP/HTTPS traffic and proxies to the appropriate backend. The blog is a Next.js app running on port 3000. Nginx sits in front of it on 443.

PM2 keeps the Next.js blog process alive and restarts it on crash. I also use PM2 for anything that needs to stay running and doesn't have its own systemd unit.

The trading bots run as systemd services. I prefer systemd for anything critical. Automatic restart on failure, logging to journald, clean dependency ordering on boot. PM2 is fine for web processes. For a bot that needs to survive reboots and fire back up automatically, systemd is the right tool.

Postgres 16 runs locally. The bots log every trade decision to it. The blog reads from it for any dynamic content. All local connections over the Unix socket, no network exposure.

Python 3.12 with separate virtual environments for each bot. I do not pollute system Python. Ever.

Certbot manages the SSL cert with a systemd timer for renewal. Set it up once, never think about it again.

The Setup, Abbreviated

This is not a full tutorial, but here is the actual sequence I used.

After provisioning the VPS and SSH'ing in as root:

# Update and install basics
apt update && apt upgrade -y
apt install -y nginx postgresql python3.12 python3.12-venv certbot python3-certbot-nginx git ufw

# Configure firewall
ufw allow OpenSSH
ufw allow 'Nginx Full'
ufw enable

# Create a non-root user for running services
adduser steve
usermod -aG sudo steve

# Switch to the service user for bot setup
su - steve

# Create venvs for each bot
python3.12 -m venv ~/envs/weather_bot
python3.12 -m venv ~/envs/econ_bot

# Install dependencies in each
~/envs/weather_bot/bin/pip install -r ~/bots/weather/requirements.txt
~/envs/econ_bot/bin/pip install -r ~/bots/econ/requirements.txt

The systemd unit for the weather bot looks like this:

[Unit]
Description=Predict and Profit Weather Bot
After=network.target postgresql.service
Wants=postgresql.service

[Service]
Type=simple
User=steve
WorkingDirectory=/home/steve/bots/weather
ExecStart=/home/steve/envs/weather_bot/bin/python auto_trader.py --min-agreement 3 --min-price 0.40 --early-exit-threshold 0.70
Restart=on-failure
RestartSec=30
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

systemctl enable weather_bot.service
systemctl start weather_bot.service
journalctl -u weather_bot.service -f

That last line is how I watch it run in real time. No dashboard. No web UI. Just the journal.

For Nginx, each application gets its own server block in /etc/nginx/sites-available/, symlinked to sites-enabled/. Certbot modifies the block automatically when you run it. The actual config is boring, which is exactly what you want in infrastructure.

What Actually Breaks

I want to be real about the failure modes because pretending everything just works is not honest.

Disk fills up. GRIB2 files from NOAA AIGEFS are large. If you run the weather bot for a month without cleanup, you will notice. I have a cron job that deletes processed GRIB files after 24 hours. Add this to your setup from day one.

# /etc/cron.d/grib_cleanup
0 4 * * * steve find /home/steve/bots/weather/data/grib -name "*.grib2" -mtime +1 -delete

Postgres connections pile up if you're not careful about connection pooling in your Python code. I use a simple pool size limit and make sure cursors close properly. This is a code problem, not a hosting problem, but it surfaces faster on a low-memory VPS.

The bot crashes and stays down if you forget to enable the systemd service before rebooting. systemctl enable is not the same as systemctl start. I have made this mistake.

SSH key management matters. If you lose your private key and have no other access method, you're locked out. Keep a backup. Enable password auth temporarily when setting up if you need to, then disable it.

RAM pressure is the real ceiling. 1.5GB sounds tight but the bots are Python processes that sleep most of the time. Peak RSS for the weather bot during an AIGEFS download cycle is around 300MB. The econ bot is lighter. Postgres takes another 100-200MB. The Next.js blog at idle is around 200MB. I have headroom. If I needed to run something genuinely memory-hungry, I would upgrade to RackNerd's 2.5GB plan at about $11/month.

Why Not Just Use a Cloud Provider

I get this question. AWS, GCP, Azure all have free tiers. Why not use those?

Because free tiers have expiration dates and then you get an unexpected bill. Because AWS console UI is designed for enterprise teams, not one engineer running two bots. Because the cheapest persistent EC2 instance that actually stays on is a t3.micro at around $8-9 a month, before you add EBS storage, data transfer, and Elastic IP costs.

More than the price, it's the complexity tax. Every AWS service touches three other AWS services. You end up configuring IAM roles just to let your EC2 instance write to S3. You end up with six CloudWatch alarms that email you at 3am. You end up paying for a NAT gateway you forgot about.

A VPS is a computer on the internet. It works like a computer. You install things on it. They run. That's the whole model.

I spent 30 years building on enterprise infrastructure. I know how to use AWS. I choose not to for this project because I do not want the overhead, and a $6 VPS does not need it.

The Part Nobody Talks About

There is a psychological benefit to owning your infrastructure that I did not expect.

When the bot has an issue, I SSH in and look at the logs. I do not file a support ticket. I do not wait for a platform status page to update. I know exactly what is running, where it is running, and why it is doing what it is doing.

After 30 years of being one engineer among many on systems built by committees, there is something genuinely satisfying about having a machine that does what I told it to do and nothing else.

The bot runs on it right now. The blog you are reading is served from it. The Postgres database with every trade decision the bot has ever made is on it. Total monthly cost: less than two cups of coffee at an airport.

If you have Python skills and basic Linux comfort, you do not need more than this to run something real.

The honest truth is that managed hosting is fine if your time is worth more than the price difference. But if you are a developer building a side project, the setup cost is a one-time afternoon, and the savings compound every month after that. I have not regretted it once.