IronTraffic

A traffic and API manager in Rust. One binary that is an L4 and L7 load balancer, a reverse proxy, an API gateway, a Kubernetes and Gateway API ingress controller, and a clustered standalone server, with a dashboard that can actually change things.

Status: pre-1.0, foundational development. Nothing here is production ready yet. The plan is public in the issue tracker and the reasoning is in ARCHITECTURE.md. This README will not carry a performance number until a script in this repository reproduces it.

Why another one

The category has converged on a set of shared gaps. These are not opinions; each is verifiable against a competitor's source, issue tracker, or documentation:

• Nobody does zero-downtime for both configuration and binary. Projects that fork a process per configuration change get binary upgrade for free and can never make configuration apply cheap. Single-process projects get cheap configuration apply and have no story for replacing the binary. IronTraffic does both: an atomic snapshot swap for configuration, and descriptor handoff to the successor process for the binary, with connections preserved across each.

• Distributed rate limiting is usually wrong. The reference implementation an entire ecosystem depends on is a fixed-window counter, which admits twice the configured burst across a window boundary. Another product replicates counters between nodes by plain assignment, which is last-writer-wins on a counter and therefore not a join-semilattice, making the limit systematically permissive in proportion to the node count. The correct version is frequently sold as an enterprise add-on.

• Clustered certificate management is a paywall. One project removed it from its open source line and now documents its commercial tier as the answer for multi-replica deployments. Another has had the request open for a decade.

• Nobody publishes their memory cost. The request to measure per-connection and per-request memory has been open in the largest project in this category since 2020. IronTraffic states its per-connection budget, gates it in CI, and publishes the curve.

• The dashboard is the upsell. Read-only, or enterprise-gated, or deprecated. IronTraffic's is authenticated, write-capable, audited, and able to roll back, in the open source project, forever.

The full analysis, with citations, is what the issue tracker is built from.

Design in one screen

• One binary, four modes. run (everything, the default), proxy (data plane only), control (control plane only), validate (parse and diff a config, exit code is the answer).
• One internal representation. Files, the admin API, Kubernetes CRDs, Gateway API objects, Ingress resources, and service discovery all compile to one immutable snapshot. The Kubernetes controller is a configuration source, not a second implementation.
• The request path allocates nothing and locks nothing. Configuration is read from an immutable snapshot published with arc_swap. Counters are per-core. Both are CI-gated properties.
• Routing is O(path length), not O(route count). A compiled trie with build-time precedence, and all regexes in one multi-pattern automaton so catastrophic backtracking is not expressible.
• The data plane never stops. If the control plane, the cluster, or the Kubernetes API server is gone, every node keeps serving its last known good configuration indefinitely.

See ARCHITECTURE.md for the reasoning and the crate graph.

Running the first milestone

The first milestone (M1) forwards TCP bytes between a listener and a single configured upstream. examples/minimal.yaml is the smallest valid document:

apiVersion: irontraffic.io/v1
listeners:
  - name: web
    bind: "127.0.0.1:8080"
upstream:
  address: "127.0.0.1:9000"

Validate it first, which parses, checks, and exits without binding anything:

cargo run -p irontraffic -- validate --config examples/minimal.yaml

Then run it, against any listener already on port 9000:

cargo run -p irontraffic -- run --config examples/minimal.yaml

and confirm it forwards, from another terminal:

curl -v http://127.0.0.1:8080/

proxy runs the data plane alone, without the control-plane runtime; control has no work in this version and exits 0. See irontraffic --help for the full flag and exit code list.

What this version does not do

M1 forwards bytes; it does not parse HTTP or any other wire protocol carried over the connection. Concretely, this version:

• Does not parse HTTP/1.1, WebSocket upgrades, or any other protocol on the connection: it is a transparent byte forwarder for whatever the two ends agree to speak.
• Does not route: one upstream, configured once, for every listener.
• Does not add, remove, or rewrite any header, including Forwarded or X-Forwarded-*.
• Does not enforce request framing of any kind. A request-smuggling payload is therefore forwarded verbatim, because there is no HTTP layer here to have an opinion about it: do not place this version where an HTTP-aware security control is assumed to exist.
• Has no TLS: every byte, on both sides, is plaintext.
• Has no per-source-IP connection limit, so one source can occupy the whole connection cap (limits.max_connections).

See docs/THREAT-MODEL.md for the full account of what this version defends against and what it does not, mechanism by mechanism.

Data-plane-only build

A data-plane-only build is available for edge and k3s deployments:

cargo build -p irontraffic --no-default-features --features dataplane --release

In this build, run and control are refused with a usage error (exit code 2) before any configuration file is read or socket is bound. proxy and validate work exactly as they do in the default build.

In this version, the two binaries are nearly the same size because the control plane is only the runtime so far. The first control-plane-only dependency must add a cargo tree allowlist assertion that proves it is not pulled into the data-plane-only build.

Promises

COVENANTS.md is a set of falsifiable commitments: no paywalled security, no feature deleted from open source and sold back, no mandatory first-party infrastructure, no unexportable state, no telemetry, no relicensing. Each is written so that breaking it is unambiguous.

docs/WILL-NOT-IMPLEMENT.md says what we will not build and why, and which of those answers could change with evidence.

Contributing

Read CONTRIBUTING.md. If you are an AI agent implementing an issue, read AGENTS.md first; it is the standing contract.

Run scripts/gate.sh before opening a pull request.

License

Dual-licensed under MIT or Apache-2.0, at your option.