systemd Unit File Builder (.service)

Writing a .service file by hand means remembering 30+ directives and which Section each belongs in. This builder gives you a form for each common option (Type, ExecStart, User, WorkingDirectory, Environment, restart policy, dependencies, security hardening) and outputs a clean unit file ready for /etc/systemd/system/yourapp.service.

How to use the systemd Unit File Builder (.service)

Fill in the form. The output updates live. Pick the right Type: simple for a long-running process that doesn't fork (Node, Python apps); forking for daemons that double-fork (nginx, sshd); notify for apps that use sd_notify (PostgreSQL, modern Go apps).

Security hardening adds NoNewPrivileges, ProtectSystem=strict, PrivateTmp=yes — standard recommendations from systemd that reduce blast radius if the service is compromised.

What is the systemd Unit File Builder (.service)?

systemd unit files declare services in INI-style sections. A .service file has three main sections:

• [Unit] — metadata, dependencies, ordering (Description, After, Requires, Wants).
• [Service] — how to start / stop / restart (Type, ExecStart, ExecStop, Restart, User, WorkingDirectory, Environment).
• [Install] — what target this unit hooks into when enabled (WantedBy=multi-user.target).

The Type= directive controls how systemd decides "the service is now running":

• simple (default) — runs ExecStart, considers it ready immediately.
• exec — like simple but waits for exec() to succeed.
• forking — runs ExecStart, expects it to fork and exit; systemd tracks the child.
• oneshot — runs once and exits; combine with RemainAfterExit=yes for "ran and considered active".
• notify — service calls sd_notify(READY=1) when ready; systemd waits.

Security hardening directives reduce attack surface: NoNewPrivileges prevents the process or its children from gaining new privileges (blocks setuid escalation); ProtectSystem=strict makes the whole filesystem read-only except for whitelisted writeable paths; PrivateTmp=yes gives the service its own /tmp.

Common use cases

• Deploying a new service — replace ad-hoc nohup / screen with proper systemd management.
• Migrating from upstart / init.d — translate old init scripts to modern unit files.
• Learning systemd — see all the options surfaced visually.
• Hardening existing services — adding security directives to an existing .service file.