How do I keep my exchange API keys safe on a VPS?

Create API keys with the least privilege your strategy needs, disable withdrawal permission, and add an IP allowlist tied to your server address. Store the keys in an environment file readable only by the bot user (chmod 600), never hard-coded in your source, and log in over SSH keys rather than passwords.

How to Run a Trading Bot 24/7 on a VPS

Q: How do I keep my bot alive if it crashes or the server reboots?

Use a process manager instead of a bare terminal. A systemd service with Restart=always relaunches the bot on crash and starts it automatically after a reboot. Node.js users can use pm2 with pm2 startup, and Docker containers can use --restart unless-stopped for the same effect.

Q: How much CPU and RAM does a trading bot need?

A single bot polling a few markets is light: 2 dedicated vCPUs and 4 GB RAM handle it comfortably. Running several strategies, indicators, or backtests at once benefits from 4 vCPUs and 8 GB or more. Because ApexVPS resources are dedicated, you get the full core with no noisy-neighbour slowdown.

Written by the ApexVPS team • Last updated: July 2026 • 8 min read

Automated strategies have to react to the market whether or not you are awake. To run a trading bot on a VPS 24/7 is the standard way to keep it online: a virtual private server stays powered on, connected, and physically close to your exchange around the clock, so your bot never misses a signal because a laptop went to sleep or a home connection dropped. This guide walks through why a VPS beats a home PC, how to pick a location, how to keep the process alive, and how to keep your keys and logs under control. It is technical guidance only, not financial advice, and it stays neutral about which bot framework or strategy you use.

Why a VPS Beats a Home PC for Bots

A trading bot is a long-running process that must not stop at the wrong moment. A home computer is a poor host for three practical reasons.

Uptime and always-on execution

Home machines sleep, install updates, and reboot on their own schedule. Power cuts and router restarts add more gaps. A VPS runs in a data center with redundant power and networking and a published availability target — ApexVPS plans carry a 99.9% to 99.99% SLA depending on tier — so the process that places and manages your orders keeps running while you sleep, travel, or work.

Latency to your exchange

Every order and market-data update travels a network path between your server and the exchange. The shorter that path, the faster your bot sees fills and reacts. A residential connection routes through your ISP first; a well-placed server sits on fast backbone links. ApexVPS runs 39 data centers with a low-latency network in major regions, which shortens the round trip for order routing and quote updates.

No interruptions

On a VPS you control when maintenance happens. There are no forced OS updates mid-session, no antivirus scans hogging the CPU, and no family member closing the lid on your laptop. The bot has a stable, dedicated environment that only changes when you change it.

Choose a Location Near Your Exchange

Latency is dominated by physical distance, so the single biggest lever is picking a data center close to where your exchange or broker is hosted. Many crypto venues run their matching engines in or near a handful of hubs, and stock and futures venues cluster around specific metros. As a rule of thumb, match your server region to the exchange:

Europe-focused venues: Frankfurt, London, or Amsterdam.
US markets: New York, Miami, or Los Angeles.
Asia-Pacific: Tokyo, Singapore, or Sydney.

If you are unsure, test round-trip time with a simple ping or mtr to the exchange API host from a couple of candidate regions and keep the lowest. Our dedicated pages on a VPS built for trading bots and a crypto-friendly VPS with no-card checkout list the available regions in detail.

Keep the Bot Alive 24/7

Starting your bot in a plain SSH session is not enough — when the session closes, the process dies. Use one of the following to keep it running and to restart it automatically after a crash or reboot.

tmux or screen (quick start)

A terminal multiplexer keeps your process running after you disconnect. It is the fastest way to get going while you test:

sudo apt update && sudo apt install -y tmux
tmux new -s bot
# start your bot inside the session, e.g.
python3 main.py
# detach without stopping it: press Ctrl-b, then d
# reattach later:
tmux attach -t bot

tmux is great for interactive testing but does not restart a crashed bot on its own. For anything you leave running, move to a process manager below.

systemd (recommended on Linux)

systemd is built into modern Ubuntu and Debian and will relaunch your bot on failure and start it on boot. Create a unit file:

# /etc/systemd/system/tradingbot.service
[Unit]
Description=Trading Bot
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=botuser
WorkingDirectory=/home/botuser/bot
ExecStart=/usr/bin/python3 /home/botuser/bot/main.py
Restart=always
RestartSec=5
EnvironmentFile=/home/botuser/bot/.env

[Install]
WantedBy=multi-user.target

Then enable and start it:

sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
sudo systemctl status tradingbot

Restart=always brings the bot back after a crash, and enable makes it start automatically after any reboot.

