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.

Service basics

Execution

Environment

Restart policy

Security hardening (recommended)

Generated unit file

Save to /etc/systemd/system/myapp.service, then sudo systemctl daemon-reload && sudo systemctl enable --now myapp.

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.

About 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.