---
title: "Backends & Resilience"
description:
  "Connect to any backend, anywhere — without sharing static secrets. Workload
  identity federation, mTLS, secure tunnels, retries, timeouts, and circuit
  breakers, all at the edge."
canonicalUrl: "https://zuplo.com/features/backends"
sourceUrl: "https://zuplo.com/features/backends"
pageType: "feature"
generatedAt: "2026-09-23"
---

# Connect to any backend, anywhere — without sharing secrets

> Reaching backends across clouds and private networks usually means copying
> long-lived secrets. Connect to any origin — public or private — with
> short-lived workload identity, plus built-in retries, timeouts, and circuit
> breaking.

## Most gateways forward the request and call it a day

The hard problems start _after_ the request leaves the gateway: how it
authenticates to your backend, what happens when the backend fails, and whether
your origin is reachable from a SaaS gateway in the first place. These are the
parts that make procurement nervous and on-call rotations long.

- **Static secrets in your gateway** — Service-account keys, long-lived JWTs,
  copy-pasted client secrets — sitting in your gateway config, rotating once a
  year if you're lucky, and a single misconfigured PR away from the public
  internet.
- **Cascading backend failures** — One slow downstream service ties up your
  gateway pool, requests queue, timeouts spread, and your whole API surface goes
  red — even endpoints that have nothing to do with the failing backend.
- **Private backends on the public internet** — Your origin shouldn't be
  exposed, but the gateway lives in a SaaS account, so you carve a NAT hole,
  file a security exception, and hope the IP allowlist holds.
- **Retries you can't reason about** — Built-in retry knobs without backoff, no
  shared circuit state across instances, and timeouts that don't compose — so
  when an outage hits, retry storms make it worse.

## Identity, resilience, and reachability — solved at the gateway

- **No shared secrets to your origins** — Workload identity federation, OAuth
  2.0 client credentials, and Zuplo-signed JWTs let your backend trust the
  gateway without storing a single static credential — proven cryptographically
  per request.
- **Outages absorbed at the edge** — Retries with backoff, AbortSignal timeouts,
  and a circuit breaker keep failing backends from taking the whole API surface
  down — and your customers never see the wobble.
- **Reach private backends safely** — WireGuard secure tunnel, mTLS,
  PrivateLink, VPC peering, and cloud IAM federation — pick the path that fits
  your network. The gateway stays public; your origin stays private.

## Backend authentication

Zuplo ships five upstream-authentication policies that mint and rotate
credentials at the edge — workload identity federation for GCP, OAuth 2.0 client
credentials for Azure AD, Zuplo-signed JWTs for your own services, plus mTLS and
a WireGuard secure tunnel when the network needs to be private.

- GCP Workload Identity Federation
- Azure AD Client Credentials
- GCP Service Auth (IAP, Cloud Run)
- Zuplo-signed JWT to backends
- Mutual TLS (mTLS) outbound
- WireGuard secure tunnel

