Pomerium in 2026: an architecture note on identity-aware proxying, the databroker, and why access control becomes a request path

Google's New Albany data center campus in central Ohio. The photo fits because Pomerium lives in this layer of infrastructure reality: it sits on the request path between real users and real services, then makes identity and policy visible there.[10]

Pomerium is easiest to misunderstand when it is pitched as a general "VPN replacement." That phrase is directionally useful, but it blurs the architecture. The stronger reading is narrower and more precise. Pomerium is an identity-aware access proxy that tries to move access control from network location to the request path itself: authenticate the user with an external IdP, evaluate policy, then decide whether a named route should forward traffic to a named service.[1][8]

That design choice matters because it lines up cleanly with the zero-trust model NIST describes in SP 800-207: protect resources rather than network segments, grant no implicit trust based on location, and perform authentication and authorization before a session to an enterprise resource is established.[8] Pomerium's official architecture page reads like an implementation of that posture for self-hosted internal services. The project does not start by asking which subnet a user entered. It starts by asking who the user is, what policy says, and which route the proxy should allow.[1]

Image context: the cover uses an official Google data center campus photograph rather than a lock icon or topology diagram. That is the right visual here because the article is about access control in real infrastructure environments, where users, proxies, IdPs, and upstream services all have to meet on an actual request path.[10]

1) The system boundary is the request path, not the subnet

Pomerium's architecture docs lay out the core traffic shape very clearly. The Proxy service receives the client request, calls the Authorization service over gRPC, redirects the user to the Authentication service if no valid session exists, stores session data through the Databroker, and only then maps the request to the configured upstream route.[1] That is the whole point of the product in one paragraph.

The practical consequence is that Pomerium works best when the unit of protection is a named resource: an internal web app, an admin panel, an SSH or TCP endpoint, a route that can be described with explicit policy, or a programmatic access surface with its own login flow.[1][4][5] Inference from the docs and the NIST model: Pomerium is strongest when a team wants identity and policy to ride with every access decision, not when the goal is broad network adjacency for everything behind a gateway.[1][8]

This is why the project feels different from a classic VPN. A VPN solves reachability first and policy later. Pomerium makes the route itself the object of policy. That yields cleaner access boundaries for many internal apps, but it also means teams have to think in routes, policies, and upstream services instead of in giant trusted zones.

2) The databroker is the real stateful center

The most revealing document in the Pomerium stack may be the persistence page. It explains why the project moved away from a cookie-heavy model: SPA breakage after session expiration, no central visibility into existing sessions, and group membership frozen at session-creation time.[2] The answer is the databroker, which becomes the authoritative stateful store while faster services keep local caches or query it in real time.[2]

That is a much more important architectural fact than "Pomerium integrates with Okta" or "Pomerium supports SSO." It means the project is not merely a stateless auth filter bolted in front of Envoy. It has a control-state center, and that center decides how durable the deployment is.

The persistence docs are blunt about the boundary conditions:

the default databroker backend is in-memory and easy to deploy, but not persistent or highly available,[2]
file storage persists across restarts, but still supports only a single instance,[2]
the Postgres backend supports multiple databroker instances and persistence across restarts, and the docs recommend a dedicated Postgres instance for the strongest security and performance guarantees.[2]

That is the operational dividing line. A serious production rollout is not only about IdP wiring and route policy. It is also about whether the team is willing to run the stateful layer properly. If you leave databroker on the default in-memory path, Pomerium remains a good demo and a fragile control point. If you give it Postgres and treat sessions as durable state, the design starts to feel infrastructure-grade.[2]

3) The security model is opinionated about separation

Pomerium's security page is useful because it makes a specific promise instead of a vague "zero trust" claim. The docs say Pomerium strips its _pomerium authentication cookies from requests before forwarding them upstream, specifically to prevent authentication tokens from leaking to backend services.[3] That is a concrete separation decision. Your application receives an authorized request, not the proxy's own session cookie.

The same page also clarifies a second boundary that matters in practice: authorization is request-based for HTTP routes, while TCP-based services are authorized on a per-session basis.[3] That distinction is easy to gloss over in marketing copy and very important in deployment review. HTTP can be checked and shaped on every request with headers and route context. Rawer protocols inherit a coarser session model. The product still supports them, but the enforcement grain changes.[3][6]

The external signal is better than the usual hand-waving too. Pomerium published a Cure53 security audit and said the impactful issues were resolved in later updates.[9] That does not make the software self-proving. It does show that the maintainers expect their security model to survive outside review, which is a stronger signal than a generic trust-center page.[9]

4) Expansion without losing the core shape

One reason Pomerium remains interesting in 2026 is that its surface area has widened without changing the basic control model. The reserved /.pomerium path gives the project a set of internal endpoints for user info, sign-out, discovery, JWKS publishing, device enrollment, and a programmatic login API.[4] Those routes are intercepted by the proxy rather than forwarded upstream.[4] That keeps operational features inside the same architecture instead of scattering them into sidecars and helper services.

Programmatic access shows the pattern especially well. The docs describe a login API that returns a cryptographically signed sign-in URL, then hands the client back an opaque pomerium_jwt token after the user completes login in a browser.[5] The client can then present that token to a proxied endpoint with Authorization: Pomerium ....[5] This is not an incidental convenience feature. It is the same design thesis extended to CLI and automation use: identity first, route-scoped authorization second, and a token that represents the proxy's access boundary rather than the upstream app's own native credential model.[5]

The routes portal extends the same idea to operator and user ergonomics. Pomerium's docs describe it as a personalized page listing all routes a user can access, and for non-HTTP routes it can surface the corresponding CLI commands needed to connect.[6] Inference from the current docs: the project is broadening into a route catalog and access entry point, but it still thinks in discrete resources rather than in undifferentiated network reachability.[4][6]

As of March 30, 2026, the latest GitHub release is v0.32.4, published on March 17, 2026.[7] That release is incremental, not a reinvention, which is the right maintenance signal for a project like this. The architecture is already established; the question now is whether the team keeps refining it without muddying its boundaries.[7]

5) Best-fit boundary and mismatch boundary

Pomerium is a strong fit when your organization can describe access as a set of named resources and wants IdP-backed policy checks to happen at that resource edge. Internal dashboards, admin tools, developer services, SSH-accessible hosts, and other routeable services fit naturally into that model.[1][4][5][6]

The mismatch appears when the environment demands something broader and less explicit:

whole-network access with minimal route modeling,
heavy dependence on coarse trusted zones,
workflows where administrators cannot realistically maintain resource-level policy and naming,
expectations that every protocol will enjoy the same per-request enforcement grain as HTTP.[3][8]

That is not a flaw in the project. It is the architecture telling the truth about itself.

Bottom line

Pomerium's core contribution in 2026 is not that it makes "secure access" feel modern. It is that it gives access control a narrower center of gravity: the request path, the route definition, the session state in databroker, and the policy check that decides whether traffic moves forward.[1][2][3]

If your team wants to protect named resources with identity-aware policy at that edge, Pomerium is a coherent OSS design. If your real goal is generalized network reachability with as little route thinking as possible, the product will feel tighter than the slogan suggests. That difference is exactly why the architecture is worth reading closely.

cronfeed.work