Authelia or OAuth2 Proxy: which fits your existing identity setup
If your internal web apps sit behind a reverse proxy and you must decide whether the gateway layer provides the login portal and second factors, the deciding question is whether you already run an identity provider. Authelia fits when no central identity provider exists yet and you want the gateway layer to authenticate users itself. It checks credentials against an LDAP directory such as FreeIPA or Active Directory, or against a YAML file of hashed passwords, and it adds one-time passwords, security keys, passkeys or Duo push as second factors. OAuth2 Proxy fits when an external OIDC provider already owns identity and the proxy only needs to enforce that login and pass user, group and email headers upstream. In that case, the second factors and login experience live in the provider, not in the proxy.
The choice also depends on the proxy you run. Authelia lists Traefik, Caddy, Envoy, NGINX, HAProxy and others among its supported proxies, with Apache and IIS listed separately, so confirm your exact proxy and version against that list before you commit. OAuth2 Proxy can run as the reverse proxy in front of an app or as middleware beside an existing proxy, and its set-xauthrequest option supports nginx auth_request mode. Session handling differs too: OAuth2 Proxy keeps sessions in encrypted cookies by default or in Redis, and cookie sessions cannot be locked, so concurrent token refreshes can force a new login. Authelia requires HTTPS for every protected site, so confirm that your certificate and DNS setup already supports it.
Which scenario points to which platform
This table maps common situations to the platform that usually fits better, with the condition that makes each choice hold. Read each row against your own identity sources and login requirements, since the right answer often depends on whether you already run an identity provider.
| Scenario | Better fit | Why |
|---|---|---|
| No existing identity provider | Authelia | Authelia authenticates users itself against a YAML file or LDAP and adds second factors, so it can front apps without a separate IdP, provided users and groups are small and managed by you. |
| Existing Entra ID, Google or OIDC provider | OAuth2 Proxy | OAuth2 Proxy defers login to Google, Microsoft Entra ID, GitHub or a generic OIDC provider, so you keep one source of truth for accounts and MFA policy. This holds when that provider already enforces the second factors you need. |
| Need TOTP, WebAuthn or Duo push at the gateway | Authelia | Authelia offers one-time passwords, security keys, passkeys and Duo mobile push as second factors at the proxy. OAuth2 Proxy relies on the upstream provider for MFA, so this only favors OAuth2 Proxy if that provider already enforces it. |
| LDAP or FreeIPA directory already in place | Authelia | Authelia can authenticate directly against LDAP directories such as OpenLDAP, FreeIPA or Active Directory, so existing accounts work without a new IdP. Confirm group mapping and access rules in your environment before relying on it. |
| SAML-only applications | Neither on its own | Authelia's support chart lists no SAML support, and OAuth2 Proxy's documented protocols are OAuth2 and OIDC. Plan a full identity provider that speaks SAML, such as Keycloak, for these applications. |
| Multi-tenant B2B customers managing their own users | A full identity platform | Per-customer user management and organization-level administration point toward an identity platform such as Zitadel, not a gateway. Neither Authelia nor OAuth2 Proxy is designed to manage tenants for external customers. |
| Small homelab-scale proxy setup | Authelia | Authelia runs alongside common proxies such as Traefik, Caddy and NGINX and stores data in SQLite, which keeps the footprint small. This holds for a few users and apps served over HTTPS; confirm your proxy is on its supported list. |
How each one sits in front of your apps
Both products sit between users and the applications behind a reverse proxy, but they split the work differently. Authelia answers the proxy's allow or deny question and handles login, factors and sessions itself, while OAuth2 Proxy hands login to an external OIDC provider and passes identity onward. The cards below cover the parts you need to map before you choose.
The proxy decision flow
With Authelia, the reverse proxy asks Authelia whether each request may pass. Unauthenticated users are redirected to Authelia's login portal, and the proxy enforces the answer. Map every application route through this flow, because a route the proxy does not check is a route Authelia does not protect. Confirm that your proxy is on Authelia's supported list before you design around it, and test the redirect path for each subdomain you publish.
The user backend
Authelia checks first-factor passwords against an LDAP directory such as OpenLDAP, OpenDJ, FreeIPA or Microsoft Active Directory, or against a YAML file of users with hashed passwords. The file option suits a small, fixed user set managed by hand. A directory suits shared accounts and group membership that already live in a corporate system. Confirm who owns password changes and account disablement, because Authelia's answer depends on that backend.
Storage for preferences, factors and logs
Authelia keeps user preferences, second factor device registrations and authentication logs in PostgreSQL, MySQL or local SQLite. SQLite fits a single-node test or small deployment, while the networked databases fit high availability requirements. Plan backups for the registration data, since losing a second factor enrollment forces users through re-registration. Ask your team which database your standard backup tooling already covers.
OAuth2 Proxy as proxy or middleware
OAuth2 Proxy can run as the reverse proxy in front of an app, or as middleware beside an existing proxy. In nginx auth_request mode, its set-xauthrequest option returns X-Auth-Request user, groups and email headers. This suits teams that already run nginx and want to keep their current routing. Check that your proxy can pass the auth subrequest and headers exactly as configured before you commit to this pattern.
Identity header forwarding
OAuth2 Proxy forwards identity to upstream apps in headers such as X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email, and can pass the access token or ID token. Your applications must trust these headers only when they arrive from the proxy, or a client could spoof them. Authelia also passes identity to applications, so compare the header names and claims each app expects before you migrate any route.
The HTTPS requirement
Authelia's session cookies require HTTPS, and the project declines to support plain HTTP. Every protected site therefore needs valid TLS in front of it, including internal test hosts. Plan certificate issuance and renewal before rollout, and confirm that your proxy terminates TLS for each protected name. OAuth2 Proxy has its own session and cookie settings, so verify the transport requirements for both products in your own environment.
Capabilities compared: MFA, sessions, protocols and proxies
This table sets Authelia against OAuth2 Proxy row by row, so you can see which platform authenticates users itself and which one hands login to an external provider. Read each row as a question about your own setup: where users live, which second factors you must enforce, and whether an identity provider already exists. The main takeaway is that Authelia is a login and second-factor layer for reverse proxies, while OAuth2 Proxy is a proxy-side client of an identity provider you run elsewhere.
| Capability | Authelia | OAuth2 Proxy |
|---|---|---|
| License | Apache-2.0 | MIT |
| Current release | v4.39.28, released September 17, 2026 | v7.15.5, published October 1, 2026 |
| OIDC and SAML support | OpenID Certified for Basic, Implicit, Hybrid, Form Post and Config OP profiles; no SAML support listed | Consumes generic OIDC and OAuth2 providers; confirm SAML support with the project before relying on it |
| User source | LDAP directories (OpenLDAP, OpenDJ, FreeIPA, Active Directory) or a YAML file of hashed passwords | External identity provider such as Google, Microsoft Entra ID, GitHub, login.gov or a generic OIDC provider |
| Second factors | One-time passwords, security keys, passkeys and Duo mobile push | No MFA feature stated in supplied facts; confirm with the project and with your identity provider |
| Self-service password reset | Supported | Not a proxy feature; depends on the external identity provider |
| Proxy support | 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, including nginx auth_request mode |
| Session storage | PostgreSQL, MySQL or local SQLite for preferences, device registrations and logs; confirm session backend details in the documentation | Encrypted client-side cookies (requires a cookie secret) or Redis, including Sentinel and Cluster |
| Identity headers | Confirm header names and values in your proxy configuration | X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email; can pass access or ID token |
| Needs an external identity provider | No, when you use LDAP or the file backend; yes if you want OIDC login for upstream apps from a provider you already run | Yes, every login is delegated to an OIDC or OAuth2 provider |
Licensing and paid options for each platform
Authelia is licensed under Apache-2.0, according to its GitHub repository, so you can run and modify it inside your own infrastructure without a license fee attached to the code. The current release is v4.39.28, released on September 17, 2026. The supplied facts do not name a paid edition, so do not assume one exists or that one is absent. Ask the project directly what commercial support options it offers.
- License: Apache-2.0 applies to the project repository, so confirm the license file that ships with the exact version you deploy.
- Release line: v4.39.28 is the current release. Pin the version in your change control and track its release notes before each upgrade.
- Paid options: No paid edition is named in the supplied facts. Ask whether commercial support, training or priority fixes exist, and on what written terms.
- Integrator work: Any help you buy to design, integrate or operate Authelia is a separate written scope with its own deliverables and fees.
Before you rely on this tab, confirm in writing with the project which support terms, if any, apply to the version you intend to run.
OAuth2 Proxy is distributed under the MIT License, one of the most permissive open-source licenses in common use. It is a Cloud Native Computing Foundation Sandbox project and is community-driven. The latest release in the supplied facts is v7.15.5, published on October 1, 2026, after v7.15.4 in August and v7.15.3 in June. Its governance and release process are therefore public, and your team will track them.
- License: MIT License terms are short, so license review usually takes less effort than with copyleft or source-available licenses.
- Foundation status: Cloud Native Computing Foundation Sandbox is the project's stated status. Confirm what that status means for your own vendor and supply-chain review.
- Governance: The project is community-driven. Plan to follow its public issues and releases yourself, because no vendor is named in the supplied facts as the party that ships fixes on your behalf.
- Current release: v7.15.5 is the latest release in the supplied facts. Check the release history for the version you intend to run, and confirm how security advisories will reach your team.
Before you commit, confirm which release your deployment will pin and who receives notice of security fixes between releases.
Both products carry no license fee in the supplied facts that would decide the choice, so the budget difference comes from the work around them. Costs fall into one-time work, such as designing the login path, integrating proxies, enrolling second factors and writing runbooks, and recurring work, such as upgrades, patch tracking, backups and monitoring. The larger driver is the identity provider you already run. Authelia can read an LDAP directory or a YAML file of users, while OAuth2 Proxy depends on an external OIDC or OAuth2 provider whose own license or subscription becomes part of the bill.
- One-time work: Design, proxy integration, MFA enrollment, testing and documentation for each application group.
- Recurring work: Upgrades, vulnerability tracking, backup checks and monitoring of the session store and user backend.
- Identity provider: Authelia's first factor can use existing LDAP or file users, while OAuth2 Proxy needs a provider that you may need to license or subscribe to.
- Session infrastructure: OAuth2 Proxy uses encrypted cookies that need a cookie secret, or Redis, which is one more service to run. Authelia stores its data in PostgreSQL, MySQL or SQLite.
- Quote inputs: Ask for the application count, proxies in use, user sources, MFA methods, environments, and who operates the platform after go-live.
When you request a quote, DeployOpen works from a written scope and does not publish a price list, so confirm which components, exclusions and support hours that scope covers.
How sessions and second factors behave under load and failure
OAuth2 Proxy and Authelia hold session state in different places, and that difference decides what you must operate. OAuth2 Proxy stores sessions in encrypted client-side cookies by default, which means you must set a cookie secret and keep it consistent across replicas. Its alternative is Redis, including Redis Sentinel or Redis Cluster, with only a ticket kept in the cookie. The documentation is direct about a limitation of cookie sessions: they cannot be locked, so concurrent token refreshes from parallel requests can conflict and force a user to log in again. If your applications fire many parallel requests, plan to test that behavior or move to Redis-backed sessions, and confirm the refresh and session settings for your chosen version in the OAuth2 Proxy session storage documentation.
Authelia keeps user preferences, second factor device registrations and authentication logs in PostgreSQL, MySQL or local SQLite. For a single-node lab, SQLite is simple to run. For multiple Authelia instances, or any setup where a restart or node loss must not disrupt users, the database becomes a shared dependency, so you need a backup, restore and failover plan for it. Ask your team to confirm how session data is held in the Authelia configuration you intend to run, whether sessions survive an Authelia restart, and what a user sees during a database outage. Those answers are configuration-specific and should be tested in your environment rather than assumed from the storage documentation.
Where MFA is enforced changes the audit trail. With Authelia, the second factor is checked by the gateway companion itself, using one-time passwords, security keys, passkeys or Duo mobile push, so the authentication event, factor type and access decision are recorded by the same system that authorizes requests. With OAuth2 Proxy, MFA is usually enforced by the external OIDC provider, so the proxy sees the result of that login, not the factor used. In that model, your evidence for MFA lives in the identity provider's logs, and you must confirm that those logs reach your SIEM and cover every application route. Map this to your own access control evidence before you choose.
Moving from OAuth2 Proxy to Authelia, or back, in order
This sequence gives a team a safe order for moving protected routes between the two gateways, so user identities and application settings carry over while proxy policies, second factors and sessions are rebuilt on the target side. Each step closes with a check that tells you whether the move can continue.
Inventory protected apps and their header dependencies
List every upstream application behind the proxy, the hostname and path it is served on, and the identity headers it reads. OAuth2 Proxy commonly passes X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email, and may forward the access token or ID token, so note any app that relies on one of these values or on an Authorization header. The application owner should confirm each dependency. Done means you have a table of routes, headers consumed and the owner who signed off on it.
Decide the user source for the target gateway
Choose where Authelia will read users, either an LDAP directory such as OpenLDAP, FreeIPA or Active Directory, or a YAML file of users with hashed passwords. If you are keeping an external OIDC provider, confirm whether Authelia will still rely on it, because Authelia's own login portal and OIDC provider role differ from OAuth2 Proxy's delegated login. Ask your identity team to confirm which directory holds the accounts you need. Done means the user source is written down with its owner and the accounts you plan to migrate are confirmed to exist there.
Map group claims to the target access model
Translate each group that an app depends on into the form the target gateway uses. In Authelia that means access rules keyed on group membership in the user source. In OAuth2 Proxy it means the group values forwarded in the group header, which the app must still parse. Note any app that checks group names exactly, since a renamed or nested group can change what it sees. Done means every route has a written rule and a test user per group, and the application team has agreed that the header or rule produces the same access as before.
Stage a parallel route and test under HTTPS
Bring up the target proxy on a staging hostname with a valid certificate, because Authelia only serves websites over HTTPS and its session cookies depend on it. Confirm that the reverse proxy you use is on Authelia's supported proxies list, or that your OAuth2 Proxy setup matches the mode you run. Test each route with each test group, including a logout and a session expiry. Done means each route passes with the expected identity headers and access decision, recorded in a test log.
Rebuild second factor enrollment on the target
Plan for users to register their second factors again on the new gateway, because Authelia stores device registrations in its own database and those records do not come from OAuth2 Proxy or the directory. Authelia supports one-time passwords, security keys and passkeys, and Duo mobile push, so confirm which of these your users need and that your Duo or other integration is ready. Give users a registration window and a fallback path for those who lose a device. Done means each user with a required factor has enrolled on the target, and the enrollment list is reviewed.
Plan session cutover so users are not stranded
Decide how existing sessions end. OAuth2 Proxy sessions are either encrypted cookies or Redis entries, and Authelia keeps its own session state, so a user on the old gateway will not carry a valid session to the new one. Announce the change, pick a cutover point for each route, and keep the old route available until the new one is confirmed. Done means the cutover order, the rollback path and the user notice are approved, and a pilot group has signed in through the new route without losing access to the app.
Retire the old route and confirm the record
Once the pilot and the broader cutover are stable, remove the old proxy routes and any cookie secret or Redis session store that no longer serves a protected app. Keep a copy of the route inventory, group mapping and test log with the change record, since auditors and the next migration will ask for them. Ask your team to confirm that no service still points at the old hostname. Done means the old configuration is archived, no traffic reaches it, and the change record lists what transferred and what was rebuilt.
What drives the running cost of each option
Running cost for Authelia and OAuth2 Proxy is spread across infrastructure, people, second factors, patching and support, and the two tools shift that spread in different places. OAuth2 Proxy often sits in front of an identity provider you already pay for, while Authelia brings its own login, storage and second factor handling. No price figures are supplied for either option, so use the cards to build the questions for a written quote.
Infrastructure and session storage
Authelia keeps user preferences, second factor registrations and authentication logs in PostgreSQL, MySQL or local SQLite, and reads users from LDAP or a YAML file. OAuth2 Proxy holds sessions in encrypted cookies by default, or in Redis if you configure it. Check whether you must run and back up a database, a Redis deployment, or both, and whether the external identity provider is hosted in your own infrastructure or by a third party.
Upstream identity provider licensing
OAuth2 Proxy does not authenticate users itself, so its running cost includes the OpenID Connect provider it depends on. If you already license an identity provider for other applications, the marginal cost may be small. If you do not, that provider becomes a separate platform to host, patch and support. Ask whether your provider's license covers the number of OIDC clients and users you plan to protect.
Skills to configure and operate
Authelia requires you to configure a reverse proxy integration, an LDAP or file backend and access rules, and for OIDC use, client registrations. OAuth2 Proxy requires proxy configuration, provider client setup and the header contract your upstream apps trust. Staff who already know your proxy and identity stack will cost less to keep current. Estimate the training time for each role in your own environment rather than relying on a generic figure.
Second factor and recovery support
Authelia provides one-time passwords, security keys, passkeys, Duo mobile push, self-service password reset and account banning after failed attempts, so the help desk load for lost devices sits with your team. With OAuth2 Proxy, second factors and recovery are handled by the identity provider, which may or may not match your policy. Confirm which factors your users need, who resets devices, and whether that work is covered by your support contract.
Patching each release line
Authelia is a single project whose current release is v4.39.28, released on September 17, 2026, and you must track its releases alongside your proxy. OAuth2 Proxy's current release is v7.15.5, published on October 1, 2026. Each component you run adds its own upgrade cycle, so a stack with Authelia, Redis and an identity provider needs more patch tracking than a single-service setup. Ask who tests upgrades and how long a patch window takes in your environment.
Community and commercial support
Both projects are open source under permissive licenses, and neither source set in this comparison lists a commercial support tier for either project, so confirm support options directly with each vendor. OAuth2 Proxy is a community-driven project in the Cloud Native Computing Foundation Sandbox. Your support cost depends on whether you rely on community channels, a paid vendor agreement, or an implementation partner for incident response. Ask for response times in writing before you compare quotes.
What implementing each involves and where projects run long
Authelia is the heavier setup on the identity side and the lighter one on the application side. You need an HTTPS-only deployment, because Authelia's session cookies require it and the project does not support plain HTTP. You also need a configured first-factor backend, either an LDAP directory such as FreeIPA or Active Directory or a YAML file of hashed passwords, plus a storage backend (PostgreSQL, MySQL or SQLite) for user preferences, second factor device registrations and authentication logs. Each protected app then needs its route defined in the proxy you already run, such as Traefik, Caddy, NGINX or HAProxy, and the proxy must ask Authelia for a decision on every request. Confirm your chosen proxy against the Authelia supported proxies page before you commit to the design.
OAuth2 Proxy shifts the work to the identity provider and to the headers. You register an OIDC client with the provider you have chosen, configure the cookie secret for session storage or provision Redis (including Sentinel or Cluster topologies), and decide whether the proxy runs in front of each app or as middleware alongside an existing proxy. The larger effort sits inside each upstream app, which must read identity from headers such as X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email, or from the set-xauthrequest headers when nginx auth_request is in use. Where an app expects a different header name or group format, you need a mapping layer or an app-side change, and that work is repeated per app.
Projects usually run long in the same places for both designs. Directory cleanup before LDAP integration is the first, since duplicate accounts, stale groups and inconsistent naming surface as login failures. Group mapping across many apps is the second, because each app's authorization model has to be agreed with its owners. Second factor rollout to users takes time for enrolment and support, and it is best staged by group. Reconciling identity headers with apps that expect different names is the third. The last is testing session behavior across proxies, including expiry, logout, token refresh and what happens when users hold several sessions. Under a written, fixed scope, DeployOpen plans, implements, integrates, hardens and documents these pieces inside your own infrastructure, and the scope should name each app, each directory source and each test case before work starts.
Questions buyers ask before choosing Authelia or OAuth2 Proxy
Can Authelia replace our existing OIDC provider?
Authelia can act as an OpenID Connect provider for applications that support OIDC, and it is OpenID Certified for the Basic, Implicit, Hybrid, Form Post and Config OP profiles. Confirm that your applications need only those profiles before you plan a replacement. Authelia does not support SAML, so any SAML service provider in your estate needs a full identity provider such as Keycloak or another product that speaks SAML 2.0. Move one application at a time, test the token and claim behavior of each client against your own configuration, and keep the existing provider running until every client is verified.
Does OAuth2 Proxy add MFA on top of our identity provider?
OAuth2 Proxy does not add its own second factor. It delegates login to an external OIDC or OAuth2 provider, so MFA is whatever that provider enforces. Confirm with your chosen provider that MFA policies apply to the client OAuth2 Proxy uses, and that step-up rules cover the applications you protect. If you need a second factor that the gateway itself enforces, Authelia offers one-time passwords, security keys, passkeys and Duo mobile push as second factors, and that is a different design with a different login flow.
Do we need SAML support, and which product covers it?
You need SAML only if an application or partner requires SAML 2.0 assertions. Authelia's support chart lists no SAML support, and OAuth2 Proxy is an OAuth2 and OIDC gateway, so neither covers SAML service providers. In that case, pair the gateway with a full identity provider. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, can broker logins to external OIDC or SAML providers, and can federate users from LDAP or Active Directory. Check every SAML integration in your inventory before you choose the gateway, because the answer can change the architecture.
How long does a migration to Authelia or OAuth2 Proxy take?
The duration depends on the number of applications, how each one handles headers or tokens, and the state of your directory. No timeline figures are published here, so ask for one only after the scope is written. The main drivers are: how many applications sit behind the proxy, whether each app trusts identity headers such as X-Forwarded-User or relies on a token, the cleanliness of LDAP or Active Directory group data, and how many session and cookie behaviors need testing. A pilot with two or three representative applications is the usual way to measure this before committing to a full plan.
What skills does the team need to run either option?
Plan for three skill areas: reverse proxy configuration, directory administration, and OpenID Connect concepts. Authelia works with proxies such as Traefik, Caddy, Envoy, NGINX and HAProxy, and it requires HTTPS because its session cookies depend on it. It reads users from LDAP or a YAML file and stores preferences and second factor registrations in PostgreSQL, MySQL or SQLite. OAuth2 Proxy needs an OIDC client registration, a cookie secret or Redis for sessions, and header handling in each upstream app. Staff who already run NGINX or Traefik and an LDAP directory will find the work familiar.
Can our own team deploy this without outside help?
A small setup with a few applications, one proxy and one user source is within reach of a team that follows the official documentation, and the Authelia and OAuth2 Proxy projects both publish configuration guides. The harder parts are testing session behavior, validating headers and tokens in each app, and designing MFA policy for production. If your environment includes regulated data, many applications, or several proxies, a written scope with an external implementation partner can reduce the risk of gaps. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure.
What does a fixed-scope engagement cover for this kind of setup?
A fixed-scope engagement covers the agreed scope, deliverables and timeline, which are confirmed in writing before work begins. For a gateway decision, that typically means: reviewing the applications and protocols in use, selecting the proxy and user backend, deploying in your own cloud, data center or air-gapped network, configuring MFA and sessions, integrating with your directory or identity provider, testing, documenting, and preparing evidence for compliance assessments. DeployOpen does not issue audit reports or certifications. Ongoing support, upgrades and continuous testing are available as retainers, and quotes follow from the written scope.
How DeployOpen helps you choose and implement either option
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. We help teams decide whether Authelia's built-in login and second factors or OAuth2 Proxy's delegated OIDC login fits their applications, then implement the option they choose.
How we scope
- Map which applications sit behind a proxy and which proxy each one uses, such as Traefik, NGINX or Caddy.
- Record where users come from, whether a file, LDAP directory or external OIDC provider, and which second factors apply.
- Agree scope, deliverables and timelines in writing before any work starts, since most engagements are fixed-scope.
How we build
- Configure the chosen gateway, its session storage and HTTPS termination within your own cloud accounts or data centers.
- Test access rules, group-based headers and second factor enrollment against each protected application before go-live.
- Confirm session behavior under token refresh and logout, including whether Redis or encrypted cookies fit your load pattern.
How we hand over
- Document the configuration, access policies, backup steps and the upgrade path for each component in your environment.
- Provide evidence of configured controls that your internal reviewers or external auditors can assess, without issuing any attestation ourselves.
- Walk your operations and security staff through runbooks for adding applications, rotating secrets and recovering users.
How we support
- Run upgrades and patching for the gateway and its dependencies on a schedule agreed in writing.
- Add new applications and proxy changes through ongoing support available as a retainer.
- Pair retainer support with continuous security testing when you want regular checks on login flows and access rules.