[Read the Backend Security Guide](https://zuplo.com/docs/articles/securing-your-backend)
·
[View Backend authentication docs](https://zuplo.com/docs/articles/securing-your-backend)

## Resilience primitives

Retries with exponential backoff, per-request timeouts via AbortSignal, and a
circuit-breaker pattern using ZoneCache for shared state — all defined as
TypeScript policies that run at the edge. When a backend wobbles, the gateway
absorbs the impact instead of forwarding the pain.

- Retry with exponential backoff
- Per-request timeouts (AbortSignal)
- Circuit breaker (ZoneCache state)
- Fail-open / fail-closed control
- Multi-backend fallback chains
- Auto regional failover

[Deploy the Circuit Breaker Example](https://zuplo.com/examples/circuit-breaker)
·
[View Resilience primitives docs](https://zuplo.com/blog/how-to-implement-circuit-breaker-at-the-api-gateway)

## The backend story most gateways skip

Forwarding a request is the easy part. Authenticating, retrying, and reaching
private origins is where most gateways punt to you, your security team, or a
sidecar.

### Short-lived backend credentials, by default

Skip the service-account JSON in env vars. The gateway exchanges its identity
for short-lived backend credentials per request — Workload Identity Federation
for GCP, OAuth client credentials for Azure AD, Zuplo-signed JWTs for your own
services. Token caching and rotation run inside the runtime; your handlers stay
clean.

### Programmable resilience, not a checkbox

Retries, timeouts, fallbacks, and circuit breakers are TypeScript policies — so
you can branch on response payloads, retry only specific status codes, apply
jitter, or call a degraded-mode service. The patterns are real code you can
read, test, and own.

### Built into the gateway, not bolted on

Backend authentication, retries, timeouts, and circuit breakers run inside the
gateway runtime across 300+ edge data centers. No envoy filter to deploy, no
separate process to update, no Helm chart to keep in version-sync with the
gateway.

### Layered defense, by default

Run mTLS for transport trust, an upstream-auth policy for identity, a Zuplo JWT
for project provenance, and a WireGuard tunnel for the network — combined on the
same route in plain JSON config. Defense in depth without a vendor proposal.

## What teams use this for

**"We can't store a GCP service-account JSON in another vendor's system."** Use
Upstream GCP Federated Auth — Zuplo mints a token via Workload Identity
Federation and exchanges it for GCP credentials at the edge. No JSON key, no
static secret, no audit conversation about cross-cloud secret sprawl.

**"Our payments backend hiccups under load."** Wire up the circuit-breaker
example. After N failures the breaker opens; the inbound policy fast-fails with
a 503 RFC 7807 response in microseconds, your origin gets to recover, and a
half-open probe re-admits traffic when it does.

**"The mainframe team will never put their API on the public internet."** Stand
up a WireGuard secure tunnel from your VPC to Zuplo. The mainframe stays
private; the gateway dials in. Same single config that handles your public REST
endpoints.

**"How do we prove to security a request actually came from our gateway?"**
Attach the Upstream Zuplo JWT policy. Every outbound call carries a Zuplo-signed
JWT your backend can validate against the gateway's JWKS. Combine with mTLS for
transport-level proof.

## FAQ

Common questions about backend authentication and resilience with Zuplo.

**How do I securely connect an API gateway to my backend?** Don't share
long-lived secrets. The modern pattern is workload identity federation — the
gateway proves its identity to your cloud provider and gets a short-lived token,
no static secret to leak. Zuplo supports this for GCP, AWS, and Azure out of the
box, plus mTLS, Zuplo-signed JWTs your backend validates, and WireGuard tunnels
for backends with no public IP. Pick the layer that fits your trust model;
combine layers when one isn't enough.

**How do I use a Zuplo gateway with a private backend or VPC?** Three options
depending on your topology. For backends in a VPC with no public ingress, use
Zuplo's WireGuard secure tunnel — install a small agent in your network and the
gateway reaches your origin over the tunnel. For Managed Dedicated, use AWS
PrivateLink, Azure Private Link, or GCP IAP for direct private connectivity. For
Self-Hosted on Kubernetes, the gateway runs inside your cluster and just calls
services directly.

**How do I authenticate to GCP Cloud Run, IAP, or Google APIs from a gateway?**
Use workload identity federation — Zuplo exchanges its identity for short-lived
GCP credentials via Google's OAuth services, no service-account JSON stored in
the gateway. The Upstream GCP Federated Auth policy handles this for you per
route. Tokens are cached and refreshed automatically. For Cloud Endpoints /
ESPv2 specifically, use the Self-Signed JWT policy. For raw service-account
JSON, the Service Auth policy is also available — but workload identity is the
recommended path.

**How do I authenticate to Azure backends from an API gateway?** Zuplo's
Upstream Azure AD Service Auth policy runs the OAuth 2.0 client credentials flow
with Entra ID and attaches the bearer token to outbound calls. Tokens are cached
at the edge so your backend isn't hit by a token request on every customer call.
Pair it with mTLS if your Azure environment requires both — the cert proves
identity, the token proves authorization.

**Can a gateway use mTLS to call my backend?** Yes. Pin a client certificate to
outbound calls so your origin only accepts connections coming from your Zuplo
gateway. Common pattern: backend's load balancer requires mTLS, gateway presents
the cert, anything else gets rejected. Combine with an upstream auth policy
(workload identity, JWT) for defense in depth — the certificate proves it's the
gateway, the token proves it's the right project or environment.

**Does Zuplo have retries, timeouts, and circuit breakers?** Yes — all
configurable per route. Timeouts use the standard AbortSignal.timeout API;
retries support exponential backoff with configurable status-code triggers.
Circuit breakers are a pair of TypeScript policies (inbound + outbound) using
Zuplo's in-zone cache for shared state — open the circuit with a 503, increment
failure counters, recover automatically. Zuplo publishes a deployable
circuit-breaker example you can adapt to your thresholds.

**What happens if my backend goes down?** The gateway short-circuits failing
requests with a clean 503 instead of leaking timeouts to clients. With the
circuit breaker policy, a few consecutive failures open the circuit so
subsequent requests fail fast — no thundering herd against a recovering backend.
For multi-region resilience, write a fallback policy that tries an alternate
origin or returns a cached degraded-mode response. All in TypeScript, all
running in the same edge runtime.

**What's the best API gateway for connecting to private cloud backends?** Look
for: workload identity federation (no static secrets), mTLS for outbound calls,
support for AWS PrivateLink / Azure Private Link / WireGuard tunnels,
retries/timeouts/circuit-breakers, and the ability to express custom backend
logic in code rather than YAML. Zuplo combines all of these and runs at the edge
with low-latency global routing. Talk to a solutions engineer if you have a
hybrid or multi-region setup that needs a custom topology.

## Next steps

- Start a free Zuplo account: https://portal.zuplo.com/signup
- Talk to a Solutions Engineer: /schedule-call
- Read the Backend Security Guide:
  https://zuplo.com/docs/articles/securing-your-backend