What does systemd sandboxing actually do?

systemd can confine a service with a set of directives that sharply limit what a compromised process can touch: NoNewPrivileges stops privilege escalation, ProtectSystem makes most of the filesystem read-only, ProtectHome hides home directories, PrivateTmp gives an isolated /tmp, and ReadWritePaths whitelists only the directories the service legitimately needs. They are free to add and dramatically shrink the blast radius if the service is exploited.

Why does a service need a restart policy?

Without Restart=always (or on-failure), a service that crashes simply stays down, and nobody is notified. Adding a restart policy with a RestartSec delay turns a transient crash into a brief blip the supervisor recovers from automatically. It is the difference between a service that is running and one that stays running.

Should my service run as root?

Almost never. If the unit has no User= it runs as root, so a compromise of the process is root on the host. Run it as a dedicated unprivileged user with only the access it needs. Combined with the sandboxing directives, this is the core of hardening a systemd service.

Free tool · Runs in your browser · Nothing uploaded

Analyze a systemd unit.

Most .service files run as root with no sandbox and no restart policy — fine until they aren’t. Paste your unit and get a hardening review: root user, missing sandboxing, no auto-restart, each with the exact directive to add.

100% client-side

root, unsandboxed, and unwatched

A service started by a quick ExecStart with nothing else does three risky things at once: it runs as root, it has the run of the filesystem, and it stays dead if it crashes. systemd can fix all three with a handful of directives that cost nothing — a dedicated user, a few sandbox lines, and a restart policy — but they only help if they’re there. This reads your unit and tells you which are missing.

Hardening one unit is a quick edit. Knowing every service across every host is hardened, and noticing when one drifts back to running as root, is the standing job a control plane handles over the infrastructure you own.

Related free tools

Deploy to your own serverPush-to-deploy, your box systemd service generatorKeep your app running Reverse proxy + HTTPSCaddy / nginx + HTTPS DNS records helperPoint your domain

All free tools →

Related guide

Fix EMFILE: Too Many Open Files

Harden it, and keep it hardened.

Infraveil supervises and audits your services across the hosts you own — with least-privilege defaults, auto-recovery, and a tamper-evident record that the hardening you set is still in place.

See how it works

Get the keep-it-running playbook

Supervision, sandboxing, and recovery for services you run yourself. No spam.