One can absolutely run Python code in the cloud with low/zero cost, and existing VPS is actually the best option for persistent (“daemon”) execution. Below is a detailed comparison of all options, with clear recommendations based on your scenario.
β Existing VPS is the PERFECT Solution (Zero Cost Beyond Existing Server)
Since you already have a VPS with Python installed, this is the most cost-effective and reliable option for running code as a daemon. No new costs, full control, and no cloud vendor limitations.
Spoiler: Step by Step setup at VPS.
How to Run as a Daemon on Your VPS:
- Use
systemd
(Modern Linux – Recommended)
Create a service file (e.g.,/etc/systemd/system/myapp.service
):
[Unit]
Description=My Python App
After=network.target
[Service]
User=youruser
WorkingDirectory=/path/to/your/app
ExecStart=/usr/bin/python3 /path/to/your/app/main.py
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
Then:
sudo systemctl enable myapp # Auto-start on boot
sudo systemctl start myapp # Start now
- Alternative:
nohup
(Quick & Dirty)
nohup python3 main.py > output.log 2>&1 &
(Less reliable β process dies if shell exits unexpectedly)
β Why VPS wins:
Feature | VPS | Cloud Alternatives |
---|---|---|
Cost | $0 (already paid for) | Free tiers often limited |
Uptime | 24/7 persistent | Cloud free tiers time out |
Control | Full root access | Restricted environments |
Security | Your own network/firewall | Shared infrastructure |
No surprises | No rate limits | Clouds throttle free tier |
Setup time | 5 minutes | Varies (often complex) |
π‘ Pro Tip: Add
Restart=always
insystemd
to auto-recover from crashes. Monitor logs withjournalctl -u myapp -f
.
β οΈ Cloud Options: Free Tiers Exist, But NOT for Daemons
Cloud “free tiers” are designed for short-lived tasks (CI/CD, batch jobs) β not persistent services. Here’s why they won’t work for your daemon use case:
Service | Free Tier Limitation for Daemons | Cost Beyond Free Tier |
---|---|---|
Google Colab | β Sessions disconnect after 12h (even with Pro) | $10/mo for persistent GPU |
GitHub Actions | β Jobs time out after 6h (max) | Free for public repos |
AWS Lambda | β Max 15m execution time per request | $0.20/mo for 1M requests |
Google Cloud Run | β Scales to zero after 5-15m of inactivity | $0.000024/vCPU-sec |
Fly.io | β οΈ 3 shared-CPU VMs free (but sleeps after 30m idle) | $5.50/mo for persistent VM |
Key Problems with Cloud for Daemons:
- Forced Sleep/Timeout: All free tiers stop your process after minutes/hours.
- No True Background Processes: Clouds assume stateless HTTP requests.
- Cold Starts: Your code restarts from scratch on every request (slow!).
- Hidden Costs: Free tiers often exclude databases, storage, or network egress.
π« Critical Warning: Trying to hack around this (e.g., pinging your Cloud Run app hourly to keep it awake) violates ToS and gets your account banned.
π When to Use Cloud Free Tiers (Instead of Your VPS)
Only use these for non-persistent tasks:
- GitHub Actions: Run tests on
git push
(free for public repos) - Google Colab: Train ML models interactively (disconnects after 12h)
- AWS Lambda: Process uploaded files (max 15m runtime)
- Fly.io: Host a tiny public API (sleeps when idle)
π§ Step-by-Step: Best Setup for Your VPS
Since you already own the infrastructure, here’s the optimal path:
- Install dependencies on your VPS:
sudo apt update && sudo apt install -y python3-venv git
- Deploy your code:
git clone https://github.com/your/project.git /opt/myapp
cd /opt/myapp
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
- Create a systemd service (as shown above)
- Secure it (critical!):
- Set up a firewall:
sudo ufw allow 22 && sudo ufw enable
- Use a reverse proxy (Nginx) if exposing HTTP:
nginx # /etc/nginx/sites-enabled/myapp server { listen 80; server_name your-domain.com; location / { proxy_pass http://localhost:8000; # Your app port } }
- Monitor:
# Check logs
journalctl -u myapp -f
# Auto-restart on crashes
sudo systemctl edit myapp # Add RestartSec=5 if not set
π Security Note: Always run your daemon under a non-root user (create
appuser
withsudo adduser appuser
), and usesudo systemctl edit myapp
to setUser=appuser
in the service file. Never run daemons as root!
π‘ When to Consider Cloud (Rare Cases)
Only if:
- You need global scalability (millions of users)
- You require managed databases (e.g., AWS RDS)
- Your VPS is underpowered for the task
- You’re building a public-facing API (use Cloud Run + Cloud Scheduler ping)
For 95% of personal projects, your VPS is superior. Cloud free tiers are marketing traps for persistent services.
π Cost Comparison (1 Year)
Solution | Cost | Uptime | Setup Effort | Best For |
---|---|---|---|---|
Your VPS | $0 | 99.9%+ | Low (5 min) | Daemons, long-running apps |
Google Cloud Run | $5/mo* | 95% | Medium | HTTP APIs (with sleep) |
AWS EC2 T4g.nano | $3.50/mo | 99.5% | High | Full VM control (paid) |
GitHub Actions | $0 | 0% | Medium | CI/CD only (not daemons) |
* After free tier β actual cost depends on traffic. Sleep prevention adds cost.
β Final Recommendation
Use your VPS with systemd
β it’s:
- Free (you’re already paying for the server)
- More reliable than cloud free tiers
- Faster (no cold starts)
- Simpler to manage
- Fully controllable (no vendor restrictions)
Cloud free tiers are designed to upsell you to paid plans β they intentionally make persistent execution difficult. Since you have a VPS, you’ve already won the cost battle. Just set up a proper systemd service and sleep easy knowing your code runs 24/7.