systemd units for a hobby project you don't want to babysit

The usual way a small self-hosted project gets run is nohup python app.py & or leaving it inside a screen session, and both work until the process crashes at 2am or the server reboots for a kernel update, at which point the project is quietly down until someone notices and remembers how it was started in the first place.

A minimal unit file

A systemd service unit solves this for about fifteen lines of config, in /etc/systemd/system/myapp.service:

[Unit]
Description=My hobby app
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/user/myapp/app.py
WorkingDirectory=/home/user/myapp
Restart=on-failure
RestartSec=5
User=user

[Install]
WantedBy=multi-user.target

Restart=on-failure is the actual value proposition here — if the process crashes, systemd brings it back after RestartSec without anyone needing to notice or intervene, which is the entire difference between a crash that's a five-second blip and a crash that's an outage until a human happens to check on it.

Surviving a reboot, not just a crash

sudo systemctl enable myapp
sudo systemctl start myapp

enable is the part that's easy to forget — it's what makes the service start automatically on boot, separate from start, which only starts it for the current session. A service that's started but not enabled comes back after a crash but not after a reboot, which is a confusing gap to debug the first time a server restarts for an unrelated reason and the project just doesn't come back.

journalctl -u myapp -f gets you live logs, the same live-tail experience screen was giving you, minus the part where the whole thing disappears if the session it was running in ever dies.

None of this is complicated once written down, and it's exactly the kind of fifteen-minute setup that's easy to skip for a project that "probably won't crash" — right up until it does, at a time nobody's watching.