Highly Available Identity-Aware Proxy: Self-Hosting Zero Trust Without a Single Point of Failure

An identity-aware proxy sits in front of every private application it protects and decides, per request, whether that request gets through. That's exactly what makes it dangerous to run as a single instance: it isn't just routing traffic, it's the thing standing between every user and every app behind it. If it goes down you've locked everyone out of everything it fronts which could be disastrous!

The short version:

• An IAP is harder to make highly available than a normal reverse proxy, because it's also holding identity, session, and policy state - not just routing rules.
• Self-hosted DIY stacks (auth proxy + reverse proxy + your own database) usually get HA bolted on late, if at all.
• Fully managed cloud IAPs (Cloudflare Access, Google IAP, and similar) are highly available by default, but that availability comes from decrypting your traffic in someone else's cloud.
• Pangolin runs as a self-hosted, clustered identity-aware proxy, where every node shares identity, policy, and certificate state and any node can serve any request.

Why an Identity-Aware Proxy Is a Harder HA Problem Than It Looks

Put a load balancer in front of a stateless web server and high availability is almost boring: any healthy instance can answer any request. An identity-aware proxy breaks that assumption in a few specific ways:

• It terminates TLS, so every node needs a valid certificate for every domain it might serve - not just one node.
• It evaluates policy per request - user identity, role, resource, sometimes device posture or IP - which means every node needs a current view of who's allowed to do what, not a cached copy that might be stale.
• It holds session state. A user who authenticated against node A shouldn't get logged out because their next request lands on node B.
• It's the thing everything else depends on. A normal app going down is an incident. An IAP going down is every app behind it going down at once.

None of that is exotic on its own, but it means "just put it behind a load balancer" isn't enough. The proxy nodes need to actually share state, not just share a hostname.

The Usual Ways People Try to Solve This

DIY: an auth proxy bolted onto a reverse proxy

A common self-hosted pattern is an auth layer like oauth2-proxy or Authelia sitting in front of nginx or Traefik, backed by a self-managed database for sessions and policy. This works well for a single instance. Making it highly available means solving, yourself, most of what a clustered IAP needs to solve natively: a shared session store, certificate distribution to every node, consistent policy across nodes, and a routing layer that knows which node can currently reach which backend.

Fully managed: cloud-brokered IAPs

Cloudflare Access, Google Cloud IAP, and similar products solve availability for you - that's a big part of what you're paying for. The tradeoff is architectural, not just financial: your traffic is decrypted in the vendor's cloud before it reaches your infrastructure, because that's where the identity check happens. For a lot of workloads that's fine but for regulated data it can be a problem. For example HIPAA and similar rules generally require that sensitive traffic stay unreadable to third parties in transit, and a mandatory decrypt-and-reencrypt in a vendor's data center works against that.

How Pangolin Runs as a Highly Available, Self-Hosted IAP

Pangolin combines an identity-aware reverse proxy with a WireGuard-based private network, and its self-hosted clustering makes the whole thing highly available.

In a Pangolin cluster, every node is a complete, interchangeable identity-aware proxy: it can authenticate a user, evaluate access policy, and terminate TLS for any domain in the deployment. That's possible because the state that would normally live in one process's memory is shared across the cluster:

• Identity and access policy live in a shared PostgreSQL database, so every node evaluates the same rules against the same user, not a stale local copy.
• Certificates are issued once and distributed to every node, so any node can terminate TLS for any protected domain.
• Session and connection state synchronize across nodes through a shared Redis-compatible layer, so a client isn't pinned to the one node it happened to authenticate against.
• Routing finds the right node automatically. If a request lands on a node that isn't the one currently holding the connection to a given backend, Pangolin relays it to the node that is. The client never sees the difference and TLS still terminates end-to-end between the client and the correct node. We go deep on exactly how that relay works in how we built high availability into Pangolin.

The result is an identity-aware proxy where losing a node means the load balancer stops sending it traffic - not an outage for every app behind it, and not a compliance conversation about which cloud your traffic was decrypted in.

What to Look for in a Self-Hosted, Highly Available IAP

• Does every node share the same identity and policy state, or can nodes disagree about who's allowed to do what?
• Is certificate issuance and renewal centralized, or does each node need its own manual TLS setup?
• Does a user get logged out or re-challenged just because a later request landed on a different node?
• Can the platform route a request to the correct backend even if it initially lands on the wrong node?
• Does getting HA require sending decrypted traffic through a third party's infrastructure?
• Can you add capacity by adding a node, without re-architecting how auth or policy works?

FAQ

Is an identity-aware proxy the same thing as a VPN?

No. An IAP sits in front of specific applications and makes a per-request access decision. A VPN gives a connected device broader network reach. Pangolin combines both models, so you can front web apps with an IAP and give trusted users VPN-style access to other resources through the same policy engine.

Can I make a self-hosted IAP highly available without clustering it?

You can get partial availability - Pangolin's free tier already supports multi-site failover for individual resources - but making the identity, policy, and certificate layer itself redundant requires clustering, since that's the state a single-instance IAP holds in memory.

Does clustering an IAP mean every node can see every user's traffic?

No. Nodes share identity, policy, and certificate metadata, not decrypted application traffic. A request is only ever decrypted on the node actually terminating that connection.

How is this different from putting a cloud IAP behind a CDN for availability?

A cloud IAP is highly available by design, but it achieves that by decrypting your traffic in the vendor's infrastructure. A self-hosted, clustered IAP gets the same node-level redundancy while keeping TLS termination on infrastructure you control.

Related reading

• What is an Identity-Aware Proxy (IAP)?
• How We Built High Availability Into Pangolin
• Understanding Clustering
• Peer-to-Peer Alternative to Cloudflare Tunnels with Edge TLS Termination
• Highly Available VPN: How to Remove the Single Point of Failure

Learn more

Ready to see it in action? Self-host Pangolin to get started, or reach out to our team to plan a clustered, highly available deployment.