Systemd Service Generator
Build systemd unit files for services, timers, and mounts. Get install commands included.
How to Use the Systemd Service Generator
- Choose a unit type — Service (daemon process), Timer (scheduled job), or Mount (filesystem mount).
- Select a preset for common runtimes: Node.js app, Python app, Go binary, or Docker container.
- Fill in the fields — ExecStart, WorkingDirectory, User, restart policy, and environment variables.
- Copy or download the unit file, then save it to
/etc/systemd/system/on your Linux server. - Activate the service using the install commands included in the output.
What is Systemd?
Systemd is the init system and service manager used by the majority of modern Linux distributions, including Ubuntu (15.04+), Debian, Fedora, RHEL/CentOS 7+, Arch Linux, and openSUSE. It starts as PID 1 when the system boots and manages all subsequent processes, dependencies, and logging. Systemd replaced older init systems like SysV init and Upstart, offering parallel startup, dependency management, socket activation, and centralized logging via the journal.
Service Unit Files
A service unit file has three main sections. The [Unit] section defines metadata and ordering dependencies — which targets or services must be running before this one starts. The [Service] section defines what to run, how to run it, and what to do when it exits. The [Install] section defines which targets "want" this service, determining when it starts during boot. After creating or modifying a unit file, always run systemctl daemon-reload to notify systemd of the change.
Restart Policies
The Restart directive controls automatic restart behavior. Restart=always is appropriate for production web servers and APIs — the process restarts regardless of exit code. Restart=on-failure restarts only when the process exits with a non-zero code, making it suitable for workers where a clean exit (code 0) should stop the service. Combine Restart with RestartSec=5 to add a delay between restarts and prevent rapid restart loops that could overwhelm the system or external services.
Systemd Timers vs. Cron
Systemd timers are the modern alternative to cron jobs on systemd-based Linux systems. They offer several advantages over cron: logs are automatically captured in the journal (viewable with journalctl -u mytimer.service), missed runs can be caught up automatically with Persistent=true, and the timer and service are integrated into the normal systemd dependency system. However, cron is simpler for basic schedules and works across all Unix systems. For new Linux server deployments, timers are generally preferred. See our GitHub Actions Generator for automating CI/CD pipelines.
User and Group Settings
Running services as root is a security risk. Always specify a non-privileged User and Group for your service. Create a dedicated system user with useradd --system --no-create-home myapp. Set file ownership with chown -R myapp:myapp /opt/myapp. For services that need to bind to ports below 1024, use AmbientCapabilities=CAP_NET_BIND_SERVICE instead of running as root.