systemd service & cron job generator
Build a production-ready systemd .service file (auto-restart, journald logging, boot startup) or a crontab line with a plain-language translation, plus the exact commands to install either one.
Will be saved as miapp.service
Always use the absolute path to the binary (which node, which python3, etc.)
Use network-online.target if your app needs internet already up at boot (e.g. connecting to a remote DB)
[Unit]
Description=My App
After=network.target
[Service]
ExecStart=/usr/bin/node /home/user/app/server.js
WorkingDirectory=/home/user/app
User=www-data
Environment="NODE_ENV=production"
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
sudo nano /etc/systemd/system/miapp.service
# (pegá el contenido de arriba, guardá con Ctrl+O, salí con Ctrl+X)
sudo systemctl daemon-reload
sudo systemctl enable --now miapp.servicesudo systemctl status miapp
sudo journalctl -u miapp -fWhy systemd instead of screen, tmux or nohup?
Running your app inside a screen or tmux session "works" for a quick test, but it's not fit for production: if the process crashes, nobody restarts it; if the server reboots, the session is gone and you have to manually log in and start it again; and the logs are trapped in that terminal's scrollback, with no rotation and no easy way to search them. systemd solves all three at once: Restart=always restarts the process automatically if it crashes, WantedBy=multi-user.target starts it automatically when the server boots (with nobody needing to log in), and journald centralizes every log, timestamped and searchable with journalctl -u your-service. It's the same mechanism Nginx, PostgreSQL, Docker and practically every modern Linux daemon uses.
The most common gotcha: creating the service doesn't enable it
systemctl start runs the service right now, but does nothing on the next reboot. systemctl enable is what creates the symlink that hooks it into multi-user.target so it starts automatically on boot. That's why the recommended command is always systemctl enable --now your-service — it does both in one step: starts it now and leaves it enabled for next time.
Cron's syntax, field by field
A crontab line has 5 time fields followed by the command to run. Each field accepts an exact value, an asterisk (*) meaning "any value", a comma-separated list (1,15), a range (1-5), or a step (*/5, "every 5 units").
| Field | Range | Notes |
|---|---|---|
| Minute | 0-59 | |
| Hour | 0-23 | 24-hour format |
| Day of month | 1-31 | |
| Month | 1-12 | |
| Day of week | 0-7 | 0 and 7 are both Sunday |
FAQ
Why doesn't my service start when the VPS reboots?+
The most common reason is that you started it with systemctl start but never ran systemctl enable — start only turns it on right now, enable is what hooks it in to start on every boot. Fix: systemctl enable --now your-service (or check with systemctl is-enabled your-service to see if it's already enabled).
Does cron use the system timezone?+
Yes, by default cron interprets schedules in the operating system's timezone. If your jobs run at an unexpected time, check the VPS timezone with timedatectl — many providers set servers to UTC by default, not your local timezone.
Why does my cron job work when I run it by hand but not when cron runs it?+
It's almost always the PATH: cron runs commands with a minimal environment, without the extended PATH or variables from your interactive shell (bash, zsh). Always use the absolute path to the binary (which node or which python3 to find it) instead of relying on the command being on the PATH.
What's the difference between Restart=on-failure and Restart=always?+
on-failure restarts the service only if it exits with a non-zero exit code (a crash or error) — if you stop it manually with systemctl stop, it won't restart. always restarts it no matter how it exited, even with exit code 0. For most production apps, always is the more predictable choice.
Need a VPS to actually run this on?
VPS with real NVMe and a dedicated IP, with full root access to install systemd services and cron jobs with no restrictions.
View plans