Systemd Unit Builder

Systemd Unit Builder

Generate .service, .timer, and .socket unit files with validation and hardening defaults.

/etc/systemd/system/myapp.service
[Unit]
After
Requires
Wants
[Service]
Environment
Hardening
WantedBy ([Install])
myapp.service
[Unit]
Description=My application service
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/myapp --config /etc/myapp.conf
User=myapp
Group=myapp
WorkingDirectory=/var/lib/myapp
Environment=NODE_ENV=production
Restart=on-failure
RestartSec=5
TimeoutStartSec=30
KillMode=control-group
# --- Hardening ---
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target
Install
# Place file
sudo install -m 644 myapp.service /etc/systemd/system/myapp.service

# Reload systemd
sudo systemctl daemon-reload

# Enable + start
sudo systemctl enable --now myapp.service

# Status / logs
systemctl status myapp.service
journalctl -u myapp.service -f

What This Tool Does

Systemd Unit Builder is built for deterministic developer and agent workflows.

Build systemd .service, .timer, and .socket unit files with directives for Type, ExecStart, User, Restart, Environment, After, WantedBy. Validates required directives and outputs ready-to-install unit.

Use How to Use for execution steps and FAQ for constraints, policies, and edge cases.

Last updated:

This tool is provided as-is for convenience. Output should be verified before use in any production or critical context.

Agent Invocation

Best Path For Builders

Browser workflow

Runs instantly in the browser with private local processing and copy/export-ready output.

Browser Workflow

This tool is optimized for instant in-browser execution with local data handling. Run it here and copy/export the output directly.

/systemd-unit-builder/

For automation planning, fetch the canonical contract at /api/tool/systemd-unit-builder.json.

How to Use Systemd Unit Builder

  1. 1

    Pick the unit kind

    Choose .service for long-running processes, .timer for scheduled jobs, or .socket for socket-activated services. The form shows only the directives relevant to the selected unit kind to keep things readable.

  2. 2

    Fill the [Unit] and main section

    Set Description, Documentation, and ordering directives (After, Requires, Wants). Then fill the main section: ExecStart for service, OnCalendar for timer, ListenStream for socket. Validation flags missing required fields.

  3. 3

    Add environment and hardening

    Add Environment key/value pairs or point to an EnvironmentFile. Tick PrivateTmp and NoNewPrivileges, and pick ProtectSystem/ProtectHome levels. The validator nudges you toward sane defaults like a non-root User.

  4. 4

    Set [Install] target

    Add WantedBy entries (multi-user.target for most services, timers.target is auto-set on timers). This determines whether the unit auto-starts on boot when you run systemctl enable.

  5. 5

    Install the unit file

    Copy the rendered file to /etc/systemd/system/<name>.<kind>, run systemctl daemon-reload, then enable --now to start. The Install panel shows the exact commands tailored to your unit name.

Frequently Asked Questions

How are .service, .timer, and .socket related?
A .service runs the actual process. A .timer triggers a service on a schedule (replaces cron). A .socket creates a listening socket and starts the matching .service on first connection (lazy/socket activation).
What hardening defaults does it suggest?
PrivateTmp=true, NoNewPrivileges=true, ProtectSystem=full, ProtectHome=true, and a non-root User. These cost nothing to enable and block whole categories of post-exploit privilege escalation.
Does the timer need a matching service file?
Yes. A .timer named myapp.timer triggers myapp.service by default. Save the service block first, then build the timer — install both files and enable only the timer with systemctl enable --now myapp.timer.
Does it send my data to a server?
No. Validation, rendering of the unit file, and the install command preview all happen in your browser. ExecStart paths, environment values, and unit names stay local.
How do I check OnCalendar syntax?
After installing the unit, run systemd-analyze calendar 'YOUR-EXPRESSION' on the target host. It expands the next firing times so you can verify the schedule matches what you expected before enabling the timer.