Emergency server help: get in touch

systemd Unit Generator: Service and Timer Files With Safe Defaults

Generates a systemd service unit, and a timer unit for scheduled jobs, with a dedicated user, restart policy and recommended sandboxing, plus the verify and enable commands.

Status
Live
Last updated
October 3, 2026

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.

Choosing the service type

TypeUse for
simple / execNode, Python, Go and Java apps that run in the foreground
forkingOlder daemons that fork into the background and write a PID file
oneshotBackup, cleanup and report scripts that finish and exit; used automatically with timers
notifyPrograms 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

systemd Unit Generator summary card: Enter a service name and an absolute ExecStart command, set the user it should run as, and pick the Type: simple or…
In short: 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.
systemd Unit Generator sections: Choosing the service type, Sandboxing options and Timers instead of cron
Covers: Choosing the service type, Sandboxing options and Timers instead of cron.
systemd Unit Generator questions answered: Where do I save the generated unit file? Should services run as root?
Answers: Where do I save the generated unit file? Should services run as root?

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.

Free website test

Is your website set up right?

Check SSL, security headers, redirects, robots.txt, sitemap, llms.txt and security.txt in one test. It takes about 30 seconds.