Innerwall

Open-source microsegmentation for heterogeneous server estates: VMs, bare metal, and cloud instances, no orchestrator required.

A small agent on each workload observes the connections that reach it and programs the operating system's native firewall. A control plane turns label-based policy into per-host rulesets, pushes them over persistent streams, and renders the estate's real traffic as a live dependency map. An operator console embedded in the control plane shows that map, the fleet, the policy, and what enforcing it would break.

Status: v0.5.1. Enrollment and short-lived workload identity, the policy sync stream, flow telemetry with evidence gaps, policy authoring with dry runs, simulation, and enforcement on Linux (nftables), and the operator console all work end to end. Releases ship binaries — downloadable, checksummed, and signed — and a published control-plane image, which the Docker Compose quickstart now runs exactly as published, never rebuilding it from the checkout. Install from a release: docs/reference/versioning-and-install.md. What is deliberately not built yet, and what comes next, is in ROADMAP.md; what changed in each release is in CHANGELOG.md.

The console

Each image puts a screen of the shipped console in its dark theme (left) beside the same state in its light theme. More are in docs/img/console/.

Simulation review. A ruleset's would-block traffic from the workloads simulating it, with the verdict on whether it is safe to enforce, the evidence it rests on, and the promotion to enforcement.

Flow map. The estate's real traffic between label groups, colored by what the policy decided or would decide.

Policy editor. Rules edited live, with every admission finding in place and a dry run that shows each workload's rendered change before anything is written.

Workloads. Every workload's mode, sync state against its latest rendered version, and agent health.

Why

• East-west traffic is the blind spot. Perimeter controls say nothing about lateral movement, and most estates cannot even see it.
• You cannot safely enforce what you cannot see. The workflow is visibility, then simulation, then enforcement: visibility is every workload's starting mode, the evidence is shown at each step, and promotion past evidence that does not support it takes an explicit acknowledgment (ADR-0001).
• The host already has a firewall. Innerwall programs the existing packet filter atomically and observably instead of shipping a datapath (ADR-0003).
• Central planes fail by being chatty. Agents hold one persistent stream; policy moves as versioned desired state; nothing polls the control plane (ADR-0002).
• Fail static. Losing the control plane changes nothing on any host. The policy an agent acknowledged is persisted before it is applied and stays enforced from local disk (ADR-0011, ADR-0020).

Quickstart

[!IMPORTANT] Before you start: decide where the agents will run. The agent runs only on Linux, as root, with nftables. If any agent will run on a machine other than the one running the control plane (always the case when Docker runs on macOS or Windows), first read Name the control plane before the first start. The gateway's certificate is generated once, at the first start, and names only that machine's local names, so an agent on another machine cannot enroll against it. If the stack already started without the right names, innerwall ca issue-server reissues the certificate from the same signing authority and a restart presents it; nothing is enrolled again (a stack that has already started).

The supported v1 deployment is one control-plane binary and one Postgres (ADR-0017). Run the released image with Docker Compose, or install the released binaries. These docs describe v0.5.1, and every command below names it.

With Docker Compose

git clone https://github.com/innerwall-dev/innerwall.git
cd innerwall
git checkout v0.5.1     # the release these docs describe; a fresh clone is main
echo 'INNERWALL_IMAGE=ghcr.io/innerwall-dev/innerwall:0.5.1' > .env
docker compose up -d    # pulls the released control-plane image and starts it with Postgres

.env (git ignores it) names the image for every later docker compose command. Compose keys the stack's volumes by the directory's name, so a clone into a directory named innerwall picks up whatever state an earlier innerwall stack left behind, even after that clone was deleted. To start clean beside an earlier stack, add a line COMPOSE_PROJECT_NAME=<a new name> to .env before the first start (how to tell, and the other way out).

Set the operator password (the command line on the host is the only place it can be set):

docker compose exec innerwall /innerwall operator set-password

It prompts twice, without echo: type the password (at least 12 characters) at each prompt. Nothing goes on the command line or into the shell's history. To provision without a terminal, pipe it in on standard input: docker compose exec -T innerwall /innerwall operator set-password < password-file reads one line.

This is the beginning of the README. Read the rest at the original. Read the full README ↗