Tecnativa vs Sockguard
Tecnativa's docker-socket-proxy is the community reference for ENV-var-based Docker socket filtering — simple, battle-tested, and backed by the largest established community in this category. Sockguard builds on that foundation with request body inspection, per-client policies, signed policy bundles, and Prometheus metrics — without any SaaS layer.
Feature Comparison
Here's how we compare on the features that matter most.
| Feature | Tecnativa | Sockguard |
|---|---|---|
| Method + path filtering | Yes | Yes |
| Config format | ENV vars (zero learning curve) | YAML config |
| Community size | 2.6k+ GitHub stars | Growing |
| Production maturity | Maintained since 2017 | Newer |
| Request body inspection | No | Yes (12+ resource types, Docker + Podman build) |
| Per-client policies | No | CIDR + labels + cert selectors + unix peer |
| Prometheus metrics | No | Yes (opt-in, finite-label socket-proxy metrics) |
| Signed policy bundles | No | Yes (separate pinned trust, keyed + keyless) |
| Rollout modes (enforce / warn / audit) | No | Yes (per-profile shadow mode) |
| Rate limits | No | Yes (per-profile token-bucket) |
| YAML config + hot-reload | No | Yes (opt-in, SIGHUP/fsnotify, validate endpoint) |
| Audit log schema | No | Yes (opt-in, JSON schema + reason codes) |
Key Differentiators
What we built that Tecnativa doesn't cover.
Request Body Inspection
Tecnativa filters by method and path only. Sockguard inspects bodies across 12+ resource types, including Docker and native Podman builds, before the daemon receives them.
Per-Client Policies
Every client sees the same rules with Tecnativa. Sockguard lets you assign different policies per CIDR range, Docker label, TLS certificate selector (including SPKI pinning), or Unix peer credential.
Signed Policy Bundles
Sockguard pins keyed or keyless trust in a separate bootstrap file, then verifies the candidate and every reload. The candidate cannot disable its own gate or redefine who may sign.
Prometheus Metrics
Sockguard exports request metrics, deny counts, and latency histograms with finite method and route labels. Tecnativa has no built-in metrics.
Rollout Modes
Shadow-mode enforcement lets you ship new rules without breaking anything. Sockguard's per-profile rollout modes (enforce / warn / audit) mean you can test a policy before it goes live.
Rate Limits
Sockguard's per-profile token-bucket rate limiter and global priority gate protect the daemon from runaway callers. Tecnativa has no request-rate controls.
No Upstream Reliability Regressions
Tecnativa v0.5.0, the version compared here, has an open regression since 2026-07-30 where its HAProxy 3.2.4 to 3.4.2 bump hangs GET /version for the full 10-minute default timeout, breaking Traefik, docktail, and crowdsec discovery that polls it (tecnativa/docker-socket-proxy#180, still open). Sockguard's /version passthrough isn't affected by that upstream dependency bump.
Coming from Tecnativa?
Start with the compatible ENV allow-list, plus SOCKGUARD_INSECURE_ALLOW_READ_EXFILTRATION=true, because a broad section grant such as CONTAINERS=1 covers the archive, export, log and attach endpoints and Sockguard fails startup rather than open them without an acknowledgment. Then map it to YAML before enabling signed policies, and drop the acknowledgment once the rules no longer need it. Signed mode rejects rule-generating compatibility variables so unsigned process state cannot modify verified rules. The socket mount stays the same.
$ docker run -d \
--name sockguard \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
-v /var/run/sockguard:/var/run/sockguard \
-e SOCKGUARD_LISTEN_SOCKET=/var/run/sockguard/sockguard.sock \
codeswhat/sockguardReady to try Sockguard?
Default-deny, Apache-2.0, no SaaS required. Drop it in front of your socket in minutes.