Which open-source identity-aware proxy fits your situation
An internal app with no login of its own needs a proxy that performs the sign-in, and each of the three options fits a different setup. Choose Authelia if you already run a supported reverse proxy such as Traefik, NGINX or Caddy and want a login portal and second factors added to it without replacing that proxy. Choose Pomerium if you want the proxy itself to enforce identity and context-aware policy on each route and you are ready to put a new component in the traffic path. Its Core edition is Apache-2.0. Choose OAuth2 Proxy if you need a small MIT-licensed proxy that authenticates users against an OIDC or OAuth2 provider and forwards identity to the app in headers, either as the front proxy or as middleware beside your existing one.
None of the three is a full identity provider. Pomerium relies on an external provider such as Keycloak, Okta or Microsoft Entra ID for user identity, and OAuth2 Proxy relies on the OIDC or OAuth2 provider it is pointed at. Authelia can check first-factor passwords against LDAP or a YAML file, but it has no SAML support, so a SAML-only app cannot sit behind it directly. In many deployments, Keycloak or authentik sits behind these proxies as the system that holds users, groups and MFA policy. Confirm where your users and groups live before you choose, because that decision determines what the proxy must store and how group membership reaches the app.
Before you commit, run three checks in your own environment. First, confirm that the reverse proxy the app already uses appears on Authelia's supported proxies page, and that the app can serve HTTPS, since Authelia only works for HTTPS sites. Second, confirm that the app can accept identity headers, because OAuth2 Proxy and Pomerium both pass user, group and email data that way and the app must trust and parse it. Third, ask the vendor or your implementation partner which edition covers the features you need, such as directory sync, Rego policies or administrator RBAC, since Pomerium reserves several of these for its Enterprise edition.
Which proxy suits which scenario
This table maps common starting points to the proxy that fits best and the supplied fact behind that choice. Read each row against your own proxy, cluster and identity setup, because the best fit often changes with the estate you already run. Treat each answer as a starting point to confirm in a proof of concept, not a final decision.
| Scenario | Best fit | Reason and what to confirm |
|---|---|---|
| Existing NGINX or Traefik estate | Authelia | Authelia lists Traefik, NGINX, Caddy, Envoy, HAProxy and others as supported proxies, so it can sit beside your current proxy. Confirm your exact proxy version and auth request pattern against the supported proxies page. |
| Existing NGINX estate needing header-based identity | OAuth2 Proxy | Its set-xauthrequest option returns X-Auth-Request user, groups and email headers for nginx auth_request mode. Confirm that your upstream apps read those headers safely and that they cannot be spoofed by clients. |
| Kubernetes ingress | Pomerium | Pomerium publishes an Apache-2.0 Kubernetes Ingress Controller for running it as ingress for Kubernetes services. Confirm how your cluster, certificates and ingress class will be managed before you adopt it. |
| Kubernetes, with an existing ingress controller | OAuth2 Proxy or Authelia | Both can sit in front of services behind an existing controller, as middleware or companion. Confirm which one your ingress controller integrates with cleanly, since the supplied facts do not settle that for you. |
| Small team with one or a few web apps | Authelia or OAuth2 Proxy | Authelia adds two-factor authentication and a login portal, while OAuth2 Proxy is a single component that adds OIDC login in front of one app. Confirm how many apps and users you expect to protect in the next year. |
| Need for SSH, TCP or UDP access without a VPN | Pomerium | Pomerium Zero plans include native SSH, TCP and UDP access through the Pomerium CLI or desktop app, while Authelia and OAuth2 Proxy focus on HTTP apps. Confirm which access features your edition includes, since Zero and Core differ. |
| Group-based authorization in a central policy file | Pomerium | Pomerium's policies are defined in its configuration and Zero adds attribute-based policies, while Rego policies are reserved for the Enterprise edition. Confirm whether a central file is enough or whether you need the Enterprise policy engine. |
| Group-based authorization from an LDAP directory | Authelia | Authelia authenticates against LDAP sources such as FreeIPA or Active Directory, so group membership can come from your directory. Confirm group attribute mapping and how many nested groups your directory uses. |
| Need to avoid storing session state in a database | OAuth2 Proxy | By default it keeps sessions in encrypted client-side cookies that require a cookie secret. Confirm the trade-off, because concurrent token refreshes can force users to log in again. |
How Pomerium, Authelia and OAuth2 Proxy each work
All three tools put a login step in front of applications that have none of their own, but they differ on who performs authentication and who makes the access decision. Read each card for the component that does the work, the license that governs it, and the release line you would be committing to.
Pomerium as an identity-aware proxy
Pomerium is an identity and context-aware reverse proxy that sits in front of internal web apps and other services and handles the connection without a corporate VPN. It authenticates users through OAuth 2.0 and OIDC against providers such as Keycloak, Microsoft Entra ID or Okta, then evaluates policy on each request. The Core edition is Apache-2.0 and open source, while Zero and Enterprise are commercial tiers. Check which features you need before assuming the free Core covers them, because directory sync, Rego policies and session management sit in Enterprise. The current release is v0.33.4, published on October 2, 2026.
Authelia as a companion server
Authelia is a two-factor authentication and single sign-on server that does not proxy traffic itself. Your reverse proxy asks Authelia whether each request may pass, and unauthenticated users are redirected to Authelia's login portal. It is licensed under Apache-2.0, and the current release is v4.39.28, released on September 17, 2026. Because its session cookies require HTTPS, plan certificates for every protected site before you deploy, and confirm that your proxy, such as Traefik, NGINX or Caddy, appears on the supported list.
OAuth2 Proxy as proxy or middleware
OAuth2 Proxy is a reverse proxy that adds authentication with Google, Microsoft Entra ID, GitHub and generic OIDC providers. It can sit in front of an app as the proxy itself, or run as middleware beside an existing NGINX setup through its auth_request mode. It is distributed under the MIT License, is a Cloud Native Computing Foundation Sandbox project, and the current release is v7.15.5, published on October 1, 2026. Decide early where sessions live, because cookie sessions cannot be locked and Redis adds a component to run.
Who authenticates in each model
Pomerium and OAuth2 Proxy both perform the OIDC login themselves and pass identity onward, while Authelia verifies credentials against an LDAP directory or a YAML user file before answering the proxy. This split decides where your user store and second factors live. If you already run FreeIPA or Active Directory, confirm that the backend you choose can reach it, and that group claims arrive in the form your apps expect. Test that path before you choose the tool.
Licensing boundaries to confirm
The three licenses differ in scope. Apache-2.0 covers Authelia and Pomerium Core, while OAuth2 Proxy uses MIT. Pomerium Zero is a managed control plane with a self-hosted data path, and Enterprise adds a self-hosted control plane, so the license of the core does not describe the commercial tiers. Ask vendors in writing which components are covered by which terms, which features require a paid tier, and whether support is included in any subscription.
How the three proxies compare on capabilities and licensing
This table sets Pomerium, Authelia and OAuth2 Proxy side by side on license, authentication sources, proxy fit, policies, second factors, session storage and paid tiers. Read each row against your own applications: the right choice depends on which identity source you already run and whether you need features that sit behind a paid tier.
| Capability | Pomerium | Authelia | OAuth2 Proxy |
|---|---|---|---|
| License (open-source core) | Pomerium Core under Apache-2.0 | Apache-2.0 | MIT License |
| Current release (as supplied) | v0.33.4, published October 2, 2026 | v4.39.28, released September 17, 2026 | v7.15.5, published October 1, 2026 |
| Who authenticates users | OAuth 2.0 and OIDC identity providers such as Keycloak, Microsoft Entra ID and Okta | LDAP directories (OpenLDAP, FreeIPA, Active Directory) or a YAML user file; OIDC provider support; no SAML | Generic OIDC and OAuth2 providers, plus dedicated Google, Microsoft Entra ID, GitHub and login.gov providers |
| Supported reverse proxies | Pomerium serves as the proxy itself; a Kubernetes Ingress Controller is also published under Apache-2.0 | Traefik, Caddy, Envoy, NGINX, NGINX Proxy Manager, SWAG, HAProxy and Skipper; Apache and IIS listed separately | Runs as the reverse proxy in front of an app, or as middleware alongside existing proxies such as nginx auth_request |
| Policy model | Attribute-based policies and continuous authorization in Zero; Rego policies and RBAC for administrators in Enterprise | Access rules applied by the proxy per request; confirm the exact rule model in the Authelia documentation | Forwards user, group and email identity as headers; access rules are set by the proxy configuration (confirm details with the vendor) |
| MFA options | Confirm with the vendor which second factors each tier supports | One-time passwords, security keys, passkeys and Duo mobile push | Inherits MFA from the upstream identity provider (confirm with the vendor) |
| Session storage | Confirm with the vendor for the Core deployment | PostgreSQL, MySQL or local SQLite for preferences, second factor registrations and authentication logs | Encrypted client-side cookies by default (requires a cookie secret), or Redis, Redis Sentinel or Redis Cluster |
| HTTPS requirement | Confirm with the vendor | Required; sessions use cookies that need HTTPS, and plain HTTP is not supported | Confirm with the vendor against your deployment |
| Features in paid tiers | Directory sync, Rego policies, RBAC for administrators, session management and SSH session recording sit in Enterprise; Zero plans are paid and not open source | Core features listed here are open source; confirm with the vendor whether any commercial support tier applies | No paid edition is listed in the supplied sources; confirm with the vendor |
Where policy, MFA and identity headers differ
The main difference is where access decisions and second factors live. Authelia makes its own access decisions through its rules engine and offers several second factors itself: one-time passwords, security keys and passkeys, and Duo mobile push. OAuth2 Proxy takes a different position. It relies on the upstream identity provider for MFA and passes identity to the app as headers such as X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email. Authelia matters most for a team with no existing MFA service that wants a second factor in front of legacy apps. OAuth2 Proxy matters most for a team that already runs MFA in Keycloak or Microsoft Entra ID and only needs the proxy to enforce that login and forward who the user is. Confirm which of these you already own before you choose, because running a second MFA layer creates a second enrollment and recovery process to maintain.
Pomerium sits between these two models. Its Zero plans list attribute-based policies and continuous authorization, so access can be evaluated against user and device attributes over the life of a session rather than only at login. Its Enterprise edition reserves Rego policies, RBAC for administrators and session management. These controls matter when policy must be written as code, reviewed by a security team, or delegated to administrators with limited roles. A small team with a few routes and simple group rules may never need them. Before you commit, ask the vendor which policy features run in your self-hosted Core cluster and which depend on the managed control plane, because the Zero and Enterprise lists differ.
Header-based identity needs one check that is easy to skip. An app that trusts X-Forwarded-User will accept any request that reaches it with that header, so the proxy must be the only path to the app and the app must strip client-supplied copies of these headers. Test this directly by sending a request to the app's backend address with a forged header and confirming it is refused. If the app cannot restrict its own trust, prefer a design where the proxy answers the authorization question and the app never parses identity from headers at all.
Which setup each proxy suits
If your web apps already sit behind NGINX, Traefik or Caddy, Authelia is usually the most direct fit because it was built as a companion to those proxies. The proxy asks Authelia whether each request is allowed, and unauthenticated users are sent to Authelia's login portal. Authelia's supported proxies list includes Traefik, Caddy, NGINX, NGINX Proxy Manager, SWAG and HAProxy, so you change the proxy configuration rather than replacing the entry point.
- Proxy match: Confirm that your exact proxy and version appear on the supported proxies page, and check whether Apache or IIS is in use, since those are listed separately.
- HTTPS everywhere: Authelia only works for sites served over HTTPS because its session cookies require it, and the project does not support plain HTTP. Plan certificate handling before you start.
- Second factors: One-time passwords, security keys, passkeys and Duo push are available, which matters if you need MFA on top of an existing login.
- Condition for change: If you need to forward user identity and groups as headers to apps that do not speak OIDC, OAuth2 Proxy is also designed for nginx auth_request mode and may fit better.
Confirm where sessions and registrations must be stored, because Authelia keeps preferences, second factor device registrations and authentication logs in PostgreSQL, MySQL or SQLite.
In a Kubernetes cluster, the question is whether your ingress layer is already fixed and whether you want the proxy itself managed as a cluster resource. Pomerium publishes a Kubernetes Ingress Controller under Apache-2.0, which is the most direct match for running Pomerium as the ingress for cluster services. OAuth2 Proxy is also commonly deployed alongside ingress controllers and works as middleware with existing proxies, which makes it a reasonable choice when you want a small, single-purpose component.
- Ingress ownership: Confirm whether your platform team wants Pomerium to act as the ingress or whether an existing ingress controller must stay in place.
- Session storage: OAuth2 Proxy keeps sessions in encrypted cookies by default or in Redis, including Sentinel and Cluster modes. Cookie sessions cannot be locked, so concurrent token refreshes can force users to log in again. Redis avoids that but adds a service you must run.
- Policy model: Pomerium offers attribute-based policies in its Core and Zero tiers, while several policy and directory features sit in its Enterprise edition. Check which features you need before choosing a tier.
- Condition for change: If your Kubernetes access needs centre on kubectl and the API server rather than web apps, a dedicated SSO path for the cluster may be a better fit than a web proxy.
Confirm your replica count, how the cluster handles TLS certificates and whether a Redis service is acceptable in your environment.
For one internal app on a single virtual machine or small host, the main goal is low moving parts. OAuth2 Proxy is a small reverse proxy under the MIT License that can sit directly in front of one app and pass identity upstream as headers such as X-Forwarded-User and X-Forwarded-Groups. Authelia is also a good fit when you want a separate login portal and MFA for several apps on the same host, and it can store its data in local SQLite without a separate database server.
- Simplest path: OAuth2 Proxy with cookie sessions needs no external service, but it requires a cookie secret to be generated and kept safe.
- Multiple apps on one host: Authelia gives one login portal and second factors across several sites, but it depends on a proxy in front of them.
- Session persistence: SQLite suits a single node. If you later add a second host, you will need PostgreSQL or MySQL, so decide early.
- Condition for change: If the app needs its own user management and you have no existing directory, an identity provider such as Keycloak may cost more to run but avoids future rework.
Confirm that the host is reachable only over HTTPS and that backups cover the session or storage files you choose.
If the same team also needs SSH, TCP or UDP access to internal systems, a web-only proxy is not enough, and the choice moves toward Pomerium. Pomerium describes itself as a reverse proxy for clientless connections to internal web apps and other services without a corporate VPN. On Pomerium Zero, native SSH, TCP and UDP access runs through the Pomerium CLI or desktop app, alongside web access, Kubernetes access and attribute-based policies. Authelia and OAuth2 Proxy are built around HTTP requests, so they do not cover these protocols.
- Protocol coverage: Pomerium Zero includes native SSH, TCP and UDP access, but confirm that the tier and client you choose match your protocols.
- Where the control plane runs: With Pomerium Zero, you run the Core cluster in your environment while Pomerium hosts the control plane, so application traffic stays with you. Check whether a hosted control plane is acceptable under your policies.
- Edition gaps: Directory sync, Rego policies, administrator RBAC, session management and SSH session recording are reserved for Enterprise, so check these against your audit needs.
- Condition for change: If you need full privileged session control for SSH and databases, a dedicated PAM platform is usually a better match than a proxy.
Confirm your licensing budget and whether a self-hosted control plane is required, since that determines the edition you need.
What the license and paid tiers mean for your team
Pomerium Core (Apache-2.0), Authelia (Apache-2.0) and OAuth2 Proxy (MIT) are open-source projects that you can run in your own environment without a license fee. The licenses do not limit production use, but they do not include vendor support, guaranteed fixes or a managed control plane. Pomerium's commercial tiers are Zero, a hosted control plane with a customer-run data plane, and Enterprise, a self-hosted control plane with extra administrative features. Authelia and OAuth2 Proxy have no commercial tier in the sources supplied for this page, so confirm with each project whether paid support is available before you budget for it.
If you choose Pomerium Zero, the Pomerium pricing page lists Zero Business at $9 per user per month billed monthly or $7 per user per month billed annually. Zero Business allows 5 clusters, 100 routes, 100 policies and 5 custom domains. Zero Personal is free for personal use but allows only 1 cluster, 10 routes and 5 policies. Zero splits the work: you run the Pomerium Core cluster in your environment, so application traffic stays there, while Pomerium hosts the control plane and management console. Before you sign, confirm how your data residency rules treat control plane metadata, count your routes and policies against the limits, and confirm how the vendor counts users, including service accounts.
Pomerium's Enterprise pricing is custom, and the sources supplied do not give a figure. Enterprise is the tier that reserves directory sync, Rego policies, role-based access for administrators, session management and SSH session recording and playback. If you need any of those, ask for a written quote that names the features, the number of users and routes, the support terms and whether the control plane runs in your environment. Compare that quote with the cost of building the same controls yourself on Core, including the staff time to maintain them and the internal support you would carry without a vendor contract.
How to choose and pilot an identity-aware proxy
This sequence takes a team from an inventory of protected apps to a tested pilot, so the proxy decision rests on each app's protocols, session needs and access rules rather than on a feature list. The output is a documented choice that the security review can check.
Inventory the apps and their protocols
The application owner and the platform team list every internal app that needs SSO in front of it, noting the protocol each one speaks (plain HTTP or HTTPS, WebSockets, SSH, TCP, or non-web protocols), whether it has any login of its own, and how users reach it today. Apps with native OIDC support may not need a proxy at all, and non-web services fall outside what a web-focused proxy covers, so those are marked for separate review. The check is a signed-off table with one row per app and a protocol column that nobody has left blank.
Confirm the reverse proxy already in use
The infrastructure team records which reverse proxy or ingress controller fronts each app today, such as NGINX, Traefik, Caddy, HAProxy, Envoy or a Kubernetes ingress. Compatibility differs by product: Authelia lists its supported proxies on its own page, OAuth2 Proxy can run as a standalone proxy or as middleware beside an existing one, and Pomerium runs as its own proxy with a Kubernetes ingress controller. The output is a short mapping of app to proxy that shows whether each shortlisted option fits the current traffic path or would require changing it.
Decide where users authenticate and where MFA lives
The identity team decides which identity source holds the users (an existing OIDC provider such as Keycloak, Microsoft Entra ID or Okta, or a directory such as LDAP or Active Directory) and whether the proxy or the identity provider enforces second factors. Authelia can authenticate against LDAP or a YAML user file and offers one-time passwords, security keys, passkeys and Duo push as second factors, while Pomerium and OAuth2 Proxy generally delegate MFA to the upstream provider. Confirm each second-factor method in the vendor documentation before relying on it. The check is a written statement of the login flow, including where MFA is enforced for each app class.
Choose a session storage approach for your availability needs
The platform team selects how sessions are held and tests the choice against the outage model the business has agreed. OAuth2 Proxy keeps encrypted cookie sessions by default, which needs a cookie secret and holds no server state, but cannot lock sessions, so concurrent token refreshes can force a new login; its Redis option, including Sentinel or Cluster, moves session state into a shared store. Authelia keeps preferences, device registrations and logs in PostgreSQL, MySQL or SQLite, so the storage tier becomes a dependency. The output is a documented session store with its failure behavior and the team that operates it.
Check HTTPS requirements and certificate handling
The network and security team confirms that every protected host will be served over HTTPS before the pilot starts. Authelia states that it only works for websites served over HTTPS because its session cookies require it, and it declines to support plain HTTP, so any internal app still on HTTP needs a certificate or an upgrade first. The team also records how certificates are issued and renewed, which internal certificate authority is trusted, and how the identity provider's callback URLs are registered. The check is a list of hostnames with valid certificates and a note on any exceptions for the security review.
Pilot one non-critical app behind the shortlisted proxy
The platform team places one low-impact internal app behind the top candidate, using a test identity provider tenant or client registration where possible, and the app owner validates normal use. The pilot records the headers the app receives (user, groups and email, where the proxy forwards them) and confirms the app does not trust any header that a user could set directly. It is complete when the app works through the proxy, the headers match the documented names, and the team has a rollback path to the previous access method.
Test logout, token refresh and group-based access
The identity and security teams run scripted test cases covering sign-out from the app and from the proxy, expiry and refresh of sessions during a long working session, and access changes when a user is added to or removed from a group. They confirm whether a revoked user loses access at the proxy within the session lifetime the team has set, and they test a refresh that happens while several browser tabs are open. Pomerium's policies and OAuth2 Proxy's group headers must be checked against the identity provider's actual group claims. The output is a test log with pass or fail results and any known gaps.
Document the decision for the security review
The platform lead writes a decision record that names the chosen proxy and version, the rejected options and why, the identity source, the MFA method for each app class, the session store and its failure behavior, the HTTPS and certificate setup, and the pilot results. The record also notes licensing terms and any features that are available only in a paid edition, such as the paid tiers that Pomerium describes on its pricing page. It is done when the security reviewer can trace each control to a test result, and the record is kept with the change history of the deployment.
What do buyers ask before running this themselves?
Does Authelia work without HTTPS?
No. Authelia only works for websites served over HTTPS because its session cookies require it, and the project declines to support plain HTTP. Before you plan a pilot, confirm that every app behind the proxy has a valid certificate and that the internal hostnames you need can be served over TLS. If some internal services cannot take HTTPS, plan for that work or choose a proxy that handles those apps differently. Check the Authelia architecture documentation for the current cookie and domain requirements.
Can OAuth2 Proxy run without Redis?
Yes. By default OAuth2 Proxy stores sessions in encrypted client-side cookies, which requires a cookie secret, so no Redis server is needed. The trade-off is that cookie sessions cannot be locked, so concurrent token refreshes can conflict and force users to log in again. If that behavior affects your apps, Redis session storage, including Redis Sentinel or Redis Cluster, keeps only a ticket in the cookie. Your team will need to manage the cookie secret and, if you choose Redis, operate that service as well.
Do these proxies replace Keycloak?
No, not in most designs. Pomerium, Authelia and OAuth2 Proxy sit in front of applications and decide who may reach them, but they do not issue a full identity platform of their own. Keycloak, authentik or Zitadel typically remain the place where users, groups and login methods are managed, and the proxy trusts that provider over OIDC. Authelia can also check users against an LDAP directory or a YAML file, so a small estate may not need a separate identity server. Confirm which system is the source of truth for users before you choose.
What drives the cost and effort of a proxy rollout?
Most of the effort comes from four parts of the work, and the software license is usually the smallest:
- Proxy integration: mapping each application's routes, headers and hostnames to policies.
- Identity provider configuration: registering clients, groups and claims with your existing provider.
- Testing and documentation: verifying access rules, session behavior and failure paths, then writing runbooks.
- Any paid tier: Pomerium Zero and Enterprise are priced separately from Pomerium Core, so confirm which features your policies need.
Some costs are one-time, such as design and integration, while upgrades, certificate renewal and on-call support recur. Ask any provider for an itemized quote tied to a written scope.
How long does a pilot take?
No timeline can be stated here because duration depends on the number of applications, the proxy you choose, the identity provider and your change approval steps. A pilot covering one or two low-risk apps is usually scoped and approved differently from a production cutover across an estate. Confirm the timeline against your own change management process and any security review that must happen first. Ask the implementation partner to split the work into phases with written acceptance criteria so each stage has a clear end.
What does the work need from our own staff?
Your staff should provide the application owners, identity provider administrators and network or DNS contacts who can make changes and approve them. You will also need someone who can approve access policies and sign off on test results. On the technical side, expect to supply the hostnames, certificates and existing reverse proxy or ingress configuration. Ask whether your team will operate the proxy after handover, and confirm which runbooks, monitoring and upgrade tasks will sit with them.
Can DeployOpen run and test these proxies in our environment?
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the proxy and its identity integration would run in your environment. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Security testing of the applications and APIs behind the proxy can be scoped separately. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen scopes an identity-aware proxy project
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For identity-aware proxies, that means agreeing in writing which applications sit behind the proxy, which identity provider and policies apply, and how the result is tested and handed over.
How we scope
- Inventory the internal web applications and services that need an authentication layer in front of them.
- Confirm the identity provider, group claims and MFA requirements the proxy must honor for each application.
- Agree the written scope, deliverables and timeline before any work starts, since most engagements are fixed-scope.
How we build
- Deploy the chosen proxy, whether Pomerium, Authelia or OAuth2 Proxy, in your environment with your reverse proxy.
- Configure session storage, cookie or Redis, to match your availability and session handling requirements.
- Test access policies, header forwarding and failure paths against each protected application before sign-off.
How we hand over
- Document routing rules, policy definitions, secrets handling and the upgrade path for each component.
- Walk your operations and security staff through runbooks for adding applications and changing policies.
- Deliver the configuration and evidence your compliance assessors will need, while noting that auditors issue any opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Ask any quote to itemize one-time build work separately from recurring support and upgrade effort.
- Confirm with your team which vendor licenses and paid editions your chosen proxy requires before scoping.
