Why run my app as a systemd service?

Because a process you start by hand dies when it crashes, when you log out, or when the box reboots - and nobody is watching. A systemd service supervises it: it restarts the process on crash, starts it again after a reboot, captures its logs in the journal, and runs it as a locked-down non-root user. It is the difference between an app that is running and an app that stays running.

What does the hardening do?

The generated unit adds the standard systemd sandboxing directives: NoNewPrivileges stops privilege escalation, ProtectSystem and ProtectHome make most of the filesystem read-only or invisible to the service, PrivateTmp gives it an isolated /tmp, and ReadWritePaths whitelists only the directories it legitimately needs. If the process is compromised, these sharply limit what it can touch.

Is one service enough to keep an app alive?

It keeps a single process alive on a single box, which is most of the battle. What it does not do is watch for a hung-but-not-crashed process, fail over to another host, alert you when it gives up, or give you a record of what changed and when. Those are the next layers of keeping a backend running - which is the job a control plane takes over.

Free tool · Runs in your browser · Nothing uploaded

Keep your app running.

A process you start by hand dies on crash, logout, or reboot — and nobody is watching. Fill in a few fields and get a hardened systemd unit that restarts your app automatically, runs it as a non-root user, sandboxes it, and the exact commands to install it.

Service name

Description

Run as user

Working directory

Start command (use absolute paths)

Environment file (optional)

Restart delay (seconds)

Add security hardening (recommended)

myapp.service

Install commands

Running vs. staying running

Shipping the app is the easy part. The hard part is everything that happens after: the crash at 3am, the reboot after a kernel update, the memory leak that wedges the process without killing it. A managed platform did all of that for you invisibly — and when you move to a box you own, it becomes yours. A systemd unit is the first and most important piece: it turns “I started it” into “it stays started.”

It's also where most self-hosting setups stop — and where the gaps are. systemd will restart a crashed process, but it won't notice a hung one, fail over to another machine, page you when it gives up, or keep a record of who changed the unit and when. Those are the next layers, and they're exactly what a control plane is for.

Related free tools

Reverse proxy + HTTPSCaddy / nginx + HTTPS Backup script generatorDump, offsite, restore RPO / RTO calculatorData loss + downtime Log rotation estimatorWhen logs fill the disk

All free tools →

One box, one service. A fleet needs more.

Infraveil supervises your services across every host you own — independent of the app, with auto-recovery, failover, and a tamper-evident record of every change. The same “stays running” guarantee, for your whole backend instead of one process.

See how it works

Get the keep-it-running playbook

A practical guide to supervising, monitoring, and recovering a self-hosted backend. No spam.