05 · Runtime & Automation Environment

Your analysis scripts are written; next comes making them run long-term, stably, and automatically — and this step hides no fewer pitfalls than strategy itself: wrong server choice, misaligned time zones, leaked keys, lost logs, a crashed program nobody notices at 3 a.m. …

Written for individual quant/automation players: from server selection (which providers, how to solve network problems) to configuration advice (is 2C4G really enough), from deployment & ops (systemd/cron/pm2) to logging, monitoring, time sync, and budget — ending with a security baseline you must memorize.

⚠️ Risk Warning

Every oversight in an automation environment can turn into real monetary loss: API key leaks, server compromise, time-zone misalignment sending orders at the wrong hour, silent crashes that make you miss your stop loss. Crypto exchange API use is governed by platform terms and local regulations — confirm compliance yourself when accessing overseas services. Prices and config parameters here are reference values only; defer to each provider's latest pricing. Everything here is for learning and research only and constitutes no investment advice. Markets carry risk; invest with caution.

1. Choosing a Personal Server

1.1 Cloud Server Comparison

1.2 Network Problems Accessing Exchange APIs from Mainland China

• Crypto exchange API domains (Binance/OKX/Bybit etc.) are unreachable directly or highly unstable from within mainland China; domestic servers reach foreign APIs through international exits with high latency, jitter, and blocking risk;
• Common solutions (each with trade-offs; assess compliance yourself):
  • Overseas servers (Hong Kong/Singapore/Tokyo/US West): deploy directly on overseas nodes for lowest physical latency — the mainstream choice for individual quants;
  • Proxy/relay: domestic server + proxy to foreign APIs — adds failure points; not recommended for automation;
• Conclusion: put the server in the region whose market data/API you access — A-shares → domestic (or mainland-reachable routes), crypto → overseas.

1.3 Why Crypto Exchanges Favor Overseas Servers

• Exchanges treat datacenter IPs more consistently (cloud IP ranges are rarely collateral-blocked) and offer low latency: Hong Kong/Singapore nodes give good access to Binance, OKX, Bybit and other Asia-centered exchanges;
• Residential or small-datacenter IPs are actually less stable — any reputable cloud provider's overseas node works;
• Note: some exchanges restrict service to specific regional IPs; your IP location should also match your account's compliance status — defer to each platform's terms.

2. Server Sizing: Is 2C4G Enough?

Conclusion: 2C4G is entirely sufficient for the vast majority of individual quants. What actually blows up isn't the spec but:

• Unrotated logs filling the disk (see Section 4);
• Memory leaks never restarted;
• No cleanup policy as data accumulates (historical quote files growing forever).

3. Operating System & Deployment

3.1 Basic Linux Commands (Enough-to-Work List)

# These few cover most needs
ssh user@ip            # log into the server
ls / cd / pwd          # directories
mkdir -p /opt/trader   # create directories
nano / vim file        # edit files
htop / top             # check resource usage
df -h                  # check disk
crontab -e             # scheduled jobs
systemctl status xxx   # check service status

3.2 Process Management: pm2 vs systemd

systemd example (/etc/systemd/system/trader.service, teaching illustration):

[Unit]
Description=trader bot
After=network-online.target

[Service]
User=trader
WorkingDirectory=/opt/trader
ExecStart=/usr/bin/python3 /opt/trader/main.py
Restart=always
RestartSec=10
EnvironmentFile=/opt/trader/.env   # secrets live here, never in code

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now trader
journalctl -u trader -f        # follow logs live

3.3 cron Scheduled Jobs

• Add daily jobs with crontab -e, e.g.: run review at 15:05, incremental fetches at 20:00;
• cron pitfalls: its environment differs from your login shell (use absolute paths in scripts, specify Python explicitly); time zones covered in Section 5.

4. Logs & Monitoring

4.1 Log Rotation

• Append-only logs will fill the disk (the most common "program fine, system dead" incident);
• Use logrotate daily splits + 7–14 day retention, or logging.handlers.RotatingFileHandler inside Python;
• Log levels: keep trading logs (fills/orders) separate from debug logs so troubleshooting doesn't cross-contaminate.

4.2 Error Alerts: Pushing to Your Phone

Alerts exist so "when things break at night, you get woken up." Common channels and approaches (examples in 15 - Quant Practice - 04↗):

# Idea example: push to DingTalk when the script errors (keys/webhooks per official docs)
curl -s -X POST "$WEBHOOK_URL" \
  -H 'Content-Type: application/json' \
  -d '{"msgtype":"text","text":{"content":"Trading script error: check /opt/trader/logs"}}'

4.3 What to Monitor

5. Time Sync: The Time-Zone Traps of Trading Servers

• Time zone rules: store and run everything on servers in UTC; convert to local time only at the display layer; scheduled job execution times must be converted into the target exchange's timezone;
• NTP sync: keep clocks synced with timedatectl set-ntp true; clock drift makes your timestamps disagree with the exchange's (affecting WebSocket heartbeats, rate-limit windows, candle boundaries);
• Classic incident: a server set to UTC-8 (US West) running an A-share 15:00 close job actually fires at Beijing time 07:00; or a crypto script splitting daily bars at "server-local midnight" actually cuts at US Eastern boundaries — candle close times, funding rate settlement times, delivery times all defer to the exchange's official timezone;
• Advice: specify timezones explicitly in scripts (Python: zoneinfo/pytz; never rely on system local time); use CRON_TZ for cron.

6. Budget: What Personal Quant Costs Monthly

Total: a personal quant "starter setup" runs about CNY 50–200/month, fully capable of daily-bar strategies and scheduled research. Spending order: server > data > everything else; start at 1C2G — don't buy top spec first.

7. Security Baseline (Must Memorize)

7.1 SSH & Firewall

• Disable password login; use SSH keys only (PermitRootLogin no + PasswordAuthentication no);
• Firewall allows only necessary ports (SSH, app ports); default-deny everything else;
• Reference flow: generate a keypair → put the public key in ~/.ssh/authorized_keys on the server → confirm key login works before turning passwords off.

7.2 API Key Isolation

7.3 Common Leak Paths for Exchange API Keys

1. Code repositories: committing Key/Secret to GitHub — coin-stealing scripts scan public repos for keys constantly (real cases in 15 - Quant Practice - 04↗);
2. Chats/cloud drives: screenshots, documents, group files carrying keys;
3. Server compromise: password login enabled, SSH keys chmod 777, weak panel passwords — first thing attackers look for is .env;
4. Third-party tools: pasting keys into unknown "quant tools/copy-trading software";
5. Log leakage: print(secret) in code or keys written into log files.

After a leak: revoke the key at the exchange immediately (possible via mobile app) → move affected assets → trace the leak path → issue new keys.

8. Next Steps

With the environment ready, deploy your strategy code — code and strategies start at 15 - Quant Practice↗; cross-check system design against the monitoring and security chapters of Chapter 10 - System Integration↗ for gaps.