Overview

iron-proxy is a single-binary egress firewall for workloads you don't fully trust. It enforces an allowlist on outbound HTTP and HTTPS, holds credentials so the workload never sees the real value, and records every request as structured JSON.

The allowlist is keyed on host. Domain globs (*.anthropic.com) and CIDRs both work. A warn mode logs without blocking, so you can size the list against real traffic before enforcement. Anything not on the list returns 403.

Credentials stay in the proxy process. Static API keys swap in for placeholders the workload sends. OAuth bearer tokens, AWS SigV4 and HMAC signatures, and GCP service-account tokens are minted per request from longer-lived material the workload never sees. See credential proxying for the full set.

Every request, allowed or blocked, becomes a JSON log line: host, method, path, status, duration, the policy that decided, the secrets injected. Pipe it to your SIEM, your warehouse, or jq.

One YAML file configures all of it. The same binary runs as a sidecar, a systemd unit, a daemon, or a CI step.

Try It

If you want a demo, run the quickstart. It's a local Docker Compose loop that shows allow, block, and secret-swap behavior in one terminal.

If you want to deploy in production, see deployment methods for the runtimes iron-proxy supports and the tradeoffs between them.

If you want to see what a real config looks like before you commit, browse the common setups below.

Common Setups

• CI/CD egress control: allowlist the registries and APIs a build needs, hold the registry tokens, log every request.
• AI coding agents: allowlist model APIs and source hosts, hold provider keys, log blocked calls.
• Sandboxed code execution: per-sandbox allowlist, scoped credentials, per-request audit log.

How It Compares

Open Source, With A Managed Option

iron-proxy is open source and runs anywhere you can run a Linux process. A managed control plane for policy, secrets, and audit aggregation across a fleet is in active development.