Free tool · Runs in your browser

Systemd Service Generator

Generate a systemd .service unit from a form - execution, dependencies, security hardening, resource limits, and an optional .timer - with a live preview and install steps. Everything runs in your browser.

Quick start
.service
Start After (ordering)
Requires (hard dependencies)
Wants (soft dependencies)
myapp.service
[Unit]
Description=My Application Service
After=network.target

[Service]
Type=simple
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

ExecStart is required - add a command in the Execution tab.

install & manage
sudo nano /etc/systemd/system/myapp.service
sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
sudo systemctl status myapp
journalctl -u myapp.service -f

What is a systemd service?

On modern Linux, systemd manages long-running services. You describe a service in a unit file (myapp.service) split into three sections: [Unit] (metadata and dependencies), [Service] (how to run it), and [Install] (how it gets enabled). Place it in /etc/systemd/system/ and systemd starts, supervises, restarts, and logs it for you.

Choosing a service Type

TypeUse it when
simpleThe command runs in the foreground and does not fork (the common default).
execLike simple, but systemd waits until the binary has actually executed.
forkingThe process daemonizes (forks and the parent exits) - set PIDFile too.
oneshotA short task that runs and exits, e.g. a script driven by a timer.
notifyThe service tells systemd when it is ready via sd_notify.

Restarting on failure

Set Restart=on-failure to bring the service back after a crash, or Restart=always to keep it running no matter how it exits (good for workers). Pair it with RestartSec=5 so systemd waits before retrying instead of hammering a broken service. To start automatically at boot, enable it - that is what the [Install] section and WantedBy are for.

Hardening a service

systemd can sandbox a service with a few directives - this is one of the biggest security wins for little effort. The high-impact ones: NoNewPrivileges, ProtectSystem=strict (read-only filesystem except ReadWritePaths), PrivateTmp, ProtectHome, and DynamicUserto run under a throwaway account. The Security tab's Apply recommended hardening button turns on a safe, broadly-compatible set.

Limiting resources

systemd uses cgroups to cap what a service can consume: MemoryMax=512M kills it if it exceeds the limit, CPUQuota=50% caps it to half a core, and TasksMax and LimitNOFILE bound threads and open files. Useful for keeping one runaway service from taking down the whole box.

Install, enable, and check logs

Save the unit and tell systemd about it:

  • sudo systemctl daemon-reload - reload unit files after any change.
  • sudo systemctl enable --now myapp - start it and enable it at boot.
  • systemctl status myapp - check it is running.
  • journalctl -u myapp -f - follow its logs live.

systemd timers vs cron

For scheduled tasks, a oneshot service paired with a .timer is the modern alternative to cron: it integrates with the journal, handles missed runs with Persistent=true, and supports flexible OnCalendar expressions. cron is still simpler for quick, universal jobs - see our cron expression generator for that side.

Common systemd directives

DirectiveSectionWhat it does
Description[Unit]A short human-readable name shown by systemctl status.
After[Unit]Ordering only - start this after the listed units.
Requires[Unit]Hard dependency - pulls in and needs the listed units.
Type[Service]How systemd decides the service started (simple, forking, oneshot...).
ExecStart[Service]The command that runs the service (absolute path).
Restart[Service]When to restart, e.g. on-failure or always.
User[Service]The account the service runs as (least privilege).
Environment[Service]An environment variable for the process.
WantedBy[Install]The target that enables the service, usually multi-user.target.
systemd FAQ

Frequently asked questions

Write a unit file with [Unit], [Service], and [Install] sections - at minimum a Type, an ExecStart command, and WantedBy=multi-user.target. Save it to /etc/systemd/system/myapp.service, run sudo systemctl daemon-reload, then sudo systemctl enable --now myapp. This generator builds the file for you and shows those exact commands.
Add Restart=on-failure (or Restart=always) with RestartSec=5 in the [Service] section to restart after a crash, and enable the service (systemctl enable) with WantedBy=multi-user.target in [Install] so it also starts on boot.
Set User= and optionally Group= in the [Service] section, e.g. User=www-data. For a throwaway, automatically-managed account, use DynamicUser=yes instead - it runs the service under a transient user that exists only while the service runs.
Use a systemd timer (a oneshot service plus a .timer) when you want journal-integrated logging, missed-run catch-up with Persistent=true, and dependencies on other units. Use cron for simple, portable, one-line schedules. This tool can generate the paired .timer; use the cron generator for crontab.
Add directives like NoNewPrivileges=yes, ProtectSystem=strict, PrivateTmp=yes, ProtectHome=yes, and DynamicUser=yes to sandbox the service with almost no effort. The Security tab in this generator includes an Apply recommended hardening button that turns on a safe default set.
Use journalctl -u myapp to see its logs, or journalctl -u myapp -f to follow them live. By default systemd captures the service's stdout and stderr into the journal, so you do not need to configure log files.
From unit file to running fleet

Manage services across every server.

CtrlOps deploys apps and manages their services across your whole fleet - start, stop, watch status and logs, and monitor resources from one local-first desktop app, with your credentials encrypted on your own machine.

Start instantly· No credit card· No sneaky autorenewals