Ensuring Uninterrupted Bot Operation
After launching your bot on a cloud server, three hours later it crashed — Killed in the logs. Cause: out of memory. The trading bot loaded market data into RAM, and the OOM killer terminated the process. Without auto-restart, it stayed dead until morning. This happens often: users focus on the trading logic but neglect the infrastructure.
We’ve been setting up bots for 5 years. Along the way we’ve hit WebSocket disconnects, key leaks, and wrong server choices. We’ve developed a simple pattern: a VPS with headroom, systemd for process management, Telegram alerts, and no Docker unless necessary.
Choosing a VPS for Your Trading Bot
The key is a server with 2 vCPU and 4 GB RAM. For scalping, the server must be near the exchange. For Binance, AWS Tokyo (latency ~10 ms) or Vultr Singapore (15 ms) work well. Latency between Europe and Asia exceeds 200 ms — deadly for HFT. We recommend Hetzner for algorithmic trading: it’s 2–3× cheaper than AWS, with 20–30 ms higher latency, which is acceptable for minute‑candle strategies. Hetzner VPS starts at €3.99/month for a 2 vCPU, 4 GB RAM instance. For Binance, DigitalOcean (NYC region) gives ~40 ms to exchange servers. Costs: Hetzner €3.99/mo, DigitalOcean $6/mo, AWS ~$10/mo. Savings can be up to 60% by choosing Hetzner over AWS.
| Parameter | Minimum | Recommendation |
|---|---|---|
| CPU | 1 vCPU | 2 vCPU |
| RAM | 1 GB | 4 GB for multi‑currency bots |
| Disk | 20 GB SSD | 40 GB SSD (logs take space) |
| Network | Any | Proximity to exchange: <50 ms |
| Provider | DigitalOcean, Hetzner | Vultr for Binance, AWS for multi‑exchange |
Systemd vs Docker for Bot Management
For a single bot, Docker adds 5–10% CPU/RAM overhead and complicates debugging. systemd is a built‑in Linux init system — reliable and minimal. Here’s the unit file we use:
[Unit] Description=Trading Bot After=network-online.target Wants=network-online.target [Service] Type=simple User=bot WorkingDirectory=/home/bot/trading-bot EnvironmentFile=/home/bot/trading-bot/.env ExecStart=/home/bot/.venv/bin/python main.py Restart=on-failure RestartSec=10 StandardOutput=journal StandardError=journal MemoryMax=512M CPUQuota=80% [Install] WantedBy=multi-user.target systemd documentation states thatMemoryMaxlimits memory via cgroup v2, preventing OOM kill.Restart=on-failureensures restart only after an abnormal exit, leaving intentional stops untouched.
After creating the file:
systemctl daemon-reload systemctl enable trading-bot systemctl start trading-bot journalctl -u trading-bot -f Secure API Key Storage
Never put keys in code — that’s the most common cause of leaks. Use environment variables. Example .env file with permissions 600:
# /home/bot/trading-bot/.env BINANCE_API_KEY=xxx BINANCE_SECRET=yyy TELEGRAM_BOT_TOKEN=zzz TELEGRAM_CHAT_ID=123456 chmod 600 /home/bot/trading-bot/.env chown bot:bot /home/bot/trading-bot/.env For extra security, you can store keys in AWS Secrets Manager or 1Password CLI, but for a single bot .env with firewall and minimal permissions is enough.
How to Monitor Your Bot with Telegram Alerts
The minimum set is Telegram alerts and heartbeat. Asynchronous code sends a message on start, on errors, and once per hour (heartbeat). If the message stops coming — the bot is down. Python example with httpx:
import httpx, asyncio TELEGRAM_URL = f"https://api.telegram.org/bot{TELEGRAM_TOKEN}/sendMessage" async def send_alert(message: str, level: str = "INFO"): prefix = {"INFO": "ℹ️", "WARN": "⚠️", "ERROR": "🚨"}.get(level, "") await httpx.AsyncClient().post(TELEGRAM_URL, json={ "chat_id": TELEGRAM_CHAT_ID, "text": f"{prefix} *{level}*\n{message}", "parse_mode": "Markdown" }) # On start await send_alert("Bot started", "INFO") # Heartbeat every hour async def heartbeat(): while True: await asyncio.sleep(3600) await send_alert(f"Heartbeat: balance={await get_balance()}", "INFO") Additionally, we use UptimeRobot for external checks: it pings the IP and sends SMS if no response. Using asynchronous I/O with uvloop reduces overhead and improves WebSocket reconnection handling.
Updating the Bot Without Downtime
Deploy a new version:
cd /home/bot/trading-bot git pull origin main /home/bot/.venv/bin/pip install -r requirements.txt systemctl restart trading-bot Systemd waits for the current iteration to finish before starting the new process. For critical updates, use systemctl restart --check — but with Restart=on-failure the new process starts without data loss.
10-Step Bot Deployment
- Choose a VPS: 2 vCPU, 4 GB RAM, region close to exchange.
- Install Ubuntu 22.04 LTS, update packages.
- Create user
botwithout sudo. - Clone the bot repository.
- Install Python 3.11 and dependencies in a virtual environment.
- Create
.envwith API keys and Telegram token. - Place the systemd unit file and enable the service.
- Set up Telegram alerts: start, errors, heartbeat every hour.
- Check the log:
journalctl -u trading-bot -f. - Configure external monitoring (UptimeRobot).
After these steps, the bot runs 24/7 with automatic restart. If something goes wrong, Telegram will notify you.
What's Included in the Setup
- Documentation of server configuration and environment variables
- SSH access with secured key pairs
- Telegram alerts configured with heartbeat and error notifications
- 7-day post-deployment support for any issues
- Detailed runbook for maintenance and updates
Common Self-Setup Pitfalls
Click to expand common pitfalls
Common issues: no auto-restart (bot stays dead), API keys in code (leak on GitHub), weak server (OOM kill when data grows), no monitoring (learn about a crash a week later). To minimize risks, use the template above — it’s battle‑tested on hundreds of production deployments.
If you’re unsure about your infrastructure, order a turnkey setup from us. We’ll prepare the server, deploy the bot, and configure monitoring in 2–4 days. Our turnkey deployment includes server setup, bot configuration, monitoring, and documentation—delivered in 2–4 days. Contact us for a free consultation to assess your project.







