Egress proxies

Call third-party APIs from your machines with no API key inside the VM. The key lives on the platform and is injected in flight; an agent that leaks its environment leaks nothing.

How it works

Register a proxy: a destination API plus the secret headers to inject. Every proxy gets its own hostname (dots become dashes) under proxy.ironwire.sh:

api.stripe.com   →  https://api-stripe-com.proxy.ironwire.sh

Code inside an attached machine calls the proxy hostname exactly as it would call the real API: same paths, same request shape, no credential. The platform recognizes the calling machine (nothing to configure in the guest), injects your stored headers, and forwards over TLS to the real destination. Responses stream back unmodified, LLM streaming included.

A machine that is not attached, or anyone on the internet, gets a plain 403. The proxy only ever forwards to destinations you registered: it is not an open relay.

Register a proxy

ssh

$ ssh dashboard@ironwire.sh proxy add stripe --target api.stripe.com --header 'Authorization: Bearer sk_live_...'
proxy stripe → api.stripe.com
url: https://api-stripe-com.proxy.ironwire.sh
attach it: proxy attach stripe <machine>

dashboard

Press u, then a to add: label → target → header. The secret is masked as you type and never shown again.

Header values are write-only: after saving, every surface shows them redacted (Bear…4f2). Rotate a secret with proxy set-header; there is no way to read one back.

Attach it to machines

Registering grants nothing by itself; each machine is attached explicitly:

ssh

$ ssh dashboard@ironwire.sh proxy attach stripe web
attached stripe to web — live now; env vars (PROXY_STRIPE) on next restart

dashboard

Select the machine, space → u proxies, and toggle with space.

Attach and detach take effect at the proxy immediately: a detached machine's next call gets 403 proxy not attached. Only the env vars below wait for a restart.

Using it from inside the machine

Each attached machine gets PROXY_<LABEL> holding the proxy URL (on its next restart after attaching; the URL also works immediately if you use it directly):

$ curl $PROXY_STRIPE/v1/customers

For stock SDKs that read their own variables, declare extra envs on the proxy, templated on $PROXY_URL. ironwire has no per-vendor knowledge; you say exactly what your SDK needs:

$ ssh dashboard@ironwire.sh proxy add openai --target api.openai.com \
    --header 'Authorization: Bearer sk-...' \
    --env 'OPENAI_BASE_URL=$PROXY_URL/v1' \
    --env 'OPENAI_API_KEY=unused'

Attached machines then carry PROXY_OPENAI, OPENAI_BASE_URL, and OPENAI_API_KEY; the OpenAI SDK works unmodified, with no real key anywhere in the guest. (Most SDKs only require the key variable to be non-empty.)

Your own account or machine env vars always win over proxy-provided ones, so you can override locally at any time.

Rules & limits

Rule	Detail
no secret in the VM	No key, no stand-in token: a machine's access derives from the platform knowing which machine is calling.
opt-in per machine	Unattached machines get `403 proxy not attached`.
registered destinations only	Unknown hosts get `403 unknown destination`; redirects are returned, never followed.
injected headers win	Whatever the guest sends in a configured header is replaced, never merged.
targets	Public hostnames only: no IP literals, no private addresses, no platform domains.
limits	20 proxies per account · 8 headers per proxy · 4 KiB per value.
machines can't manage proxies	The in-VM CLI may `proxy list` (redacted; a machine without fleet access sees only the proxies attached to it) but never add, rotate, attach, or remove.

Full syntax: command reference.