pm2 for Node.js bots

If your bot is written in JavaScript or TypeScript, pm2 is a simple process manager with built-in logs and restart-on-boot:

npm install -g pm2
pm2 start bot.js --name trading-bot
pm2 save
pm2 startup   # run the command it prints, then reboot to verify

Docker for reproducible deployments

Containers package your bot with its exact dependencies so it runs the same everywhere. The --restart policy handles crashes and reboots:

docker run -d --name trading-bot \
  --restart unless-stopped \
  --env-file /home/botuser/bot/.env \
  my-bot:latest

Containers also make upgrades and rollbacks clean; the official Docker documentation covers building images and managing restart policies in depth.

Rotate and Manage Logs

A bot that runs for weeks can fill a disk with log output and eventually crash the whole server. Rotate logs so old files are compressed and pruned automatically. On Ubuntu and Debian, logrotate is already installed — add a rule for your bot:

# /etc/logrotate.d/tradingbot
/home/botuser/bot/logs/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
}

If you run under systemd, the journal already captures output; cap its size in /etc/systemd/journald.conf with a setting such as SystemMaxUse=500M. Either way, review logs periodically and alert on errors so a silent failure does not go unnoticed for days.

Secure the Bot and Your API Keys

Your VPS holds credentials that can move money, so treat security as part of the setup, not an afterthought. The OWASP principle of least privilege applies directly here.

Scope your exchange keys. Create API keys with only the permissions the strategy needs. Disable withdrawal rights entirely, and where the exchange supports it, bind the key to your server's IP address.
Never hard-code secrets. Keep keys in an environment file loaded at runtime, not in source control. Restrict it to the bot user: chmod 600 /home/botuser/bot/.env.
Run as a non-root user. Create a dedicated account for the bot so a compromised process cannot take over the whole box.
Harden SSH. Log in with SSH keys, disable password authentication, and keep the system patched with sudo apt update && sudo apt upgrade.
Close unused ports. A simple firewall keeps the attack surface small:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

ApexVPS gives you full root access plus DDoS protection and optional private networking, so you can layer these controls without fighting the platform.

Size Your VPS Resources

Bots are usually light on CPU but sensitive to being starved at the wrong moment, which is exactly what oversold shared hosting does. Because ApexVPS resources are truly dedicated — no overselling, no noisy neighbours — the cores you buy are the cores you get. A rough guide:

One bot, a few markets: the Starter Pro plan (2 dedicated vCPU, 4 GB RAM, 80 GB NVMe SSD) is comfortable.
Several strategies or backtesting: the Business plan (4 vCPU, 8 GB RAM, 160 GB NVMe, 1 dedicated IPv4) adds headroom and an IP you can allowlist on your exchange.
A desk of bots with private networking: the Enterprise plan (8 vCPU, 16 GB RAM, NVMe RAID, 2 dedicated IPv4) suits heavier, multi-service setups.

Watch htop and your latency for a week after launch and scale up only if you see real contention. You can compare specs side by side on our VPS plans and pricing page.

Getting Started

Setup is quick: pick a plan, choose a region near your exchange, and provide an email — no name, address, or KYC. Checkout is crypto-only through OxaPay, accepting Bitcoin, Ethereum, USDT and 30+ cryptocurrencies, with no credit card or bank account required. Once your payment confirms on-chain, provisioning begins and you get full root access to install your bot, add a systemd service, and go live.

Ready to keep your bot online 24/7? Explore our VPS for trading bots →

Frequently Asked Questions

Why run a trading bot on a VPS instead of my home PC?

A VPS stays powered on and connected around the clock in a data center with redundant power and networking. Unlike a home PC, it is not affected by sleep settings, forced OS reboots, power cuts, or an ISP that drops the connection, so your bot keeps running without interruption.

How do I keep my bot alive if it crashes or the server reboots?

Use a process manager rather than a bare terminal. A systemd service with Restart=always relaunches the bot on crash and starts it after a reboot. Node.js users can use pm2 with pm2 startup, and Docker containers can use --restart unless-stopped for the same effect.

How much CPU and RAM does a trading bot need?

A single bot polling a few markets is light — 2 dedicated vCPUs and 4 GB RAM handle it comfortably. Running several strategies, indicators, or backtests at once benefits from 4 vCPUs and 8 GB or more. Since the resources are dedicated, you get the full core with no noisy-neighbour slowdown.

How do I keep my exchange API keys safe?

Create keys with the least privilege the strategy needs, disable withdrawal permission, and add an IP allowlist tied to your server address. Store keys in an environment file readable only by the bot user, never hard-coded in your source, and log in over SSH keys rather than passwords.