Docker WAF vs single-binary WAF — how I choose for a single VPS

Kai Ren — Mon, 10 Aug 2026 23:43:01 +0000

Homelab and small-prod threads keep landing on the same question:

“I want a self-hosted WAF. SafeLine/Docker, or something smaller?”

There’s no universal winner. Here’s the decision frame I use after running both styles.

Two honest shapes

A) Docker / appliance WAF

Examples: SafeLine, BunkerWeb-style stacks, ModSecurity-in-compose.

Wins

Polished dashboards
Familiar deploy (docker compose up)
Often opinionated defaults for homelab

Costs

More containers, volumes, upgrades
Another network path to reason about
Host already busy? You feel it

B) Single-binary reverse proxy + WAF

Examples: Caddy + Coraza yourself, or a packaged product like Tiyi.

Wins

One process, one upgrade artifact
Fits “I already think in reverse proxies”
Easy to put on a tiny VPS / metal box

Costs

UI may be simpler than a full appliance
You still need to understand CRS false positives
Not a substitute for L3/L4 scrubbing

Decision checklist

Pick Docker appliance if most of these are true:

You’re fine operating Compose long-term
You want a rich security console first
Multiple teammates will click through the UI daily

Pick single binary if most of these are true:

You want scp / package / one systemd unit
Caddy (or Caddy-like) is already your front door
You’re optimizing for fewer failure domains on one node

What I run when constraints are “one box, CRS, low glue”

I use Tiyi: Caddy + Coraza + OWASP CRS 4 + admin UI/CLI in one Go binary, SQLite, free on a single node.

Site: https://www.tiyisec.com/
90s demo: https://www.tiyisec.com/assets/video/tiyi-demo.mp4
Source: https://github.com/zzmzm/tiyi

I’m not arguing it’s “more secure than SafeLine.” It’s a packaging choice: less stack, more “proxy with CRS.”

False friends

“WAF = anti-DDoS” — no. Different layer.
“CRS with defaults forever” — you’ll tune. Budget time for false positives.
“More containers = more secure” — sometimes just more surface.

Practical recommendation

Write down the threat: scanners/SQLi vs volumetric floods vs credential stuffing.
Pick the packaging that matches how you already operate.
Prove a block (SQLi probe + log) before you polish dashboards.

If you comment your stack (Caddy/Nginx/Traefik, Docker yes/no, one node vs cluster), I’ll suggest the boring default for that case.

Self-hosted WAF without Docker — Caddy + Coraza + CRS in one binary

Kai Ren — Mon, 10 Aug 2026 23:42:42 +0000

If you already reverse-proxy with Caddy (or you’re tired of ModSecurity glue), there’s a boring option that works well on a single VPS: put OWASP CRS in front of your apps and keep the ops surface small.

This post is the path I use when I want app-layer filtering (SQLi/XSS/scanners) without a compose stack.

What you actually need

For most small/medium self-hosted setups:

Layer	Job	What does not solve it
Edge / scrubbing	Volumetric DDoS, big botnets	A reverse-proxy WAF alone
App-layer WAF	SQLi, XSS, scanner junk, bad bots that look like browsers	Geo-IP blocks forever
Auth / rate limits	Credential stuffing, noisy clients	CRS by itself

Don’t sell yourself a WAF as a DDoS product. Use CRS for the application junk; keep rate limits / challenges / an upstream scrubber for the rest.

The packaging tradeoff

Common self-hosted WAF paths:

Docker WAFs (SafeLine and friends) — great UI, more moving parts.
Roll your own — Caddy/Nginx + Coraza/ModSecurity + CRS + dashboards — flexible, glue-heavy.
Single binary — reverse proxy + Coraza + CRS + admin UI in one process.

I’ve been using option 3 via Tiyi: one Go binary, SQLite, local admin UI/CLI, free on a single node. Demo (install → site → block SQLi):

https://www.tiyisec.com/assets/video/tiyi-demo.mp4

Install (Linux)

curl -fsSL https://www.tiyisec.com/install.sh | sh
tiyi run

Open the admin UI, set the admin password on first run, then:

Add an upstream (your real app)
Add a site (hostname → upstream)
Keep CRS enabled (default path)
Hit the site with a trivial SQLi probe and confirm a block + security log

Exact CLI flags change with versions — the site/quickstart is the source of truth.

A minimal “did it work?” check

Once the site is live on the proxy port:

# should be blocked / challenged by CRS
curl -i "http://127.0.0.1:18080/?q=1%27%20OR%20%271%27%3D%271"

Then check the security/events view in the UI (or CLI logs). If nothing shows up, you’re usually testing the wrong host/port or bypassing the proxy.

When not to use this

You need a full cloud WAAP / bot management suite
You must stay on Nginx/Apache modules only
You want multi-region active-active with a shared control plane on day one

For a homelab or a single production node where you already like Caddy semantics, the “one binary + CRS” shape is hard to beat.

DEV Community: Kai Ren