Systemd Service Generator
Run your application as a proper Linux service that starts at boot, restarts on failure and logs to the journal. Describe the command, user and environment, and get a unit file with a restart policy, resource limits and sandboxing that limits what the service can touch, or a timer that runs it on a schedule, plus the commands to install, start and follow it.
- Runs in your browser
- No sign-up
- Free to use
How to use Systemd Service Generator
- Enter the service name and the command to start.
- Set the user, working directory and environment file.
- Choose restart, sandboxing and limits, or a schedule.
- Run the install commands on the server.
Systemd Service Generator features
Complete unit
[Unit], [Service] and [Install] sections.
Reliability
Restart policy, network-online ordering, start types.
Sandboxing
NoNewPrivileges, ProtectSystem, PrivateTmp and more.
Limits
MemoryMax and LimitNOFILE.
Timers
Scheduled jobs with OnCalendar and Persistent.
Install steps
User creation, file installation, enable and logs.
When to use Systemd Service Generator
- Running a Node.js, Python or Go app on a VPS.
- Replacing pm2, screen or nohup with a real service.
- Scheduling backups and maintenance jobs.
- Hardening existing services.
Systemd Service Generator FAQ
Which Type should I choose?
exec for most programs that stay in the foreground, notify for programs that report readiness (such as Gunicorn), forking only for old daemons that background themselves, oneshot for jobs that run and exit.
Why an absolute path in ExecStart?
systemd does not search PATH like a shell. Find the full path with which node or which python3.
Where do secrets go?
In the EnvironmentFile, owned by root with mode 600. Environment= lines are visible to all users through systemctl show.
What does ProtectSystem do?
full makes /usr, /boot and /etc read-only for the service; strict makes the whole file system read-only except the paths in ReadWritePaths.
Timer or cron?
Timers log to the journal, can catch up missed runs with Persistent=true and are managed like services; cron is simpler and more portable.
Is anything uploaded?
No. The unit file is generated in your browser.
Running apps with systemd
On almost every Linux distribution, systemd starts and supervises services. A small unit file is enough to make an application start at boot, run as its own unprivileged user, restart if it crashes, send its output to the journal and stop cleanly on shutdown, without extra process managers.
The [Unit] section describes the service and orders it after the network is online. The [Service] section holds the command, user and group, working directory, environment and restart behaviour, and [Install] makes systemctl enable start it at boot. The generator validates what systemd is strict about, such as absolute paths in ExecStart.
Configuration and secrets go into an EnvironmentFile owned by root with restrictive permissions, because Environment= lines are visible to every user. Resource limits cap the service’s memory and raise the open-file limit that busy network services need.
Sandboxing options let systemd restrict the service with kernel features. Even the basic level makes system folders read-only, hides home directories, gives the service a private /tmp and forbids gaining privileges. The strict level goes further and makes the whole file system read-only except the folders you list. Check the result with systemd-analyze security.
For periodic jobs, a timer replaces cron: the service runs once per trigger, OnCalendar sets the schedule, Persistent=true catches up runs missed while the machine was off, and the output of every run lands in the journal.