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

fixed-egress-proxy
# 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 socket

Where 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.