How to Keep a VPS Application Running with systemd

Use a systemd service for a long-running Linux application that should start after reboot and restart after failure. A terminal session, background shell job or nohup command is not a complete service-management plan.

Example service

For an already deployed application and existing nonprivileged user, a unit might contain:

[Unit]
Description=Example application
After=network.target

[Service]
User=app
WorkingDirectory=/srv/example
ExecStart=/srv/example/.venv/bin/gunicorn --workers 1 --bind 127.0.0.1:8000 app:app
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

This is a Python example, not a universal startup command. Create the user, files and virtual environment first, and verify that the user can read the application. Keeping the listener on loopback is appropriate when another guest-local proxy handles ingress.

Activate and inspect

After saving a correctly adapted unit as /etc/systemd/system/example.service, run sudo systemctl daemon-reload and sudo systemctl enable --now example. Inspect systemctl status example and journalctl -u example -n 50 --no-pager.

Use absolute executable paths. Services do not inherit your interactive shell's activated environment. Store credentials in a restricted configuration mechanism rather than command-line arguments that may appear in process listings.

Avoid restart loops

A restart policy cannot fix a missing dependency, bad configuration or database migration failure. Resolve the first useful error in the logs. Review rate limits and startup ordering if another local service is required.

See Python deployment, journal logs and scheduled jobs.

Reference: systemd.service manual.