Keycloak vs Authelia: when to choose each
Choose Keycloak when applications need SAML, when logins must be brokered to an external OpenID Connect or SAML provider, when users live in LDAP or Active Directory and must be federated, or when administrators want a full admin console. Choose Authelia when a reverse proxy already fronts your web applications, when OpenID Connect is the protocol you need, when users come from a YAML file or an LDAP directory, and when no SAML-only SaaS or legacy app is on the list. The decision starts with protocols and user sources, then moves to how much administration your team wants done in a UI and how much platform work it can carry. Start by listing every application and its protocol. Authelia's OpenID Connect documentation lists OpenID Certified support for the Basic, Implicit, Hybrid, Form Post and Config OP profiles, and its support chart lists no SAML. If a SaaS vendor or an older internal app accepts only SAML, Authelia cannot cover it, and Keycloak becomes the practical choice. Next, check where users live. Authelia authenticates against LDAP servers such as OpenLDAP, FreeIPA or Microsoft Active Directory, or against a YAML file of users with hashed passwords, and it does not broker logins to an external identity provider in the way Keycloak does. Confirm with your identity team whether that gap matters for partner or customer logins. Operating skills and session design also differ. Authelia sits beside a proxy such as Traefik, Caddy, NGINX or Envoy, stores preferences, second factor registrations and logs in PostgreSQL, MySQL or SQLite, and only works for sites served over HTTPS. Keycloak needs a relational database in production and a supported deployment method, with the Keycloak Operator on Kubernetes or the server distribution on virtual machines. Ask your team which platform skills it has today, and whether a retainer for upgrades and hardening fits the plan. Cost is driven mainly by the staff time to build and run each platform, so request quotes that separate design, integration and ongoing support.
Keycloak vs Authelia by scenario
This table maps common situations to the platform that usually fits better and the condition behind that answer. Read each row against your own protocol needs, user source and team size, and confirm the flagged capabilities in your environment before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| Enterprise SSO to SAML and OIDC applications | Keycloak | Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 as a full identity provider. Authelia's support chart lists no SAML, so any SAML-only application points to Keycloak. |
| Protecting internal web apps behind NGINX or Traefik | Authelia | Authelia works as a companion to a reverse proxy that asks it whether to allow each request. If every app is an HTTPS website behind a supported proxy, its footprint is smaller, though you should confirm your proxy is on the supported list. |
| Brokering logins to an external corporate IdP | Keycloak | Keycloak can broker logins to an external OpenID Connect or SAML identity provider and keep its own sessions and client configuration. Confirm that Authelia's OIDC relying-party setup covers your IdP's claims and MFA expectations before choosing it for this role. |
| Active Directory or FreeIPA user federation | Keycloak | Keycloak federates users from LDAP or Active Directory and lets you manage the federation settings in its admin console. Authelia can authenticate against LDAP directories including FreeIPA and Active Directory, so confirm group mapping and authorization rules in your environment if you only need password checks. |
| Small team with a file-based user list | Authelia | Authelia can read users from a YAML file with hashed passwords and needs only a small storage backend for preferences, second factors and logs. This suits a small group with few users, but confirm that a file-based list meets your audit and offboarding requirements. |
| SaaS vendor needing customer-facing login | Depends on requirements | Keycloak offers realms, identity brokering and a full admin console for multi-customer setups. Authelia is aimed at protecting internal sites behind a proxy rather than hosting customer sign-up and self-service, so confirm the tenant and user lifecycle features you need before deciding. |
| Operating effort for a platform team | Authelia | Authelia runs as a lightweight companion with a small set of components. Keycloak needs a supported relational database in production and a deliberate high availability design, so budget more operating effort for it. Confirm the effort against your own infrastructure. |
How each is built and what that means for operations
Keycloak and Authelia solve adjacent problems with very different moving parts. The cards below cover what each component depends on, where it can fail and what your team must maintain after go-live.
Keycloak as a standalone server
Keycloak runs as its own identity server and needs a relational database in production. Its supported production databases include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL. The default dev-file database is for development only, so a production build must be pointed at one of these engines before go-live. Confirm which database your DBA team will back up and patch, because Keycloak stores realms, users and client configuration there.
Keycloak high availability requirements
Keycloak documents three high availability architectures: a single cluster optionally spread across availability zones, multi-cluster v2 without an external Infinispan cluster, and the deprecated multi-cluster v1. Both supported designs require a synchronously replicated database, so the database tier often sets the availability ceiling. Ask your platform team whether the database replication you already run meets that requirement before you size the Keycloak nodes.
Authelia as a reverse proxy companion
Authelia does not sit in front of applications as an identity store. The reverse proxy asks Authelia whether to allow each request, and unauthenticated users are redirected to Authelia's login portal. Supported proxies include Traefik, Caddy, Envoy, NGINX, NGINX Proxy Manager, SWAG, HAProxy and Skipper, with Apache and IIS listed separately. Your team owns the proxy rules for every protected route, so each new application adds a proxy configuration change that must be tested and reviewed.
Authelia HTTPS and session cookies
Authelia only works for websites served over HTTPS because its session cookies require it, and the project declines to support plain HTTP. Any internal application you plan to protect needs a valid TLS certificate and a consistent domain layout before Authelia can work. Confirm certificate issuance and renewal for every protected hostname, since an expired certificate blocks sign-in for all routes behind that proxy.
Authelia storage and database upkeep
Authelia stores user preferences, second factor device registrations and authentication logs in PostgreSQL, MySQL or local SQLite. SQLite keeps the footprint small but ties state to one host, which limits replication options. PostgreSQL or MySQL moves that upkeep to a database your team already backs up. Decide early which store holds second factor registrations, because losing them forces users to re-enroll their devices.
Upgrade cadence and change control
Keycloak plans four minor releases a year and says breaking changes in a minor release will be opt-in, while its Operator documentation strongly recommends manual approval for updates. Keycloak also migrates its database schema automatically at startup by default. Authelia's current line is v4.39.28, and its proxy, storage and first factor settings must be re-checked after each upgrade. Plan a test environment for both platforms and assign an owner for release tracking.
Keycloak vs Authelia side by side
This table sets Keycloak's full identity provider features beside Authelia's role as a reverse-proxy companion across nine capabilities. Where a cell asks you to confirm a point, check it in the named documentation before you shortlist either platform. The main takeaway: both are Apache-2.0, but SAML, brokering, the admin console and the directory model decide which one fits.
| Capability | Keycloak | Authelia |
|---|---|---|
| License | Apache-2.0 | Apache-2.0 |
| Current release | 26.8.1, released October 13, 2026 | v4.39.28, released September 17, 2026 |
| Protocols | OpenID Connect, OAuth 2.0 and SAML 2.0 | OpenID Connect and OAuth 2.0; its support chart lists no SAML |
| OpenID Certified profiles | Confirm current certification and profiles in the OpenID Foundation certification listing | Basic, Implicit, Hybrid, Form Post and Config OP profiles |
| Identity brokering and user federation | Brokers logins to external OIDC or SAML providers; federates users from LDAP or Active Directory | Users from LDAP (OpenLDAP, OpenDJ, FreeIPA, Active Directory) or a YAML file with hashed passwords; confirm brokering in its documentation |
| Second factors | Confirm supported OTP, WebAuthn and passkey options in the Keycloak server administration guide | One-time passwords, security keys, passkeys and Duo mobile push |
| Admin console | Web admin console for realms, clients, users and authorization | Confirm in the Authelia documentation whether any administrative interface exists beyond its login portal |
| Storage and production database | Relational database required in production: PostgreSQL 14 to 18, MariaDB, MySQL, SQL Server, Oracle, Aurora PostgreSQL | PostgreSQL, MySQL or local SQLite for preferences, second factor registrations and authentication logs |
| Deployment model and Kubernetes operator | Standalone server with clustering; Keycloak Operator installed via OLM or kubectl, plus an experimental Helm chart | Companion to HTTPS reverse proxies such as Traefik, Caddy, NGINX and Envoy; confirm Kubernetes operator availability |
Licensing and editions for each platform
Keycloak is licensed under Apache-2.0, and its LICENSE file governs the upstream server you download from the project repository. The current release is 26.8.1, published October 13, 2026. Upstream Keycloak is community-supported, so any formal support commitment has to come from a separate arrangement that you confirm in writing.
- Apache-2.0 terms: This is a permissive license. Have counsel confirm the notice and attribution duties that apply when you redistribute a modified build or embed the server in a product.
- Current release line: Since Keycloak 26.0, the project plans four minor releases a year, and breaking changes in a minor release are opt-in. Plan upgrades against the line you run, not only the latest tag.
- Red Hat build of Keycloak: This is Red Hat's supported distribution based on the open source project and replaces Red Hat Single Sign-On. Red Hat's product page showed version 26.6 as its latest, so confirm the current version there before you quote it.
- Who is paid for what: A Red Hat subscription pays for vendor support on the supported build. Running upstream Keycloak means your team, or a services partner, carries patching, upgrades and incident response.
- Choosing between them: Upstream suits teams that can operate the server and its upgrades. The supported build suits organizations whose procurement or assessment work needs a named vendor support path.
Confirm which Keycloak line your subscription covers and which version your deployment runs before you start the procurement process.
Authelia is licensed under Apache-2.0, as shown in its GitHub repository. The current release is v4.39.28, released September 17, 2026. The supplied facts do not establish any paid edition, so treat any feature you assume is paid as unconfirmed until the vendor answers in writing.
- Apache-2.0 terms: The license is the same permissive family as Keycloak's, so the redistribution and notice duties are comparable. Confirm them with counsel for the exact build you run.
- Current release: v4.39.28 is dated September 17, 2026. Check the releases page for patch releases after that date before you set an upgrade window.
- Paid editions: No paid edition is established here. Ask the vendor directly whether a commercial tier, feature set or license exists for the components you plan to use.
- Commercial support: Ask whether commercial support, response commitments or a subscription exist, and which versions and patches it covers.
- Scope of the license: Apache-2.0 governs the code. It does not decide whether a support contract exists for your deployment, so the two questions need separate answers.
Get any commercial option confirmed in writing and check the license text for the exact version you intend to deploy.
A paid subscription generally buys the right to vendor-provided support and maintenance for a named product and version range. It does not replace the work of running the platform. Payments usually split into a recurring fee to the vendor, one-time implementation work by an implementer, and ongoing internal or contracted effort for upgrades, testing and incident handling.
- Recurring vendor fee: Paid to the software vendor for support, patches or access to a supported build. It recurs for as long as the subscription runs.
- Support terms: Response expectations, supported versions and hours of coverage are set in the contract. Ask for them in writing rather than relying on marketing descriptions.
- One-time implementation: Planning, configuration, integration and hardening are usually a separate one-time effort. DeployOpen agrees this work in a fixed written scope before it starts.
- Recurring operating effort: Upgrades, backups, testing and evidence collection recur whether or not you hold a subscription. Ask who performs each task and who is paid for it.
- What to ask for in a quote: Request the named product and version coverage, the support window, the inclusions and exclusions, and any separate charges for upgrades or testing.
Compare subscription terms for both platforms against the same list before you decide which cost model fits your team.
How Keycloak and Authelia connect to existing identities
The first decision is where the user's password and group membership live, because that determines which platform can enforce MFA and which one hands tokens to applications. Keycloak can act as a full identity provider in three ways: it federates users from LDAP or Active Directory and reads them from that directory, it brokers logins to an external OpenID Connect or SAML identity provider, and it issues OpenID Connect and SAML tokens directly to each application. Authelia takes a narrower path. It authenticates users against an LDAP directory such as OpenLDAP, OpenDJ, FreeIPA or Microsoft Active Directory, or against a YAML file of users with hashed passwords, and then answers the reverse proxy's question of whether a request may pass. Applications behind the proxy receive identity information from the proxy rather than tokens issued by Authelia.
That difference shifts MFA placement and password ownership. With Keycloak, MFA and password policy are enforced by Keycloak for every application that uses its tokens, while federated passwords stay in the directory and brokered passwords stay at the external provider. With Authelia, the second factor is checked at the proxy login portal, and each protected site depends on the proxy sending each request through Authelia. Authelia supports one-time passwords, security keys, passkeys and Duo push as second factors, and it stores second factor device registrations in its own database, so the reader must decide whether those registrations belong to Authelia or to the directory. Confirm which platform will hold the password reset flow, and whether your help desk expects to reset passwords in Active Directory, FreeIPA or the Keycloak console.
Provisioning and attribute handling differ most in practice. Keycloak user federation can import and sync accounts from a directory, and brokering creates local accounts on first login, so you must define how groups and attributes map into realms and client roles. Authelia reads users and group membership from the LDAP filter or the YAML file, and the groups it sees decide which access rules apply at the proxy. Before committing, run a test with a representative set of nested groups and one user from each source. Confirm how each platform maps directory groups to roles, which attributes are released to each application, and whether a removed directory account stops working immediately or after a session expires. The Authelia first factor documentation is the place to check the LDAP settings your directory layout requires.
What drives the running cost of each
Running Keycloak and Authelia costs different things, and the largest items are not the license fees, which are zero for both in the community editions. The cards below cover the components you operate, the skills your team needs, how often you will upgrade, and the support you can buy. Use them to shape the scope you send to any implementation partner.
Database and high availability
Keycloak needs a relational database in production, and its high availability designs require a synchronously replicated database in both supported architectures. That database, its backups and its failover testing are usually the biggest recurring infrastructure line. Authelia runs next to your existing reverse proxy and keeps preferences, second factor registrations and authentication logs in PostgreSQL, MySQL or SQLite, so its footprint is smaller. Ask for the database engine, replication design and failover targets in the quote.
Kubernetes and Operator skills
Keycloak runs well from the server distribution on virtual machines, or through the Keycloak Operator on Kubernetes or OpenShift. The Operator route assumes your team can manage custom resources, cluster upgrades and the external database, which is work that stays with you after delivery. Authelia's skill load sits in the proxy: Traefik, Caddy, NGINX and similar tools each need their own forward auth configuration and HTTPS certificates. Confirm which of these skills already exist in-house before comparing effort.
Upgrade cadence and change control
Keycloak plans four minor releases a year, and the project says breaking changes in a minor release will be opt-in. For operator-managed clusters, the Keycloak documentation strongly recommends manual approval mode so upgrades do not happen unintentionally. Authelia is a smaller codebase with its own release line, and the current release is v4.39.28. Ask how many upgrade cycles per year your change process can absorb, and who tests each one against your applications.
Vendor support options
Both projects are open source, so support is a purchase decision rather than a license purchase. Red Hat build of Keycloak is one supported route for Keycloak, and Authelia's support options should be confirmed directly with its maintainers before you assume any. DeployOpen can plan, implement, harden and document either platform and offer retainers for ongoing support, upgrades and testing, under a written scope. Confirm with each vendor what support terms and response commitments they offer for your version.
Editions and licensing
Keycloak and Authelia are both Apache-2.0, so there is no paid feature gate to model in the license itself. Cost depends on what you need outside the core: Keycloak's SAML, brokering and federation are in the community distribution, while Authelia lists no SAML support, which may push you toward a second product. Confirm that every feature you rely on is in the edition you plan to run, and get that confirmed in writing before the quote is final.
Moving from Authelia to Keycloak or the reverse
This sequence takes a team from a reverse-proxy authenticator to a full identity provider, or back, one application group at a time, so that users, directory data and access rules move with a documented check at each stage. The result is a cutover you can reverse, with parallel access proven before the old path is removed.
Inventory protected applications and their protocols
The platform or security team lists every application behind Authelia or Keycloak, including the reverse proxy route, the protocol each one uses (forward auth, OpenID Connect, SAML 2.0 or LDAP-bound), the owner and the access rule that applies. Protected sites that rely on Authelia's forward auth are a different migration from applications that already speak OIDC, so the inventory separates them. The step is done when every application has one row, an owner and a protocol, and the team agrees which applications move in each wave.
Confirm user source and attribute needs
Identify where users live today: a YAML file of users with hashed passwords, an LDAP directory such as OpenLDAP, FreeIPA or Active Directory, or Keycloak's own user store. Record which attributes and groups each application reads, because Authelia's access rules and Keycloak's client mappers depend on different attribute names. Keep the directory as the system of record where one exists, since users and group structure in an LDAP or Active Directory directory transfer without being rebuilt. The output is a short attribute and group map signed off by the application owners.
Stand up the target in a non-production environment
Deploy the target identity service in a test environment that mirrors production networking, HTTPS and certificates. For Keycloak, the production database must be a supported relational database such as PostgreSQL 14 to 18, because the default dev-file database is for development only. Authelia's storage options (PostgreSQL, MySQL or SQLite) are a different migration from Keycloak's database, so the team records which store holds Authelia's preferences, second factor registrations and authentication logs. The check is a working login through the target for one test application.
Map MFA and session policy
Translate each Authelia access rule, including its one-factor and two-factor requirements, into the equivalent Keycloak authentication flow or conditional requirement, and decide which second factors remain (one-time passwords, security keys, passkeys or Duo push). Authelia's second factor enrollments do not move to Keycloak, so every user needs to re-enroll, and the help desk script should say so. Session lifetimes are set explicitly on both sides. The step is complete when a written policy table matches each protected application to a factor level and a session timeout.
Migrate or re-register applications one group at a time
Move applications in the waves agreed during inventory. Forward-auth sites are rebuilt as proxy rules in the reverse proxy and pointed at the new authenticator, while OIDC or SAML applications get a new client or SAML registration, with redirect URIs and signing certificates checked against the test environment. Keycloak's database schema migrates automatically at startup by default, and administrators who need tighter control can apply the schema changes manually, which the upgrading guide suggests for large deployments. Each wave closes when its applications complete a login and logout test with the right factor level.
Run parallel access during cutover
Keep the old path available while the new one serves the migrated group, with DNS or proxy routing that can switch back quickly. Users in a pilot group sign in through the new path and the team watches authentication logs, failed factor enrollments and support tickets. Because Authelia requires HTTPS for its session cookies, both paths must present valid certificates for the same host names during this window. The cutover is ready to close when the pilot group has run through normal work without access exceptions and the rollback steps have been rehearsed.
Retire the old path
After every wave has passed its checks, remove the old authenticator's routes, client configurations and storage that no longer serve users, and archive its configuration and logs according to the organization's retention rules. Confirm with the compliance lead what evidence of the change must be kept, since DeployOpen prepares evidence but does not issue audit reports. The step is done when the old path has no live routes, the archive is verified, and the runbook reflects the new architecture.
What implementing each involves and where projects run long
Keycloak and Authelia put work in different places, and the difference shapes the schedule. Keycloak is a full identity server, so the first decisions are about the platform itself: the production database (Keycloak needs a relational database in production, and PostgreSQL 14 to 18 is one of the supported choices), TLS and public hostnames, and the high availability architecture. Then come realm and client configuration, user federation or identity brokering, and an upgrade routine. Keycloak's own guidance is to plan upgrades deliberately: its Operator documentation strongly recommends manual approval mode for operator updates, and database schema migration runs automatically at startup by default, which teams often choose to control by hand for large deployments. Confirm your database backup and rollback steps before the first production upgrade, not after.
Authelia's work is spread across your estate rather than concentrated in one server. Each protected host needs its reverse proxy wired to Authelia, from one of the supported proxies such as Traefik, Caddy, NGINX or HAProxy, and every protected site must be served over HTTPS because Authelia's session cookies require it. The team then chooses a first-factor backend (an LDAP directory or a YAML file of users), a storage backend (PostgreSQL, MySQL or SQLite) for second-factor registrations and logs, and the access control rules that decide which users reach which hostnames and paths. Those rules are the part that grows over time, so write them down per application and review them with the application owners. Projects run long in predictable places. The first is application claim needs that nobody documented: an app may expect a specific group, role or attribute in the token or header, and Authelia's forward-auth model may not supply it without extra work. The second is SAML requirements discovered late, since Authelia offers no SAML support and a single SAML service provider can push the design toward Keycloak. The third is directory schema differences when LDAP users carry attributes named differently across OpenLDAP, FreeIPA or Active Directory. The fourth is high availability decisions made after go-live, because a session store or database choice made for a pilot is hard to change under live users. Ask each application owner for its protocol, claim list and session length before scoping.
Questions buyers ask before choosing or hiring help
What drives the cost and effort of running Keycloak compared with Authelia?
The main driver is how much identity scope each platform must cover, not the license fee, because both are Apache-2.0 and free to download. Keycloak needs a relational database in production, supports PostgreSQL 14 to 18 and other databases, and its high availability design depends on a synchronously replicated database, so the database, backups and cluster operations carry real work. Authelia stores its data in PostgreSQL, MySQL or local SQLite, so its footprint is smaller, but it still needs an HTTPS-served reverse proxy, a user backend and second-factor setup. Ask any provider for a written quote that separates one-time build work (integration, hardening, documentation) from recurring work (upgrades, patching, support retainers, testing).
Can a team run Keycloak or Authelia without outside help?
Yes, a team with platform skills can run either one, and the answer depends on the skills available rather than on the software. Authelia suits a team that already operates a reverse proxy such as Traefik, Caddy or NGINX and wants forward auth for web apps. Keycloak suits a team that will run a database cluster, manage realms and clients, and plan upgrades; its Operator documentation strongly recommends manual approval mode for operator updates, which is a sign that upgrade discipline matters. Teams without that capacity often bring in an implementation partner for the first build and then decide whether to keep a retainer. DeployOpen implements and supports self-hosted platforms inside the client's own infrastructure, under written, fixed-scope agreements.
How long does a typical Keycloak or Authelia deployment take?
No duration is supplied for either platform, so treat any timeline as unknown until it is written down. The timeline is set by the number of applications to integrate, whether each application has an owner available for testing, the number of user directories to connect, the database and high availability design, and the approval process for DNS and certificate changes. Authelia deployments are usually bounded by the number of proxied applications and the choice of user backend, while Keycloak deployments are usually bounded by realm design, identity brokering and federation work. Ask for a written scope with deliverables and a timeline agreed before work starts, and check which items are excluded.
What does the work need from our side before deployment starts?
The work needs access and decisions from several owners, and most delays come from waiting for them. Expect to provide:
- Directory access, such as read-only bind credentials for an LDAP directory, OpenLDAP, FreeIPA or Active Directory, if users will come from one.
- DNS records and a hostname plan for the login portal and each protected application.
- Certificates for HTTPS, since Authelia works only for HTTPS-served sites because its session cookies require it.
- Named application owners who can test redirects, claims and logout behavior.
- A decision on the database platform, backup schedule and who approves production changes.
Confirm each item in writing before the scope is signed.
Can Authelia replace Keycloak for SAML applications?
No. Authelia's support chart lists no SAML support, so it cannot act as the SAML identity provider for applications that require SAML 2.0. Authelia is OpenID Certified for the Basic, Implicit, Hybrid, Form Post and Config OP profiles of OpenID Connect, and it works as a companion to reverse proxies. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so applications that need SAML are a clear reason to choose Keycloak. If a SAML application sits behind a proxy protected by Authelia, the SAML login still has to come from a SAML-capable identity provider. Confirm each application's protocol requirements before choosing Authelia.
How do we decide whether we need Keycloak, Authelia or both?
Start with the protocols and the application inventory, then decide whether you need a full identity provider, a proxy authenticator, or both. Choose Keycloak when you need SAML, brokering to external identity providers, user federation with LDAP or Active Directory, an admin console for delegated administration, or fine-grained authorization. Choose Authelia when the main goal is to add single sign-on and second factors in front of web applications that already sit behind a supported proxy. Many teams use both: Keycloak for SAML and OIDC applications, and Authelia in front of legacy web apps that cannot integrate directly. Document which applications use which path before implementation.
What does it cost to move from Authelia to Keycloak later?
The cost depends on how many applications, user stores and second-factor enrollments must move, and on whether application integrations are rebuilt or only repointed. Authelia sits in the request path at the reverse proxy, so moving to Keycloak usually means changing how each application handles login, redirects and sessions, which is application-specific work. Second-factor device registrations and user preferences stored in Authelia's database would need an export or re-enrollment plan. Ask any provider for a migration plan that lists each application, its owner, its test steps and the rollback approach before committing to either platform.
How DeployOpen helps choose, implement and migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Keycloak vs Authelia, we start by mapping which applications need a full identity provider and which only need a gate in front of a reverse proxy, then build and hand over the option that fits.
How we scope
- Inventory which applications need SAML, OIDC federation or LDAP and which sit behind a proxy
- Agree the reverse proxy, user backend and second factor methods in writing before work starts
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing up front
How we build
- Deploy Keycloak or Authelia in your cloud accounts, data centers or air-gapped networks
- Configure the database, HTTPS, proxy integration and user backend for your environment
- Test login flows, second factor enrollment and session behavior against each protected application
How we hand over
- Document configuration, realms or access rules, and the steps to add a new application
- Deliver runbooks covering backups, upgrades and the database schema migration process
- Plan any move between the two platforms as a scoped piece of work with a rollback path
How we support
- Ongoing support, upgrades and continuous testing are available as retainers
- Retainers can cover patching to new Keycloak or Authelia releases after your change review
- Confirm with us which release lines, monitoring and on-call coverage your retainer includes
