---
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-08-03"
---

# Backends & Resilience

> Zuplo connects your gateway to any backend — public, private, or across clouds
> — without sharing long-lived static secrets. It ships workload identity
> federation, mTLS, a WireGuard secure tunnel, and programmable resilience
> (retries, timeouts, circuit breakers) as TypeScript policies running at the
> edge.

## Why this matters

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 unrelated to 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.

## What you get

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

Connect to any backend without sharing static secrets. 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

**Next actions:**
[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

Stop cascading failures before they reach your origin. 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

**Next actions:**
[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.md)

## What makes Zuplo different

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

**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 for Free](https://portal.zuplo.com/signup)
- [Read the Docs](https://zuplo.com/docs/articles/securing-your-backend)
- [Talk to a Solutions Engineer](/schedule-call)