Moayyad Faris
AWS and DevOps

Processed locally in your browser — not uploaded

Systemd Service Unit Generator & Hardener

Build production-grade Linux systemd unit files (.service) for Node.js, Go, Python, or Rust daemons. Features process sandboxing security directives (ProtectSystem=strict, NoNewPrivileges=true, PrivateTmp=true, PrivateDevices=true, MemoryDenyWriteExecute=true), resource limits (LimitNOFILE, LimitNPROC), environment variables, and automated systemctl installation commands.

Preset:

Service Identity & Execution Command

[Unit]
Description=My Production Node.js Web Application
After=network.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/node /var/www/myapp/dist/index.js
Restart=always
RestartSec=5s
TimeoutStopSec=30s

# Resource Limits
LimitNOFILE=65536
LimitNPROC=4096

# Environment Variables
Environment="NODE_ENV=production"
Environment="PORT=3000"

# Sandboxing & Security Hardening
ProtectSystem=strict
ProtectHome=yes
NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
MemoryDenyWriteExecute=true
ReadWritePaths=/var/log/myapp

[Install]
WantedBy=multi-user.target
Installation CLI Commands
sudo cp myapp.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
Check status: sudo systemctl status myapp
Encoding: UTF-8Linux systemd.service(5)
01

How to use

  1. Select a pre-configured starter preset (Node.js Web App, Go/Rust Binary, Python FastAPI/Gunicorn, Background Worker).
  2. Specify Service metadata (Service Name, Description, ExecStart command path, WorkingDirectory, User/Group).
  3. Configure Restart policies (Restart=always, RestartSec, TimeoutStopSec, LimitNOFILE, LimitNPROC).
  4. Enable security sandboxing options (ProtectSystem=strict, NoNewPrivileges=true, PrivateTmp=true, CapabilityBoundingSet=).
  5. Copy or download the generated .service unit file and inspect systemctl installation commands.
02

Understanding the output

The generator creates a production Linux systemd unit file (.service) formatted according to systemd.service(5) standards. It combines execution settings, environment declarations, process resource limits, and systemd sandboxing directives to prevent compromised daemons from escalating privileges.

03

Common issues & tips

  • Ensure executable binary paths (ExecStart) are absolute paths (e.g., /usr/bin/node or /usr/local/bin/app). Relative paths are rejected by systemd.
  • When enabling ProtectSystem=strict, systemd mounts / as read-only. Declare explicit ReadWritePaths=/var/log/myapp if your service needs to write local files.
  • After copying your file to /etc/systemd/system/myservice.service, always execute 'sudo systemctl daemon-reload' before starting the unit.

Frequently asked questions

Where do I save the generated .service file on Linux?
Save the file in /etc/systemd/system/ (e.g. /etc/systemd/system/myapp.service). After copying, run 'sudo systemctl daemon-reload' and 'sudo systemctl enable --now myapp'.
What does ProtectSystem=strict do in systemd?
ProtectSystem=strict mounts the entire file system (/) as read-only for the process. If your app writes log files or state, declare explicit ReadWritePaths=/var/log/myapp.
Why must ExecStart use an absolute binary path?
systemd does not evaluate shell PATH environments when launching services. All ExecStart binary commands must specify the absolute path (e.g., /usr/bin/node or /usr/local/bin/app).

Related tools