Systemd Unit File Generator
Build systemd service unit files through a visual form. Choose service type, restart policy, environment variables, and download a ready-to-use .service file.
About This Tool
Writing systemd .service files from scratch means remembering dozens
of INI-style directives and their exact spelling. This free visual
generator lets you fill in a form — service type, restart policy, user,
environment variables — and outputs a ready-to-deploy unit file. Select a service type
(simple, forking, oneshot, notify, dbus, idle), configure restart policies,
set user/group permissions, define environment variables, and the tool
generates a complete .service file ready to deploy on any Linux system
running systemd.
The generator covers all three main sections of a unit file: [Unit] for metadata and dependencies (Description, After, Requires, Wants), [Service] for execution parameters (Type, ExecStart, ExecStop, Restart, RestartSec, User, Group, WorkingDirectory, Environment, EnvironmentFile, PIDFile, StandardOutput, LimitNOFILE), and [Install] for activation targets (WantedBy, RequiredBy). Built-in templates for common scenarios like Node.js applications, Python Gunicorn servers, Docker containers, and Nginx reverse proxies let you start with a solid baseline and customize from there.
If you manage Docker containers, the
Docker Run Command Builder provides a similar
visual experience for building docker run commands. For generating
Nginx configuration files, check out the
Nginx Config Generator. And if you need
to schedule recurring tasks, the
Cron Expression Builder can help you create cron
schedules.
All processing runs entirely in your browser. No unit file content, server paths, usernames, or environment variables are ever sent to any server. This tool is safe to use with production service configurations and sensitive deployment details.
How to Use
- Optionally select a Template at the top to pre-fill the form with a common service pattern (Node.js, Python, Docker, Nginx, etc.).
- Fill in the [Unit] section: enter a Description, and set dependencies with After, Requires, and Wants fields.
- Configure the [Service] section: choose a Type (simple, forking, oneshot, etc.), enter the ExecStart command, set User/Group, WorkingDirectory, and add Environment variables.
- Set the Restart policy and RestartSec delay to control automatic restart behavior.
- Configure the [Install] section: set WantedBy (usually
multi-user.target) to enable the service on boot. - Review the Generated Unit File in the output panel on the right. The file is formatted and ready to use.
- Click Copy or press Ctrl+Shift+C to copy to clipboard, or click Download to save as a
.servicefile.
Popular Systemd Unit File Examples
FAQ
What is a systemd unit file?
A systemd unit file is a configuration file that tells systemd (the Linux init system) how to manage a service, socket, timer, or other resource. Service unit files (ending in .service) define how to start, stop, and restart a process, what user to run it as, and when it should be activated.
What is the difference between simple and forking service types?
A 'simple' service type means the process started by ExecStart is the main service process and stays in the foreground. A 'forking' type means the process forks a child and the parent exits; systemd considers the service started when the parent exits. Forking is used by traditional Unix daemons. Most modern applications should use 'simple'.
Which restart policy should I use?
For most services, 'on-failure' is a good default: the service restarts only if it exits with a non-zero status or is killed by a signal. Use 'always' for critical services that must run continuously (like web servers). Use 'no' for oneshot scripts that should only run once. The 'on-abnormal' policy restarts on signal/timeout but not on clean exit.
Where do I save the generated unit file?
Save the file to /etc/systemd/system/ with a .service extension (e.g., /etc/systemd/system/myapp.service). Then run 'sudo systemctl daemon-reload' to reload the configuration, and 'sudo systemctl enable --now myapp' to start and enable the service on boot.
How do I use environment variables in a unit file?
You can set environment variables inline with Environment="KEY=VALUE" directives (one per variable), or load them from a file with EnvironmentFile=/path/to/env. The environment file should contain KEY=VALUE pairs, one per line. Using EnvironmentFile is recommended for sensitive values to avoid exposing them in the unit file.
Is my data safe?
Yes. The generator constructs the .service file using JavaScript string templating based on your form inputs. No data — including ExecStart commands, file paths, usernames, or environment variable values — ever leaves your browser. There are no fetch requests, no WebSocket connections, and no external dependencies.
Can I create timer units with this tool?
This tool focuses on generating .service unit files. However, you can use the generated service file alongside a manually created .timer unit to schedule periodic execution. Set the service Type to 'oneshot' for timer-triggered services, and create a corresponding .timer file with OnCalendar or OnBootSec directives.
Related Tools
Docker Run Command Builder
Build docker run commands visually with ports, volumes, env vars, and generate docker-compose.yml.
Nginx Config Generator
Generate Nginx server blocks visually. Configure reverse proxy, SSL, static files, and redirects with a GUI.
Cron Expression Builder
Build and validate cron expressions with a visual editor and next run times.
Shell Script Linter
Lint and check bash/shell scripts for common issues, deprecated syntax, and best practices. Catch bugs before they reach production.
GitHub Actions Workflow Builder
Build GitHub Actions workflow YAML files visually. Configure triggers, jobs, steps, matrix strategies, and secrets references.