systemd unit file generator

Generate a valid systemd .service unit from a few fields — and learn what each directive does.

Fill in the fields to produce a working .service unit, then follow the notes below to install, enable and debug it.

↳ Runs entirely in your browser. Nothing you type here is sent to us or anyone else.

Anatomy of a service unit

A unit file has three sections. [Unit] holds metadata and ordering (description, After=). [Service] defines how the process runs (ExecStart=, User=, Restart=). [Install] tells systemd how to enable it at boot (WantedBy=).

Key directives

Directive What it does
ExecStart The command to run (use an absolute path)
User Run as this account, not root, where possible
Restart on-failure or always to auto-recover
After Start after these units (e.g. network.target)
WantedBy Usually multi-user.target for boot start

Installing and enabling

sudo cp myapp.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service

Checking and debugging

systemctl status myapp.service
journalctl -u myapp.service -f

If it won’t start, journalctl shows why. Common causes: a relative ExecStart path, a missing User, or a working directory that doesn’t exist (WorkingDirectory=).

Frequently asked questions

Where do I put the unit file?

For your own services, /etc/systemd/system/. After adding or editing a unit, run sudo systemctl daemon-reload so systemd picks up the change.

What is the difference between enable and start?

start runs the service now; enable makes it start at boot. systemctl enable --now does both at once.

Should services run as root?

Avoid it. Set User= to a dedicated low-privilege account and add hardening like NoNewPrivileges=true and ProtectSystem=strict where practical.