A focused systemd guide for keeping Python and Node bots alive after SSH disconnects, crashes and VPS reboots.
In plain English
This guide assumes a long-running service on a Linux VPS. Your home PC can be off, but the VPS still needs proper service management, updates, logs and secrets.
What systemd solves
systemd manages the lifecycle of a process. It is not a strategy engine and it does not know whether your bot is making correct decisions. Its job is to start, stop, restart and report process status.
Restart policy
Restart=on-failure is a useful default because a clean intentional stop stays stopped. Avoid tiny restart delays during a repeated failure; a restart storm can hammer an API and make logs unreadable.
Restart=on-failure
RestartSec=10
StartLimitIntervalSec=300
StartLimitBurst=5Environment variables
Use EnvironmentFile with permissions restricted to the service user. Never print the environment file in diagnostic output that may later be shared.
Logs
journalctl -u bot.service --since "30 minutes ago"
journalctl -u bot.service -p warning
journalctl -u bot.service -fHealth is more than process state
Track values such as last_tick_at, last_api_success_at, last_strategy_run_at and last_order_check_at. A watchdog can alert when those timestamps are too old.
Before you rely on this in production
- Service starts after reboot.
- Firewall exposes only required ports.
- Secrets have restricted permissions.
- Logs and disk usage are monitored.