# Linux for Traders

> The Linux skills traders need to run bots on servers: the command line, files, processes, services with systemd, logs, scheduling, SSH security and updates.

Source: https://learn.tradelabsai.com/infrastructure/linux-for-traders/  
Track: Trading Infrastructure · Level: Advanced · Updated: 2026-10-03  
Publisher: TradeLabs AI (https://tradelabsai.com). Education, not financial advice.  
Cite as: TradeLabs Learn, "Linux for Traders", https://learn.tradelabsai.com/infrastructure/linux-for-traders/

Most of the world's servers run Linux, including nearly all trading systems at professional firms and most cloud servers that retail traders rent. You do not need to become a systems administrator to run a trading bot, but a working knowledge of the Linux command line lets you deploy code, keep it running, read its logs and fix problems without guesswork. This lesson covers the essentials, in the order you will need them.

## Connecting with SSH

SSH (Secure Shell) gives you a command line on a remote server.

```
ssh trader@203.0.113.10
```

Use SSH keys instead of passwords, and disable password login on the server. Keep your private key safe; anyone with it can log in.

## Core commands

| Command | Does |
|---|---|
| `ls`, `cd`, `pwd` | List, change and show directories |
| `cat`, `less`, `tail -f` | View files; follow a log as it grows |
| `cp`, `mv`, `rm`, `mkdir` | Copy, move, delete files, make folders |
| `grep` | Search text, such as errors in logs |
| `ps`, `top`, `htop` | See running processes and resource use |
| `df -h`, `du -sh` | Disk space |
| `free -h` | Memory |
| `chmod`, `chown` | File permissions and ownership |
| `sudo` | Run a command as administrator |

## Running a bot as a service

A bot started in an SSH session stops when you disconnect. A systemd service runs in the background, starts at boot and restarts after crashes.

```
# /etc/systemd/system/mybot.service
[Unit]
Description=My trading bot
After=network-online.target

[Service]
User=trader
WorkingDirectory=/home/trader/bot
EnvironmentFile=/home/trader/bot/.env
ExecStart=/home/trader/bot/.venv/bin/python main.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
```

Then run `sudo systemctl enable --now mybot` to start it, `systemctl status mybot` to check it and `journalctl -u mybot -f` to follow its logs.

**Example: Restart loops**
A bot crashes at startup because its API key expired. With `Restart=on-failure` and `RestartSec=5`, systemd restarts it every 5 seconds, about 720 times an hour, each time sending a failed login to the broker. Some brokers may temporarily block the key or the server's address after repeated failures. Adding `StartLimitIntervalSec=300` and `StartLimitBurst=5` in the Unit section stops restarts after five failures in five minutes, and a monitoring alert on the service state tells the trader to fix the key. See [Alerts, Error Handling and Reconnection](https://learn.tradelabsai.com/algo-trading/error-handling/).

## Scheduling tasks

Cron runs commands on a schedule, such as downloading data after the close.

```
# minute hour day month weekday command
30 21 * * 1-5 /home/trader/bot/.venv/bin/python /home/trader/bot/download.py
```

Remember that cron uses the server's time zone; set servers to UTC and convert schedules accordingly. See [Timestamps, Time Zones and Daylight Saving](https://learn.tradelabsai.com/programming/timestamps-and-time-zones/).

## Logs and disk space

Logs grow forever unless rotated. Use logrotate or systemd's journal limits, and alert when disk usage passes a threshold. A full disk can stop a database and crash a bot. See [Monitoring and Logging Systems](https://learn.tradelabsai.com/infrastructure/monitoring-and-logging-systems/).

## Security basics

| Practice | Why |
|---|---|
| SSH keys only, no root login | Blocks password guessing |
| Firewall (such as ufw) allowing only needed ports | Reduces attack surface |
| Automatic security updates | Patches known vulnerabilities |
| A non root user for the bot | Limits damage if compromised |
| Secrets in protected files, not code | Keeps keys out of repositories |
| fail2ban or similar | Blocks repeated failed logins |

## Clock synchronisation

Make sure time synchronisation is active (`timedatectl status`). A drifting clock corrupts timestamps and can cause signed API requests to be rejected. See [Clock Synchronization and PTP](https://learn.tradelabsai.com/infrastructure/clock-synchronization-and-ptp/).

## Deploying updates safely

When you change your bot, avoid editing files directly on the live server. Commit the change to git, pull it on the server, install any new requirements and restart the service during a quiet period, never with open orders you cannot watch. Keep the previous version easy to restore, for example by tagging releases, so a bad update can be rolled back in one command. Check the logs right after the restart to confirm the bot connected, loaded its state and reconciled positions with the broker before it trades. A short written checklist for deploys prevents the rushed mistakes that cause most outages. See [Developing, Testing and Monitoring Algorithms](https://learn.tradelabsai.com/algo-trading/algorithm-development/) and [Trade Accounting and Reconciliation](https://learn.tradelabsai.com/industry/trade-reconciliation/).

## Frequently asked questions

### Do I need Linux to run a trading bot?

Not strictly, but most servers run Linux, and it is the most common, cheapest and best supported choice for bots that run unattended.

### How do I keep a Python bot running on Linux?

Run it as a systemd service with automatic restart, or in a container managed by a supervisor. See [Docker and Kubernetes](https://learn.tradelabsai.com/infrastructure/docker-and-kubernetes/).

### How do I see my bot's logs on Linux?

For a systemd service, use `journalctl -u servicename -f`; for log files, use `tail -f` on the file.

Next, learn how networks affect trading in [Networking for Traders](https://learn.tradelabsai.com/infrastructure/networking-for-traders/).

## Continue learning

- Next lesson: [Networking for Traders](https://learn.tradelabsai.com/infrastructure/networking-for-traders/)
- Previous lesson: [VPS, Cloud and Bare-Metal Servers](https://learn.tradelabsai.com/infrastructure/vps-cloud-and-bare-metal-servers/)
- Related: [VPS, Cloud and Bare-Metal Servers](https://learn.tradelabsai.com/infrastructure/vps-cloud-and-bare-metal-servers/): Compare VPS, cloud and bare metal servers for running trading bots and systems. Learn costs, latency, reliability, choosing a region and basic server setup.
- Related: [Networking for Traders](https://learn.tradelabsai.com/infrastructure/networking-for-traders/): The networking basics behind trading: latency and distance, TCP versus UDP, multicast market data, packet loss, jitter and practical ways to improve connectivity.
- Related: [Docker and Kubernetes](https://learn.tradelabsai.com/infrastructure/docker-and-kubernetes/): How containers with Docker package trading bots and research environments, when Kubernetes helps, and when simpler setups are better for latency and reliability.
- Related: [Monitoring and Logging Systems](https://learn.tradelabsai.com/infrastructure/monitoring-and-logging-systems/): The tools behind trading observability: structured logs, metrics, dashboards, tracing and alerting with Prometheus, Grafana and log stacks, and how to set them up.
- Related: [Building Trading Bots](https://learn.tradelabsai.com/programming/building-trading-bots/): How to build a trading bot that is safe to run: the main components, an event loop, state and position tracking, risk checks, logging and a staged path to live.