# iron.sh

> iron-proxy documentation

## Docs

- [Getting Help](/help): Three ways to reach us.
- [Quickstart](/quickstart): Run iron-proxy locally with Docker Compose. By the end, you have a running proxy that allowlists specific hosts, blocks everything else, and swaps proxy tokens for real secrets. The setup uses the [docker-compose example](https://github.com/ironsh/iron-proxy/tree/main/examples/docker-compose) from the iron-proxy repo.
- [AI Coding Agents](/use-cases/ai-coding-agents): An iron-proxy in front of an AI coding agent allowlists the model APIs and source hosts the agent needs, holds the model provider keys, and logs every request including the blocked ones.
- [CI/CD Egress Control](/use-cases/ci-cd): An iron-proxy in front of a CI runner allowlists the registries and APIs the build needs, holds the registry tokens and credentials the build uses, and logs every request with method, host, path, status, and the policy that decided.
- [Sandboxed Code Execution](/use-cases/sandboxed-code): An iron-proxy in front of a sandbox allowlists the hosts the sandboxed code can reach, holds any credentials the platform exposes to that code, and logs every outbound request with the policy that decided.
- [Configuration](/reference/configuration): iron-proxy is configured via a single YAML file, passed at startup with the `-config` flag:
- [Header Allowlist](/policies/header-allowlist): The `header_allowlist` transform strips any request header not in a configured allowlist before forwarding upstream. Workloads send a lot of headers you may not want upstream to see: cookies, internal trace IDs, debug headers, telemetry. `header_allowlist` enforces a minimum surface area at egress regardless of what the workload's HTTP client is doing.
- [Host Allowlist](/policies/host-allowlist): The `allowlist` transform decides which destinations the workload can reach. Requests to hosts not in the allowlist return 403. This is the default-deny boundary; everything else iron-proxy does runs on top of it.
- [LLM Judge](/policies/llm-judge): The `judge` transform calls a large language model to produce an allow or deny decision for outbound HTTP requests. Each judge instance carries its own natural-language policy, LLM backend, and URL rules. You can deploy zero, one, or many judges with different prompts scoped to different destinations.
- [MCP Interception](/policies/mcp-interception): iron-proxy can enforce a default-deny tool allowlist on Model Context Protocol (MCP) servers. Denied `tools/call` invocations are rejected with a JSON-RPC error envelope before they reach the upstream server, and `tools/list` responses are filtered so denied tools never appear in the agent's tool catalog.
- [Concept: Transforms](/policies/transforms): A transform is a single processing step that runs on every outbound request. Every policy in iron-proxy is configured as a transform: the host allowlist, credential injection, signing, the LLM judge, header stripping. They all share the same shape (a `name` and a `config` block), live in the same ordered list, and run on every request.
- [Managing CA Certificates](/guides/ca-certificates): iron-proxy intercepts TLS traffic by acting as a man-in-the-middle: it terminates the client's TLS connection, inspects or transforms the request, then opens a new TLS connection to the upstream server. To do this, it needs a CA certificate and private key to mint leaf certificates on the fly for each upstream host.
- [Configuring OTEL Export](/guides/otel-export): Starting in `v0.7.0`, iron-proxy can export audit logs as OpenTelemetry structured log records. This lets you send every proxied request to any OTLP-compatible backend: Axiom, ClickHouse, Logfire, Grafana Cloud, or your own collector.
- [Tunneling with SOCKS5 and CONNECT](/guides/socks5-connect): iron-proxy can accept traffic via SOCKS5 and HTTP CONNECT tunnel requests in addition to its standard DNS-based interception. This is useful when you cannot control DNS resolution but can configure a proxy address: for example, applications that support `HTTPS_PROXY`/`ALL_PROXY` environment variables, or tools with built-in SOCKS5 support.
- [Deploy on Bare Metal](/deploy/bare-metal): Run iron-proxy directly on a Linux host: a physical server, a cloud VM, or any other machine where you control the network stack. This is the [embedded in a VM or sandbox](/deploy/overview#embedded-in-a-vm-or-sandbox) deployment pattern.
- [Deploy on Daytona](/deploy/daytona): Run iron-proxy inside [Daytona](https://www.daytona.io/) sandboxes. You build a custom Docker image with iron-proxy pre-installed, then use Daytona's [declarative builder](https://www.daytona.io/docs/en/declarative-builder/) to launch sandboxes with egress control already configured.
- [Deploy on Amazon ECS](/deploy/ecs): Run iron-proxy as a [daemon service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html#service_scheduler_daemon) on Amazon ECS. The proxy intercepts all outbound HTTP/HTTPS traffic from workload containers and checks it against a domain allowlist.
- [Deploy on Freestyle](/deploy/freestyle): Run iron-proxy inside [Freestyle](https://freestyle.sh) VMs. You create a VM snapshot with iron-proxy pre-installed, then use that snapshot to launch ephemeral VMs with egress control already configured.
- [Deploy on GitHub Actions](/deploy/github-actions): The [iron-proxy GitHub Action](https://github.com/ironsh/iron-proxy-action) runs iron-proxy inside your GitHub Actions workflows. It intercepts all outbound HTTP/HTTPS traffic and checks it against a domain allowlist.
- [Deploy on Kubernetes](/deploy/kubernetes): Run iron-proxy inside a Kubernetes cluster as a Deployment behind a Service with a fixed ClusterIP. Workload pods point their DNS at that ClusterIP, which routes lookups and TLS traffic through the proxy.
- [Deployment Methods](/deploy/overview): iron-proxy is a single binary, and how you place it determines the tradeoffs between circumvention resistance, operational complexity, and isolation. This page covers four common patterns and when to use each.
- [AWS Request Signing](/credential-proxying/aws-auth): The `aws_auth` transform re-signs inbound AWS SigV4 requests with real credentials, so workloads can configure their AWS SDK with placeholders and point at the proxy.
- [GCP Service Accounts](/credential-proxying/gcp-auth): The `gcp_auth` transform mints Google Cloud access tokens from a service-account keyfile and injects them as `Authorization: Bearer` headers on matching requests.
- [HMAC Request Signing](/credential-proxying/hmac-sign): The `hmac_sign` transform signs outbound requests with HMAC and injects the signature into the headers the upstream expects.
- [OAuth2 Token Injection](/credential-proxying/oauth-token): The `oauth_token` transform mints short-lived OAuth2 access tokens and injects them as `Authorization: Bearer` headers on matching requests.
- [Credential Proxying](/credential-proxying/overview): iron-proxy holds the credentials your workloads use to call upstream APIs, so the workloads never see the real values.
- [Static Secrets](/credential-proxying/static-secrets): The `secrets` transform applies a fixed credential (API key, bearer token, basic-auth password) to outbound requests so the workload never holds the real value.
- [Enrollment](/control-plane/enrollment): A new iron-proxy joins the control plane by running a one-time `init` command with an enrollment token. The proxy registers itself, picks up the tags configured on the token, pulls its initial configuration, and begins reporting audit events. After enrollment, the proxy stores a long-lived credential on disk and does not need the enrollment token again.
- [Overview](/control-plane/overview): A single iron-proxy is a default-deny firewall for one workload. A fleet of them is a distributed system, and distributed systems need a control plane. The iron-proxy control plane is that layer.
- [Policies](/control-plane/policies): A policy is a named allowlist that tells matching proxies which hosts, paths, and methods they can reach. Policies are authored in the control plane UI and delivered to every proxy whose tags match the policy's match set. Changes propagate within seconds of saving, without restarts.
- [Self-Hosted](/control-plane/self-hosted): The control plane runs inside your own network with the same software, API, and proxy protocol as the hosted version. Policy data, enrollment tokens, and audit logs never leave your infrastructure, and the deployment can be fully air-gapped. Source is available.
- [MCP Policies API](/control-plane/api/mcp-policies): MCP policies enforce default-deny tool allowlists on Streamable HTTP MCP servers. See [MCP Interception](/policies/mcp-interception) for the runtime semantics, JSON-RPC handling, and `tools/list` filtering behavior.
- [Network Policies API](/control-plane/api/network-policies): Network policies are named egress allowlists. Each policy targets a subset of the fleet by tag and lists the hosts, paths, and methods those proxies are allowed to reach. See [Policies](/control-plane/policies) for the conceptual overview.
- [API Overview](/control-plane/api/overview): The control plane exposes a JSON API for managing policies, proxies, and other fleet resources. Anything you can do in the control plane UI under **Policies** is available over the API.
- [Secret Policies API](/control-plane/api/secret-policies): Secret policies tell matching proxies how to apply a credential at the egress boundary, so workloads never see the real value. See [Credential Proxying](/credential-proxying/overview) for the runtime semantics, and [Static Secrets](/credential-proxying/static-secrets) for source backends.