SafeLine

Last reviewed Aug 26, 2026 · 810 words

SafeLine is the best-looking web application firewall you can self-host, and it charges one architectural fee for that: it has to be the thing your DNS points at. It is a full reverse proxy (an nginx fork called Tengine) with a detection engine beside it, not a module you bolt onto Caddy or Traefik. Accept that and you get a one-script install, a console you'll actually open, and semantic attack detection that needs far less false-positive tuning than a ModSecurity ruleset. Refuse it and you should be looking at CrowdSec instead, which is a perfectly good outcome.

It wants to be the front door

The deployment shape is: internet, then SafeLine, then whatever you already run. If you have Caddy or Traefik handling certificates and routing today, you either move that job into SafeLine (it does ACME certificates and virtual hosts itself) or chain SafeLine ahead of your existing proxy and let it forward everything. The chain works, but you now have two proxies, two places to look when a request fails, and the inner one loses the client's real IP unless you trust forwarded headers. I ran the chained layout for a month and then let SafeLine take over TLS for the public sites, which is the layout its maintainers assume.

One script, roughly 7 containers, 1 GB of RAM

The install is a shell script from the official docs that writes a Docker Compose stack to /data/safeline and starts it. Expect a management service, the detection engine, the Tengine proxy, a PostgreSQL database, and a few helpers. The catalogue's 1 GB minimum is honest: idle, the stack sits around there, and the detector grows with traffic. The console lives on https://your-ip:9443 with a self-signed certificate; the script prints the admin credentials at the end and you'll want to copy them immediately because they don't show again.

Adding a site is a form: domain, upstream address, whether to fetch a certificate. Within 5 minutes the dashboard is charting requests and blocks. That speed is the whole appeal; a ModSecurity deployment reaches the same point after a day of reading.

Semantic detection means fewer rules to babysit

Signature-based WAFs match requests against thousands of regexes and then make you exclude the ones that break your app's legitimate traffic. SafeLine instead parses the request and asks whether a parameter is structurally a SQL fragment, a script, a path traversal, and so on. In practice that means a Nextcloud or Gitea instance behind it produces a handful of false positives in the first week rather than a wall of them, and those are one click to exempt from the log entry. It is not magic; obfuscated payloads still get through occasionally, and you should still patch the app. But it is the first WAF I've run at home that I didn't eventually disable out of irritation.

What the community edition leaves out

The community edition covers the core: attack detection, IP and geo allow/deny lists, rate limiting, an HTTP flood mode, a per-site auth gate, and a bot challenge. Some features are held back for the paid Pro tier, and the docs are a mix of English and Chinese, with the English pages thinner. The project is by Chaitin, a Chinese security company, which is context some readers will want. In practice, the free tier has everything a homelab needs; the paid line only matters if you're evaluating it for work.

Where it sits next to CrowdSec and Anubis

These three answer different questions. CrowdSec asks "is this IP known to be bad" and bans it before the request reaches anything. Anubis asks "is this a browser willing to do a second of work" and taxes scrapers. SafeLine asks "is this specific request an attack" and inspects the payload. Running CrowdSec and SafeLine together is reasonable; running two WAFs is not. If you're choosing a proxy layer from scratch, the reverse proxy comparison covers the routing side, and SafeLine slots in front of whatever you pick there.

What I'd do

If I have public-facing apps with login forms (Nextcloud, a Git forge, anything with a database behind a search box), I'd give SafeLine the TLS job and put it at the edge, with CrowdSec's log parser watching its access logs. If everything I expose is behind a VPN or an identity proxy, I'd skip it: a WAF in front of traffic only I generate is 1 GB of RAM spent on a dashboard. The community edition on a 2 GB VPS is the setup I'd stand up first, and I'd give it a week before deciding whether the console earns its place.