This systemd unit generator writes the service file you would otherwise copy from an old server and adjust by hand. Fill in the name, command and user, choose how the program behaves, and it produces a unit with sensible restart settings and optional sandboxing. Add a schedule and it also writes a matching .timer unit, which is the modern replacement for a cron job with better logging and catch-up after downtime.
Short answer: Enter a service name and an absolute ExecStart command, set the user it should run as, and pick the Type: simple or exec for programs that stay in the foreground, forking for classic daemons, oneshot for scripts that run and exit. Save the output to /etc/systemd/system/, run systemd-analyze verify, then systemctl daemon-reload and systemctl enable --now.
Table of Contents
Choosing the service type
| Type | Use for |
|---|---|
| simple / exec | Node, Python, Go and Java apps that run in the foreground |
| forking | Older daemons that fork into the background and write a PID file |
| oneshot | Backup, cleanup and report scripts that finish and exit; used automatically with timers |
| notify | Programs that call sd_notify when ready, such as some database and proxy servers |
Sandboxing options
The recommended hardening adds NoNewPrivileges, PrivateTmp, ProtectSystem=full, ProtectHome and kernel protections. They stop a compromised service from writing to system directories or reading home directories. If the service must write somewhere, add that path with ReadWritePaths=. Check the effect with systemd-analyze security name.service, which scores the unit’s exposure.
Timers instead of cron
With a schedule such as daily or Mon..Fri 08:00, the generator writes a timer with Persistent=true, so a run missed while the server was off happens at the next boot, and a small random delay so many servers do not all start at once. Check the next run with systemctl list-timers and the output with journalctl -u name.service.
Systemd unit generator at a glance



Official documentation: systemd.service manual, systemd.timer manual.
Related tools: Cron expression helper · chmod calculator · nginx config checker.
Frequently asked questions
Where do I save the generated unit file?
Save custom units in /etc/systemd/system/ as name.service (and name.timer), then run systemctl daemon-reload so systemd reads them.
Should services run as root?
Only if they genuinely need root. Create a dedicated system user with useradd –system and set User= so a bug or compromise in the service cannot take over the server.
What is the difference between Restart=always and on-failure?
on-failure restarts the service only when it exits with an error or is killed; always also restarts it after a clean exit. Use on-failure for most apps so a deliberate stop stays stopped.