authentik or Authelia: when each one fits
authentik fits when your team needs a full identity provider with an admin UI, SAML, LDAP, RADIUS and proxy providers in one system. Authelia fits when the need is forward auth and OpenID Connect for a small set of web apps behind a reverse proxy. The choice turns on five questions. First, protocols: Authelia's support chart lists no SAML, so any SAML service provider rules it out unless you add a different component. Second, user backend: Authelia authenticates against LDAP (OpenLDAP, OpenDJ, FreeIPA or Active Directory) or a YAML file of users, while authentik manages users in its own database and provides LDAP as a provider. Third, second factors: confirm that the one-time passwords, passkeys, security keys or Duo push you need are supported by the product you pick. Fourth, licensing: authentik core is MIT, but the Google Workspace and Entra ID integrations, mTLS and other features sit in the enterprise-licensed directory and need a paid subscription for production. Fifth, scale: count the services that must sit behind SSO and whether they all use the same pattern.
Run a short test before you decide. List each application with its protocol (OIDC, SAML, LDAP bind or header-based proxy login), its user source and the second factor your policy requires. If every app can use OIDC or sits behind a supported proxy such as Traefik, NGINX or Caddy, Authelia's smaller footprint is a reasonable match. Authelia also requires HTTPS, so confirm that every protected site has a valid certificate. If any app needs SAML, a provisioning feed, or a single place to manage users, groups and policies for many systems, plan for authentik and confirm the feature set against the authentik pricing page for the edition you need. Keep the licence check in writing with your legal or procurement team, since the enterprise boundary determines what you can run in production without a subscription.
How authentik and Authelia are built and deployed
authentik runs as a set of stateful services that you operate as a platform, while Authelia is a companion that sits beside your reverse proxy. The cards below cover what each one runs, where its state lives, and what that means for patching, backups and proxy integration.
authentik server with embedded outpost
The server container runs the core identity provider plus an embedded outpost, which is the component that answers proxy and forward-auth requests for applications. Because the outpost lives in the same container as the server, upgrading the server also upgrades the outpost that your protected apps depend on. Check whether you need separate outposts for sites or networks that the core server cannot reach directly, and plan a maintenance window for each server upgrade.
authentik worker container
A second container runs background tasks such as scheduled jobs, synchronization and outbound work. If the worker is down, the login pages may still load while sync, cleanup and other queued work stalls, so monitor it as its own service. Confirm that both containers run the same authentik version after every upgrade, since mismatched images are a common cause of hard-to-trace failures.
PostgreSQL as the only data store
authentik stores configuration and data in PostgreSQL, with uploaded files as the exception. Your backup, restore and high-availability plan therefore centers on one database, and a restore test should cover a full authentik instance rather than a dump of a single table. Ask your DBA to size connections for the platform, because the 2025.10 change described next increased connection use.
Redis removed in 2025.10
The 2025.10 release moved caching, tasks, sessions and WebSocket functions from Redis to PostgreSQL, so there is no Redis to run. The release notes warn of roughly 50% more PostgreSQL connections after upgrading. If your database has a tight connection limit or uses a connection pooler, test that headroom before upgrading from an older release that still depended on Redis.
Authelia as a per-request companion
Authelia does not sit in the traffic path as an identity provider on its own. Your reverse proxy asks Authelia whether each request is allowed, and unauthenticated users are redirected to Authelia's login portal. This means that the proxy integration is the main setup task, and every protected route depends on the proxy configuration staying correct after changes.
HTTPS-only and supported proxies
Authelia works only for sites served over HTTPS, because its session cookies require it, and the project declines to support plain HTTP. Confirm that your certificate process, including renewal, covers every protected hostname before you deploy. Check that your proxy appears on the supported list, since Traefik, Caddy, Envoy, NGINX and HAProxy are listed, while Apache and IIS are documented separately.
Authelia storage backends
Authelia stores user preferences, second factor device registrations and authentication logs in PostgreSQL, MySQL or local SQLite. SQLite is simpler for a single host, but it puts the backup burden on the file and the host, while PostgreSQL or MySQL moves that burden to a database you already operate. Decide which backend you will back up and restore before choosing the deployment.
Which scenario favors authentik and which favors Authelia
This table maps common situations to the platform that fits them better and names the condition under which the other one would win. Read each row against your own protocols, user directory and team size, since the right choice often depends on one requirement rather than overall feature count.
| Scenario | Better fit | When the other platform fits better |
|---|---|---|
| SaaS-style app catalog that needs SAML for enterprise customers | authentik, because its provider list includes SAML alongside OAuth2 and OpenID Connect | Authelia, only if every app you protect speaks OpenID Connect or sits behind a proxy, since its support chart lists no SAML |
| Homelab with Traefik or Caddy and a handful of apps | Authelia, because it is built as a forward-auth companion for these proxies and needs little infrastructure | authentik, if you want a web admin UI for flows and policies, or outposts for apps that need more than forward auth |
| Mixed Active Directory environment with LDAP users | authentik, because it provides an LDAP provider and an admin interface for mapping directory groups to access policies | Authelia, if the only goal is first-factor login against an existing LDAP directory and you do not need the extra provider types |
| Team that wants an admin UI to manage policies and flows | authentik, since configuration of providers, applications and flows is handled in its web interface | Authelia, if your team prefers keeping access rules in a YAML configuration file under version control |
| Team that needs only OIDC and second factors in front of a few services | Authelia, which offers one-time passwords, security keys, passkeys and Duo push with a lightweight footprint | authentik, if you later need SAML, LDAP or RADIUS providers and expect the list of integrated apps to grow |
| Protecting internal apps that must be reached without HTTPS | Neither platform fits as-is, so plan TLS first | Authelia requires HTTPS for its session cookies and does not support plain HTTP, so confirm your certificate setup before choosing |
| Need for a paid support tier or enterprise-only features | authentik, if you need Enterprise features such as Entra ID sync, mTLS or enhanced audit logging, which require a subscription | Authelia, if the open-source feature set covers your needs and you do not need vendor subscription terms |
Protocols, user backends and second factors compared
authentik supports several protocols from one admin console, which matters when the application list includes SAML service providers, LDAP clients or RADIUS consumers. Authelia's scope is narrower: it acts as an OpenID Connect provider and a forward-auth companion, and its support chart lists no SAML.
- OAuth2 and OpenID Connect: authentik provides OAuth2/OIDC providers, and Authelia is OpenID Certified for the Basic, Implicit, Hybrid, Form Post and Config OP profiles. Both cover modern web and API clients, but confirm which profile each application requires.
- SAML: authentik documents a SAML provider. Authelia's support chart lists no SAML, so SAML-only business applications point toward authentik or another product.
- LDAP and RADIUS: authentik documents LDAP and RADIUS providers for directory-bound and network-access clients. Authelia's documented role covers neither, so these needs favor authentik.
- SCIM and directory sync: authentik lists SCIM among its provider types. Confirm with the authentik providers documentation whether your target applications need SCIM push.
Check your application inventory for SAML, LDAP and RADIUS consumers first, because those needs can settle the product before feature lists do.
Both products can protect applications that have no login of their own. Authelia is built for this role: the reverse proxy asks it whether each request may pass, and unauthenticated users are sent to its login portal. authentik offers proxy providers served through an outpost, which is a different deployment shape. Your proxy choice and network layout shape the effort for each.
- Proxy support: Authelia's supported proxies include Traefik, Caddy, Envoy, NGINX, NGINX Proxy Manager, SWAG, HAProxy and Skipper, with Apache and IIS listed separately. Check your exact proxy version against that list.
- HTTPS requirement: Authelia works only for websites served over HTTPS because its session cookies require it, and the project declines to support plain HTTP. Plan certificates for every protected site before you start.
- Outpost model: authentik's server container includes an embedded outpost, and its architecture documentation describes how the components fit together. Confirm whether your network needs a separate outpost placement.
- Footprint: Authelia is a lightweight companion, while authentik runs a server container, a worker container and PostgreSQL. Its Docker Compose guide calls for at least 2 CPU cores and 2 GB of RAM for test and small-scale production setups.
Confirm that your proxy is on the supported list and that every protected site can run on HTTPS before you compare setup effort.
Where user accounts live determines much of the ongoing work. Authelia authenticates against an LDAP directory or a YAML file of users with hashed passwords, and it stores preferences, second factor registrations and logs in its own SQL database. authentik stores its configuration and data in PostgreSQL and manages users as objects in its own admin interface.
- LDAP backends: Authelia supports OpenLDAP, OpenDJ, FreeIPA and Microsoft Active Directory as first factor backends. This suits teams that already keep identities in one of those directories.
- YAML file users: A file of users with hashed passwords is simple to start with, but each account change is a file change. It fits small, stable user sets, so confirm whether your team can accept that change control.
- authentik-managed users: authentik keeps users in its database, and its architecture documentation says PostgreSQL stores all configuration and data except uploaded files. Plan backups and upgrade windows around that database.
- Authelia state: Preferences, second factor registrations and authentication logs live in PostgreSQL, MySQL or local SQLite. Choose the database against your backup and retention requirements.
- Cloud directory sources: Google Workspace and Microsoft Entra ID integrations appear on authentik's Enterprise-only list. If either is your source of truth, price that edition into the decision.
Decide where the authoritative user record lives before choosing, because moving it later changes every application login path.
Authelia's documentation lists one-time passwords, security keys and passkeys, and Duo mobile push as second factors. It also offers self-service password reset and bans accounts after too many failed attempts. The authentik factor list is not covered in this comparison, so confirm it directly in the authentik documentation before you rely on any method.
- One-time passwords: Authelia supports OTP as a second factor. Confirm that the authenticator app standard matches your policy and your users' devices.
- Security keys and passkeys: Authelia supports both. Verify that your browser and device fleet handles the registration flow you plan to use.
- Duo push: Authelia documents Duo mobile push, so teams already licensed for Duo can keep that workflow. Duo licensing sits outside this comparison, so confirm terms with your vendor.
- Account protection: Authelia includes account banning after repeated failures and self-service password reset. Decide who approves resets and who unlocks banned accounts.
- authentik factors and mTLS: Confirm which second factors and passwordless methods authentik supports in its current documentation. mTLS client certificate authentication is listed as an Enterprise-only feature on its pricing page, so check whether it meets any stronger requirement.
Write your MFA policy first, then test each factor with a pilot group of real users before you commit to a product.
What drives the running cost of each
This table sets the recurring and one-time cost drivers for authentik and Authelia side by side, so you can see where each one spends staff time and money. Read each row as a question to put to your team and to any implementation quote, not as a price comparison, because neither project publishes a cost model for your environment.
| Cost driver | authentik | Authelia |
|---|---|---|
| Infrastructure footprint | The Docker Compose guide calls for at least 2 CPU cores and 2 GB of RAM and positions Compose for test and small-scale production. Production adds PostgreSQL, which stores all configuration and data, plus a worker container. | Lighter footprint as a companion to your reverse proxy. Storage for preferences, second factor registrations and logs can be SQLite, PostgreSQL or MySQL, so confirm which backend your sizing assumes. |
| Database and dependencies | PostgreSQL is mandatory and carries caching, tasks and sessions since the 2025.10 release removed Redis. The release notes warned of roughly 50% more PostgreSQL connections after upgrading, so budget for database sizing and monitoring. | SQLite works for small setups, while PostgreSQL or MySQL moves storage to a server you must back up and patch. Ask whether you need a shared database for more than one Authelia instance. |
| Skills and daily operations | Staff run the admin UI, flows, stages, providers and outposts. Operations skills centre on identity configuration, which can be learned by the identity team but takes time to master. | Staff edit configuration files and proxy rules for each protected site. Skills centre on reverse proxy work (Traefik, NGINX, Caddy and others), which many platform teams already have. |
| Upgrade effort and release lines | Versions are named by year and month. The security policy lists 2026.5.x and 2026.8.x as supported for security fixes, and security releases are announced at least 24 hours in advance, so plan a window that short. | Authelia publishes tagged releases on GitHub; confirm its current support policy and advance notice for security fixes with the project before you commit to an upgrade schedule. |
| Per-user licensing | The Open Source edition is free, but Enterprise features such as Entra ID and Google Workspace integration, mTLS and enhanced audit logging require a paid subscription. The pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month. | Authelia is Apache-2.0 with no per-user licence fee. Licence cost is zero, so the recurring spend is infrastructure, staff time and any support contract you agree separately. |
| Policy and access rule maintenance | Policy changes run through flows, groups and providers in one interface, which can cut repeated edits but adds a review step for each change. Ask who approves policy changes and how often they are audited. | Access rules live in configuration for each protected site, so every new application adds rules to maintain. Standardize rule templates early to keep review time from growing with the app count. |
| One-time implementation | Initial design of flows, providers, branding and migrations from an existing directory or SSO is usually the largest one-time item. Ask for the scope of each in a written quote. | Initial setup of the proxy, the user backend (file or LDAP) and second factors is usually smaller, but migrating existing users and sessions still needs planning. Confirm the scope in writing. |
| What to request in a quote | Itemized sizing for PostgreSQL and workers, the Enterprise licence count for internal and external users, and the named upgrade window for security releases. | Itemized proxy and backend configuration work, storage choice and support terms, plus the upgrade and testing effort for each release you plan to apply. |
Moving users and apps from Authelia to authentik, or back
This sequence moves protected applications and their users between Authelia and authentik in a controlled order, so each app switches with a working rollback path and the old companion can be retired once nothing depends on it.
Inventory every app and its auth method
The platform team lists each application behind the current setup and records how it authenticates: a reverse proxy forward-auth check with Authelia, a direct OpenID Connect client, a header-based login, or a local account that bypasses SSO entirely. Application owners confirm which apps need users, groups or claims from the identity source. The step is done when every app has one row in a shared inventory with its owner, hostname, auth method and rollback contact.
Map user sources and second factors
Identify where users live today. Authelia can read users from a YAML file with hashed passwords or from an LDAP directory such as OpenLDAP, FreeIPA or Active Directory, and it stores second factor enrollments and preferences in PostgreSQL, MySQL or SQLite. Record which factors each user holds (one-time passwords, security keys, passkeys or Duo push) and confirm with the vendor or your own tests how authentik will connect to the same directory. The output is a user source map showing which accounts can move without re-creation and which factors will need re-enrollment.
Stand up authentik with its database
Deploy authentik alongside the existing setup, not in place of it. Its server and worker containers store configuration and data in PostgreSQL, so provision that database with backups before the first login. Connect the LDAP source, create groups that mirror the access rules from Authelia, and confirm that a test user can sign in to the admin interface. Authentik requires HTTPS for its public endpoints just as Authelia does, so the certificate and hostname plan must be ready. The step closes when a test account authenticates against authentik and the database backup has been restored successfully once in a non-production copy.
Rebuild proxy rules or OIDC client registrations
Nothing from Authelia's access configuration transfers automatically. For each app that sits behind a reverse proxy, create an authentik proxy provider and application with equivalent access rules, and for each app that speaks OpenID Connect, register a new client in authentik and copy the redirect URIs and scopes into the app. Verify the proxy type matches the way your reverse proxy calls the outpost, and confirm that HTTPS is used on every hostname. The step is complete when each app has a provider or client in authentik and a documented list of the settings changed from the Authelia version.
Re-enroll factors and test each app in staging
Second factor enrollments do not move with the directory data, so users must register their one-time password apps, security keys, passkeys or Duo push again in authentik. Plan a window where each user is told which factor to enroll and how to contact the help desk if a device is lost. Run a test login through every rebuilt app, including logout, session expiry and a denied-access case. The output is a signed-off test record per app showing which users re-enrolled and which checks passed.
Cut over one app at a time with rollback
Switch a single low-risk application first by pointing its reverse proxy route or client configuration at authentik while keeping the Authelia route ready. Watch authentication logs and user reports, then move the next app. For each cutover, the rollback path is to restore the previous proxy route or client setting, which should be documented and tested before the switch. The step is done when every app in the inventory has moved, the rollback path has been tested at least once, and no app still depends on the old route.
Retire the old companion
Once every app runs on the new provider and the rollback window has passed, remove Authelia's forward-auth routes, stop its service and archive its configuration, user file and database. Keep the backups for the retention period your policy sets. Remove any leftover DNS records and certificates that only served the old login portal. The check is that no reverse proxy route still points at Authelia, the archive has been verified, and the inventory records the retirement date and approver.
Where implementation projects usually run long
Implementation effort on authentik tends to concentrate in provider and flow design, not in installing the server. Each application needs the right provider type (OAuth2/OIDC, SAML, LDAP or proxy), and flows, stages and policies have to be designed so that login, enrollment and recovery behave the same way across apps. Outpost placement is a separate decision: the embedded outpost in the server container covers many cases, but proxy or LDAP access from segments that cannot reach the server needs its own planning. User sources also take time, because syncing from an existing directory means agreeing which system owns each attribute before the first sync runs. Confirm with your own architects whether Enterprise features such as Google Workspace or Microsoft Entra ID integration, mTLS or privileged access management are required, since that decision changes both licensing and the integration work. After upgrades, check PostgreSQL sizing and connection limits, because the authentik 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading and note that Redis is no longer used.
Implementation effort on Authelia concentrates in the proxy and the access rules. Every protected site needs an access control policy written against its hostnames and paths, and each one needs HTTPS, because Authelia's session cookies require it and the project does not support plain HTTP. Certificate issuance and renewal for every protected name is therefore part of the project, not an afterthought. User setup depends on the backend: a YAML file of users is simple to start with but becomes manual administration at scale, while LDAP through OpenLDAP, FreeIPA or Active Directory moves the work into directory management. Applications that need OpenID Connect each require a client registration and redirect URI configured in Authelia and in the app, and that work repeats per application.
Across both products, the same causes push timelines out. Mixed identity sources, such as an Active Directory domain alongside local accounts and a SaaS directory, create ownership questions that take longer than any technical step. Undocumented applications surface during testing when their login path, headers or callback URLs turn out to be unknown. SAML demands are a frequent late discovery: Authelia does not support SAML at all, and authentik supports it only in the protocols it provides, so confirm SAML needs with every application owner in discovery. Backup and restore testing is often skipped, yet it should cover the database, configuration and any second factor registrations before go-live. Ask any implementation partner for a written scope that lists each application, its protocol and its owner, and that includes restore tests, so the schedule reflects these risks.
Questions buyers ask before choosing or hiring help
Does authentik need the Enterprise edition for production use?
Not for the core. authentik core is MIT licensed, so the open source code can run in production without a subscription. The exception is code under the authentik/enterprise directory, which falls under a separate enterprise license and needs a paid subscription for production use. Check which features your design depends on before you deploy. The Enterprise-only items on the pricing page include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. If you need none of these, the open source edition may cover your scope. Confirm the license terms against the current authentik pricing page and the LICENSE file in the repository, since editions and feature placement can change between releases.
Can Authelia replace applications that depend on SAML?
No, not as a direct replacement. Authelia's support chart lists no SAML support, and it is OpenID Certified for the Basic, Implicit, Hybrid, Form Post and Config OP profiles of OpenID Connect. Authelia also works as a companion to reverse proxies, so it protects web applications by asking the proxy whether to allow each request. Applications that need SAML assertions, such as many older enterprise SaaS connectors, will need a different provider. authentik supports SAML as a provider type, so it is a common option when SAML apps are on the list. Inventory every application's protocol before choosing, and confirm each vendor's supported authentication methods in its own documentation.
How long does an identity provider migration take, and what drives it?
Duration depends mostly on the number of applications, the protocols they use, and the user source. Each application needs its redirect URIs, client settings and claims mapped to the new provider, and each one needs its own test pass before cutover. Migrating user passwords or second factor enrollments is often the hardest part, because Authelia stores second factor device registrations in its own database and authentik stores its data in PostgreSQL, so enrollments may need to be repeated. Running both systems in parallel adds effort. A consultant can give a duration only after the written scope lists the applications and integrations. Ask for the inventory, the cutover plan and the rollback steps to be part of that scope.
What does a consultant need from our team before starting work?
Most of the early work depends on access and decisions from your side. The consultant will need an inventory of applications with their protocols, owners and hostnames, plus a list of which user sources are authoritative, such as LDAP, Active Directory or a local user file. Test or staging environments, access to the reverse proxy configuration, and a named approver for changes to production identity services are also needed. Security approvals for firewall rules, certificates and HTTPS termination should be agreed up front, since Authelia requires HTTPS for its session cookies. DeployOpen plans, implements and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Can our own team run authentik or Authelia without outside help?
It depends on your team's experience with PostgreSQL, container platforms, reverse proxies and identity protocols. authentik runs as a server container with an embedded outpost and a worker container, storing its configuration in PostgreSQL. Authelia is a smaller component that sits beside your proxy and stores data in PostgreSQL, MySQL or SQLite. Both need ongoing patching, backups and upgrade testing. authentik's security policy lists the supported release lines that receive security fixes, and the project announces security releases at least 24 hours in advance, so someone must watch that feed. Teams that already run these stacks can often operate the system internally. Teams new to identity services may prefer a support retainer for upgrades and testing, which DeployOpen offers.
Which cost components should we request in a quote?
Ask for each component separately so you can compare options fairly. A quote should list discovery and inventory work, architecture and design, the proxy or provider configuration for each application, user source integration, second factor setup, testing, cutover support, documentation and handover. Recurring items include patching, upgrades, backup verification and any retainer for continuous support. On the software side, authentik's Enterprise edition is priced per user and per external user on its public pricing page, and Authelia's license is Apache-2.0 with no paid tier. Ask whether the quote includes any subscription fees, infrastructure costs in your cloud or data center, and what is excluded. DeployOpen does not publish a price list, so a quote follows from the written scope.
What breaks most often when moving applications behind a new SSO setup?
The most common failures involve redirect URIs, cookie domains, and session handling. Authelia depends on a correct domain structure and HTTPS, so mismatched hostnames or plain HTTP test endpoints will fail. Applications that cache sessions or hold their own login state can loop or show errors after cutover. Group and claim mapping errors often appear only for specific roles, so test with real accounts from each group. Keep the old provider available for rollback until each application has been verified. Ask your consultant or internal team to document each application's login path, so troubleshooting does not depend on one person.
Primary sources to check before you decide
Start with the licensing and editions question, because it decides what you can run in production without a contract. Read the authentik pricing page for the current edition list and the enterprise-only features, then read the authentik LICENSE file to confirm that the code under the enterprise directory carries a separate license. Authelia's license is Apache-2.0 according to its repository, so the check there is whether the feature set you need is available in the open project. Ask your legal or procurement team to read both license texts, not only the summary pages, before you commit to either product.
Next, check architecture and protocol coverage against your own applications. The authentik architecture and authentik providers pages describe the server, worker and PostgreSQL components and the provider types, including SAML, LDAP and proxy. For Authelia, the Authelia architecture page explains the forward-auth model and its HTTPS requirement, the supported proxies page lists the proxies you may already run, the OpenID Connect page shows the OIDC profiles and the absence of SAML, and the first factor page lists the user backends. Confirm that your reverse proxy and each application's login method appear on these lists.
Finally, confirm current versions and release cadence on the release pages before you plan an upgrade path. Check the authentik GitHub releases page for the supported lines and the security notice window, and the Authelia GitHub releases page for the current release and its changelog. The authelia repository is also where you can check open issues on the features you depend on. Record the version you tested, the date you checked it, and any change to licensing or support terms, so the decision can be reviewed when a new release ships.
How DeployOpen helps you choose and implement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For authentik vs Authelia, we start by mapping which applications need SAML, OIDC, LDAP or proxy-based protection before recommending either product.
How we scope
- Inventory which applications need OIDC, SAML, LDAP, RADIUS or reverse-proxy protection before choosing a product
- Confirm the user source, such as an existing LDAP directory, Active Directory or a local user file
- Agree in writing whether the Enterprise edition is needed, and which features it would cover
- Define the reverse proxy, HTTPS termination and database platform the deployment will run on
How we build
- Deploy the chosen platform in your cloud account, data center or air-gapped network
- Configure providers, applications, second factors and user sources to match the agreed scope
- Integrate with your existing identity sources, logging and reverse proxies, and test login flows end to end
- Run security testing on the authentication endpoints and documented configuration before go-live
How we hand over
- Document the architecture, provider configuration, backup and restore steps and upgrade procedure
- Provide evidence of configuration and access controls that your compliance assessors can review
- Walk your operators through day-to-day administration, user onboarding and incident steps
- Deliver the work to the fixed-scope deliverables agreed in writing before work started
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan version upgrades around the vendor's published release and security support windows
- Confirm current release and license details with the vendor before each upgrade decision
- Quote support from the written scope, since DeployOpen does not publish a price list
