Backfire compared with writing your own proxy function

When each one wins

Build your own if outbound HTTP is part of your differentiated product and you want full control of the policy. Use Backfire if you would rather not own an SSRF blocklist, a key store and an audit trail.

The same call, side by side

// the proxy everyone writes first — and what it still misses
export default async function handler(req, res) {
  const target = new URL(req.query.url);
  if (!/^https?:$/.test(target.protocol)) return res.status(400).end();

  const upstream = await fetch(target);        // follows redirects by default
  return res.status(200).send(await upstream.text());
}

// missing: addresses checked after DNS, a redirect policy, a body ceiling,
// an enforced timeout, a credential per caller, and any record of the call

Worth knowing

• A proxy you host can sit inside your own network and reach private services. Backfire deliberately cannot, which removes a class of incident but also a class of use case.
• If you already run an API gateway with egress policy, that gateway may be the better home for this — Backfire is aimed at teams that do not want to build one.

Limits that stay your problem either way

• A proxy you host can reach services inside your own network. That is its advantage and the reason the guard has to be correct.
• You own the blocklist, the key store, rate limiting and log retention — plus the on-call when one of them drifts.
• A bug in a self-built proxy is an open relay inside your VPC, which is a different incident class to a refused target.
• Your platform bill still applies: idle resources, invocations and egress are charged either way.