How to Deploy a Trading Bot on a Cloud Server

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. T

Blockchain Development Services

Frequently Asked Questions

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1451
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1309
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    1005
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1270
  • image_logo-advance_0.webp
    B2B Advance company logo design
    719
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    1011

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 that MemoryMax limits memory via cgroup v2, preventing OOM kill. Restart=on-failure ensures 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

  1. Choose a VPS: 2 vCPU, 4 GB RAM, region close to exchange.
  2. Install Ubuntu 22.04 LTS, update packages.
  3. Create user bot without sudo.
  4. Clone the bot repository.
  5. Install Python 3.11 and dependencies in a virtual environment.
  6. Create .env with API keys and Telegram token.
  7. Place the systemd unit file and enable the service.
  8. Set up Telegram alerts: start, errors, heartbeat every hour.
  9. Check the log: journalctl -u trading-bot -f.
  10. 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.