Innerwall: 41 days to a shipped open-source microsegmentation platform

On October 18 I launched Innerwall — an open-source microsegmentation platform for Linux VMs, bare metal and cloud instances. A control plane renders label-based policy into per-host rulesets; an agent on each workload observes the connections that reach it and programs them into the host's own nftables. Apache-2.0, repo here. First commit to launch took 41 days.

Why this exists. East-west traffic is where visibility runs out in most server estates, and segmentation projects die the same death everywhere: someone enforces a policy built from a diagram instead of from traffic, something critical breaks, and the project is rolled back forever. So Innerwall is built visibility-first. Workloads start in a mode where agents only observe. Policy is then simulated — the exact ruleset enforcement would install runs against real traffic with a logging rule in place of the drop — and the review tells you either that it's safe to enforce or exactly which peers, services and connection counts would be cut. An agent that went quiet is an evidence gap, and a review spanning one refuses to read safe. Only then do you promote.

The decisions are the product. Every architectural decision is an ADR, and all 22 of them are rendered publicly in the docs: why inbound-only first, why one owned nftables table and no custom datapath, why agents hold one persistent stream and nothing polls, why losing the control plane must change nothing on any host. CI enforces the record as much as the code — proto breaking-change gates, migration immutability, and automated review of every PR against the ADRs. I've also written up the thinking behind these decisions as a seven-part series on this site: Microsegmentation from First Principles.

The launch gate. I refused to launch on my own familiarity with the system. The gate was a cold run: stand up a pristine estate — control plane plus a handful of VMs — following only the published docs, the way a stranger would. That run surfaced real issues. The fixes landed before the release tag, and the estate was rebuilt from scratch to confirm them. Even then, the install re-verification after tagging v0.4.0 caught a packaging defect in the compose path, so v0.4.1 followed. That's the current release, and the docs are pinned to it.

What v1 is, and isn't. It is: the full observe → simulate → enforce loop, label-based policy with live validation and dry-run diffs, a flow map of real traffic, CSR-based agent enrollment over mTLS with short-lived auto-renewing credentials, cosign-signed releases, zero telemetry. It isn't: outbound enforcement (roadmapped), Windows (post-1.0), multi-operator. The roadmap is direction, not dates, and every item on it cites the decision that produced it.

If you run a server estate and have ever wanted to know what a firewall change would actually break — try it. It's three steps with Docker Compose to a running control plane, and I read every issue.