Backfire vs a fixed-egress proxy
Backfire compared with a fixed-egress proxy
The phrase "egress proxy" covers two purchases that sound alike and solve unrelated problems. One gives your infrastructure a known source address so other people can recognise you — a NAT gateway, an egress cluster, a managed static-IP service. The other decides whether a specific outbound call is allowed to happen and leaves evidence that it did. Backfire is the second.
Which one you actually need
Setting up a NAT gateway or an egress fleet is the correct answer when the requirement is "our traffic must leave from these addresses". It is the wrong answer when the requirement is "a URL we did not write must be called safely from code that has no network controls at all".
What it controls
- A fixed-egress proxy
- Where traffic leaves from
- Backfire
- Where traffic is allowed to go
Layer
- A fixed-egress proxy
- Network — subnets, routes, NAT
- Backfire
- Application — one call at a time
Setup
- A fixed-egress proxy
- Cloud networking, one time per environment
- Backfire
- One bearer key and a POST
Identity to the target
- A fixed-egress proxy
- A stable set of addresses
- Backfire
- Relay infrastructure, attributed to your key
Guard against private ranges
- A fixed-egress proxy
- Only if you also build target validation
- Backfire
- Built in, checked after DNS on every call
Evidence
- A fixed-egress proxy
- Flow logs, if you enabled them
- Backfire
- A log line per attempt with the reason it was refused
Billing hazard
- A fixed-egress proxy
- Per-GB processing data charges
- Backfire
- A prepaid trip balance that never expires
Works from an agent runtime or a localhost
- A fixed-egress proxy
- Rarely, and not without networking
- Backfire
- Yes — it is an HTTPS POST
Side by side
# Networking answer: traffic leaves from known addresses
route 0.0.0.0/0 → nat-gateway → elastic IP
# ...but the destination is still whatever the request said it was.
# Backfire: the destination is the thing being decided
{ "url": "https://api.partner.example/v1/orders", "method": "GET" }
# private, loopback, link-local and metadata targets never open a socketWhere the other one wins
- A NAT gateway does not inspect the destination. Your function can still reach a metadata endpoint through it, and it will, because nothing stopped it.
- Infrastructure controls are the right ownership model when you own the network. Most of the code that now makes unvetted outbound calls — serverless handlers, agent tools, webhook consumers — sits outside the part of the network you can route.
- Flow logs are not an answer to "what did the model try to fetch". They record connections, not intent, and never the refusal.
- If your buyer wants network egress policy across a whole estate, this is not that product — see the allowlist gateway comparison instead.
What Backfire will not do
- Not a network control: traffic that does not go through the relay is not covered by it.
- No static addresses, no VPC peering, no routing — it is a call, not a path.
- Uncovered surface is real: anything that fetches directly still needs its own guard.
- If a compliance requirement names network egress, this does not satisfy it and we will not claim it does.
Other comparisons
Questions about this
Related reading
Try it with 5,000 free trips.
No card, no subscription, and the balance never expires.

