When is Ory open source enough, and when does the Enterprise License become necessary?
Apache-2.0 is enough when you are evaluating, developing, or running a deployment where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. That is Ory's own guidance for Ory Open Source, and it is the test to apply first. If your identity service can be taken offline for upgrades in a planned window, and your team can track security advisories and ship fixes on its own schedule, the open source Kratos, Hydra, Keto, Oathkeeper and Polis servers are a sound basis. Ory also states that OEL builds are drop-in replacements for open source installations, so you can start on Apache-2.0 and move later without rebuilding the deployment. The Enterprise License becomes necessary when a requirement is written into a contract, a policy or a feature list. The Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as enterprise features not available in the open source version. The Ory Enterprise License documentation adds Kratos multi-tenancy and organizations and the Hydra ROPC grant, along with 24/7 support SLAs and timely CVE patches. Check each requirement against your architecture: if one customer or business unit needs its own identity boundary inside a single Kratos deployment, or if an identity provider must provision users through SCIM, the open source build will not meet it. Ask Ory to confirm in writing which enterprise features and patch timelines apply to your version. One option sits outside this comparison. Ory pricing describes Ory Network as a managed cloud service offered alongside the self-hosted components and the Enterprise License. Choosing Ory Network moves hosting and patching to Ory, which changes the decision about where identity data lives, so treat it as a separate decision and compare it on its own terms.
Which Ory capabilities are in open source and which are Enterprise License
This table compares the capabilities Ory lists as open source against those it places in the self-hosted Ory Enterprise License (OEL). Read each row as a question to answer for your own deployment, and confirm any gap with Ory before you rely on it. The main takeaway is that identity federation features, multi-tenancy and patch commitments are where the two editions differ most.
| Capability | Ory open source | Ory Enterprise License |
|---|---|---|
| Server license | Apache-2.0 for Kratos, Hydra, Keto, Oathkeeper and Polis | Optimized builds of the same servers under the OEL, offered as drop-in replacements |
| SCIM | Not included; Kratos README lists it as an enterprise feature | Included as an enterprise feature on self-hosted Kratos |
| SAML | Not included; Kratos README lists it as an enterprise feature | Included as an enterprise feature on self-hosted Kratos |
| Organization login (SSO) | Not included; Kratos README lists it as an enterprise feature | Included as an enterprise feature on self-hosted Kratos |
| CAPTCHAs | Not included; Kratos README lists it as an enterprise feature | Included as an enterprise feature on self-hosted Kratos |
| Kratos multi-tenancy and organizations | Not listed as open source in the Ory documentation | Included, per the Ory Enterprise License documentation |
| Hydra ROPC grant | Not listed as open source in the Ory documentation | Included, per the Ory Enterprise License documentation |
| 24/7 support SLAs | No support SLA in the open source offering | Included, per the Ory Enterprise License documentation |
| Timely CVE patches | No guaranteed patching; Ory says open source suits cases where it is not required | Included, with CVE patch SLAs stated in the Kratos README |
How licensing, support and updates differ by edition
The Ory servers are Apache-2.0 in both editions of the self-hosted stack, so the difference lies in what Ory commits to around them. The cards below separate the license terms, the support and patching commitments, and the upgrade path, so you can check each one against your own risk tolerance before you choose.
Apache-2.0 open source terms
Kratos, Hydra, Keto, Oathkeeper and Polis are each published under Apache-2.0. You can run, modify and redistribute the open source servers without a license fee. What you do not get is a contractual commitment from Ory on support hours, response times or patch timing. Confirm the license file in each repository you deploy, because the terms apply per component, not to the Ory brand as a whole.
What the enterprise license adds
The Ory Enterprise License (OEL) is a commercial license for self-hosted deployments. Ory lists enterprise features such as Kratos multi-tenancy and organizations, and the Hydra ROPC grant. The Kratos README also names SCIM, SAML, organization login and CAPTCHAs as enterprise features not in the open source build. Ask Ory for the current feature matrix in writing before you assume a feature is included.
Support windows and SLAs
The OEL includes 24/7 support SLAs. Open source has no contractual support window, so incidents depend on community channels and your own on-call staff. If an outage would breach a regulatory or customer commitment, the support window is a purchasing requirement. Ask for the response and resolution targets by severity, the hours they cover, and whether they apply to your region and time zone.
CVE patching commitments
Ory states that the OEL includes timely CVE patches, and the Kratos README describes CVE patch SLAs for enterprise deployments. Open source users receive fixes through the public repositories, and applying them is their job. Ask Ory how quickly it patches critical and high severity CVEs, how it notifies customers, and whether patches reach both the enterprise builds and the matching open source tags.
Drop-in replacement of open source installs
Ory states that OEL builds are drop-in replacements for open source installations. That matters if you start on open source for evaluation and later need enterprise features or patch commitments. Test the swap in a staging copy of your configuration and database first, because the migration path, rollback steps and any feature flags still need confirmation from Ory.
Optimized builds and current terms
Ory describes OEL builds as optimized versions of the same open source servers, not separate codebases. Ory's own guidance says open source fits evaluation, development and deployments that accept occasional upgrade downtime and do not require guaranteed CVE patching. Confirm current terms, pricing basis and the exact feature list in the Ory Enterprise License documentation before you sign, because licensing terms change.
What the open source edition is missing for typical enterprise needs
The Ory Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as enterprise features that the open source version does not include. For a B2B product, these are the features customers ask for first. SCIM lets a customer's directory create, update and deprovision users in your application automatically, so offboarding in the customer's identity provider takes effect in your product without a ticket. SAML and organization-level SSO let each customer tenant bring its own identity provider. Kratos multi-tenancy and organizations, which the Ory Enterprise License (OEL) adds, keep each customer's identities and login settings separate inside one deployment. If your roadmap includes any of these, confirm with Ory which edition supplies each one and whether the OEL build changes your upgrade path.
For workforce identity, the question is less about features and more about operations. Ory states that open source suits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Ask your team who will apply Kratos and Hydra upgrades, how long a maintenance window can run, and who watches advisories for the components you run. The OEL adds 24/7 support SLAs and timely CVE patches, and Ory describes OEL builds as drop-in replacements for open source installations. Confirm the patch and support terms in writing, since the SLA details are not part of the researched facts for this page. Your own CVE response time, staffing and change-approval process will decide whether that gap matters.
Which edition fits which team
Ory's own guidance is that Ory Open Source remains a good fit for evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. For a team proving out a login flow, testing Kratos or Hydra against an existing user store, or building a prototype, the Apache-2.0 servers carry the full core: passwords, passkeys, social sign-in, TOTP, OAuth 2.0 and OpenID Connect. The enterprise features discussed on this page are not needed to learn the stack or to validate architecture. Keep the evaluation environment separate from anything that holds real identities, and plan the move to production as its own step.
- Core capabilities are included: Kratos and Hydra can be evaluated end to end without a license conversation.
- Enterprise features are deferred: SCIM, SAML, organization login and Kratos multi-tenancy can be tested later if they become requirements.
- Upgrade downtime is tolerable: Development environments can absorb restarts and breaking changes between releases.
- Production gap is explicit: Document which controls, including CVE patch timing, are missing before the prototype is promoted.
Confirm with Ory whether the drop-in replacement path from open source to the Enterprise License is supported for your specific Kratos and Hydra versions, so the prototype does not become a rebuild.
An internal workforce login, where employees sign in to a fixed set of corporate applications, usually has a smaller feature set than a multi-tenant product. Whether open source is enough depends on whether you can accept maintenance windows for upgrades and whether your security policy lets you run without guaranteed CVE patch timing. If your security team needs a defined response window for vulnerabilities in the identity layer, the Enterprise License's CVE patch SLAs and 24/7 support become relevant. If you can schedule upgrades into planned windows and your patching process can absorb open-source release timing, the Apache-2.0 servers may be enough.
- Downtime tolerance: Decide in writing how long a planned upgrade window can last and who approves it.
- Vulnerability response: Map your internal patch policy to what the open-source project commits to, and compare it with the Enterprise License's stated CVE patch SLAs.
- Support model: Determine whether your team, a retained partner or Ory support will handle incidents that affect login for all staff.
- Feature need: Confirm whether SAML or SCIM is required for your directory and application catalog, since those are enterprise features in Ory's documentation.
- Operations ownership: Name who operates the database, backups and high availability for Kratos and Hydra.
Ask Ory for the current Enterprise License terms in writing, including the support hours, SLA scope and what is covered for self-hosted deployments.
A B2B SaaS product often needs each customer to have its own organization, its own login policy and, in many cases, its own SCIM directory sync or SAML connection. Ory's documentation places Kratos multi-tenancy and organizations, SCIM, SAML and organization login in the enterprise feature set, and the Enterprise License adds CVE patch SLAs. For this team, the question is less whether open source can run the flows and more whether the product can meet customer contracts that specify patch timing, tenant isolation and directory integration. Those obligations usually tip the decision toward the Enterprise License, but only after you confirm what each feature covers.
- Tenant model: Confirm which multi-tenancy and organization features are included in the Enterprise License and how they map to your customer structure.
- Directory sync: Check whether SCIM provisioning through Ory Polis or Kratos meets your customers' identity provider requirements.
- Contractual patch timing: Compare the stated CVE patch SLAs with the timing you promise customers, and ask what happens when a fix lands in a newer build.
- Upgrade path: Ask whether OEL builds can replace open source installations without a data migration, and how often they are released.
- Managed alternative: Weigh the self-hosted Enterprise License against Ory Network if you do not need to keep identity data in your own infrastructure.
Review the customer contracts and data residency commitments before you sign, since those set the minimum patching and hosting terms your identity layer must meet.
What each edition costs to run
This table lists the cost components you will carry under Ory open source and under the Ory Enterprise License, showing who is paid for each and whether it is one-time or recurring. Ory does not publish a fixed OEL price in the sources we have, so use the rows as a checklist for a written quote and for your own internal estimate.
| Cost component | Ory open source (self-hosted) | Ory Enterprise License (self-hosted) |
|---|---|---|
| Software license fee | No license fee for the Apache-2.0 servers (Kratos, Hydra, Keto, Oathkeeper, Polis) | Commercial license fee; confirm the amount and renewal terms in a written quote |
| Infrastructure | Your cloud accounts or data centers for the servers, load balancers and backups, sized by you | Same infrastructure footprint, since OEL builds are drop-in replacements for open source installations |
| Database | Your own PostgreSQL, MySQL, CockroachDB or SQLite (SQLite is for evaluation), with licensing and hosting you arrange | Same database choice and cost, carried by you |
| Upgrade and maintenance staff time | Your team plans and runs each upgrade, including planned downtime, which Ory accepts for open source deployments | Same upgrade work, with Ory's drop-in builds reducing the rework; confirm how much downtime is expected in the support terms |
| Patching and CVE response | Your team watches releases and applies fixes on your own timetable, with no guaranteed CVE patch SLA | Ory provides timely CVE patches under the license; confirm the SLA wording and response windows in writing |
| Monitoring and on-call | Your team builds and staffs monitoring, alerting and incident response | Same internal duties, plus access to 24/7 support SLAs; confirm coverage hours and escalation paths |
| Custom login UI | Your team builds and maintains the login and registration UI on top of the headless APIs | Same build and maintenance work for the UI, since OEL does not replace it |
| Enterprise features (SCIM, SAML, organization login, Kratos multi-tenancy) | Not available in the open source servers, so you build or buy alternatives | Included under the license; ask Ory which features are in scope for your contract |
Moving from open source to the Enterprise License, and back
This sequence shows a team how to move a running Ory deployment from Apache-2.0 servers to the self-hosted Ory Enterprise License, and how to return if the requirement goes away. Each step ends with a check the team can record, so the change is verified rather than assumed.
Confirm the enterprise feature set needed
The identity owner and the security lead list the features the business needs, such as SCIM provisioning, SAML, organization-level login, Kratos multi-tenancy or the Hydra ROPC grant, and the patching commitments they require. Compare that list against the features the Ory Kratos README names as enterprise-only and the features the Ory Enterprise License documentation describes. The output is a written requirement list signed off by the owner, which becomes the acceptance test for later steps. Ask Ory to confirm in writing which named features are included in the license you are considering.
Obtain the Enterprise License build
Your team requests the Ory Enterprise License from Ory and receives access to the optimized builds of the same servers. Procurement records the license terms, the support scope and who at your organization may download and deploy the builds. Confirm with Ory which versions of Kratos, Hydra, Keto and Oathkeeper are covered, and which release channel and support window apply. The step is complete when the license is on file and the build artifacts are available to the platform team.
Back up configuration, data and database
Before any binary changes, the platform team takes a full backup of the database used by Kratos or Hydra, along with the configuration files, secrets and any identity schemas. Store the backup outside the running environment and test a restore in a staging copy. This step matters because the upgrade path must be reversible if verification fails. The step is complete when a restore in staging has been tested and the team has written down the exact version currently running.
Swap in the drop-in replacement in staging
The platform team replaces the open source binaries or container images in a staging environment with the OEL builds, keeping the same configuration and database. Ory describes OEL builds as drop-in replacements for open source installations, so the expected change is the artifact, not the architecture. Confirm with Ory whether any configuration keys differ for enterprise features before starting the services. The step is complete when all services start cleanly and report the expected versions in their logs.
Verify SCIM, SAML and organization configuration
The identity team enables each enterprise feature in staging and tests it against the requirement list from the first step. For SCIM, they confirm that a directory sync creates, updates and deactivates a test user. For SAML and organization login, they confirm that a test organization can authenticate through its configured identity provider. For Kratos multi-tenancy, they confirm that identities stay isolated between organizations. The step is complete when every item on the requirement list has a recorded test result.
Retest login and recovery flows
The application team runs the full set of login, registration, recovery, MFA enrollment and logout flows against the staging deployment, including any custom login UI built on the Kratos APIs. They also check token issuance and refresh through Hydra for each client application. Any failing flow is logged and traced to either configuration or the build before promotion. The step is complete when all critical flows pass in staging and the results are attached to the change record.
Promote to production with a rollback plan
After staging sign-off, the team schedules the production change, keeping the rollback backup and the previous binary version ready. Ory states that open source is acceptable where occasional upgrade downtime is tolerable, so the change window and the affected user communication should be agreed in advance with the business owner. Confirm with Ory what downtime, if any, to expect for your specific versions. The step is complete when production runs the OEL build and the post-change checks match the staging results.
Reverse to open source if needed
If the enterprise requirement lapses, the team returns to the Apache-2.0 servers by reinstalling the open source binaries against the same configuration and database. Before doing this, confirm with Ory whether any database schema changes or enterprise-only settings made while on the license will be accepted by the open source build, because a reverse path can fail on compatibility rather than code. The step is complete when the open source build is running, the login flows pass the staging test set again, and the team has recorded which enterprise features are no longer active.
Questions buyers ask before choosing an Ory edition
What does the Ory Enterprise License cost and what drives the quote?
No price is published for the Ory Enterprise License in the sources we rely on, so ask Ory for a written quote tied to your deployment. The license fee is paid to Ory, while DeployOpen is paid separately for scoping, implementation and support work under a written scope. Quotes usually move with the number of Ory servers in use (Kratos, Hydra, Keto, Oathkeeper, Polis), which enterprise features you need (SCIM, SAML, organization login, Kratos multi-tenancy, the Hydra ROPC grant), the support level you choose, and how many environments you run. Ask whether the fee is one-time or recurring, and what happens at renewal.
How long does a move from open source to the Enterprise License take?
The move length depends on how your Ory deployment is configured and how much testing your change process requires. Ory describes OEL builds as drop-in replacements for open source installations, which suggests the binary swap itself can be small, but you still need to confirm version compatibility, configuration, and any features you enable after the switch. Ask Ory for its documented upgrade steps for your version, then ask DeployOpen for a fixed-scope plan that covers staging validation, cutover and rollback. Any timeline should come from that written scope rather than from a general estimate.
Can an internal team run Ory open source on its own?
Yes, many teams do, provided their requirements match what Ory says open source is for. Ory describes Ory Open Source as a good fit for evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. If you run production logins for regulated users, you will need a patching process you can execute on your own schedule, a tested backup and restore path, and staff who can review Ory release notes. Confirm whether your team can meet those duties before you choose open source for a customer-facing system.
What skills do identity and platform staff need to run Ory?
Your team needs people who understand OAuth 2.0 and OpenID Connect flows, can design a headless login UI on top of Kratos, and can operate a SQL database used by Kratos (SQLite, PostgreSQL, MySQL or CockroachDB, per Ory's documentation). Platform engineers should own deployment, secrets handling, monitoring and certificate rotation. Security staff should own the policy around sessions, multi-factor authentication such as TOTP, and the permission model if you use Keto. Ask DeployOpen to document which of these roles it would cover in a fixed-scope engagement and which would remain with your staff.
Can SCIM and SAML be added to Ory open source later?
Ory's Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as enterprise features that are not in the open source version. Adding them later means moving to the Ory Enterprise License, so the decision is an edition change rather than a code change you make yourself. Before you build around open source, list the SCIM provisioning and SAML federation you expect to need in the next few years. Ask Ory which of those features ship in the OEL build for your version, and ask DeployOpen to plan the integration work, including any changes to your identity sources and application configuration.
When does Ory Network change the answer to self-hosting?
Ory Network is Ory's managed cloud service, offered alongside the self-hosted open source components and the Ory Enterprise License, so it changes who runs the platform rather than which features exist. It becomes the stronger option when your team does not want to own database operations, upgrades and patching, or when hosting identity data in your own infrastructure is not a requirement. Keep identity data in your own infrastructure when data residency, air-gapped operation or internal control rules demand it. Compare the Ory Network and self-hosted options against your own requirements, and see the sibling comparison of Ory Network against self-hosted Ory for the operational tradeoffs.
What does DeployOpen do for an Ory edition decision?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which includes Ory deployments. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen can help you map your requirements to open source or the Ory Enterprise License, plan the work, and run the implementation, while the license itself is purchased from Ory. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so request a written scope and quote to see what your environment requires.
Where DeployOpen fits in an Ory edition decision
DeployOpen works on the implementation side of this decision, whichever Ory edition you choose. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Ory deployment, that means the work around Kratos, Hydra, Keto, Oathkeeper and Polis: database provisioning, login UI integration, OAuth2 client registration, network placement, backup and restore procedures, and the upgrade runbooks that matter most under the open-source path, where upgrades may require downtime. DeployOpen does not sell or resell Ory licenses, and it does not hold partner or reseller status with Ory unless that is stated on a supplied fact. Confirm any vendor relationship directly with Ory before you assume one exists.
Scope and cost follow from a written scope, not from a list price. Most DeployOpen engagements are fixed-scope, so the deliverables and timelines are agreed in writing before work starts. For an Ory decision, ask the quote to separate the components you will run, the number of identity flows and integrations, the database and backup design, and the upgrade and CVE response model you need. The licence cost of the Ory Enterprise License is a separate line that Ory quotes, and the implementation effort is a separate line that DeployOpen scopes. Ask each party to state which items are one-time (initial build, integration, hardening) and which recur (retainers for support, upgrades and continuous testing, and Ory's own subscription). Ask whether the same statement of work can be reused if you later move from open source to the enterprise build, since the OEL builds are described as drop-in replacements for open-source installations.
Confirm the edition boundary in writing before the statement of work is signed. Ask Ory which features your integration depends on, such as SCIM, SAML, organization login or Kratos multi-tenancy, and whether the Hydra ROPC grant is needed. Ask DeployOpen to show, in the scope, how each of those features will be configured, tested and documented in your environment. Ask for the CVE patching commitment in writing, and confirm how your own change window will absorb upgrades. If the answer to any of these is unclear, treat the edition decision as open and resolve it first, since the engagement scope depends on it.
How DeployOpen scopes and supports either Ory edition
This sequence turns an Ory open source or Enterprise License decision into a written scope, a tested integration with your identity sources, and a documented system that either you or a retainer can keep running. Each step ends with an artifact you can check before the next one starts.
Confirm the edition fit and requirements
Before any work is scoped, DeployOpen reviews your requirements against the edition boundaries: whether you need SCIM, SAML, organization login, Kratos multi-tenancy, the Hydra ROPC grant, or 24/7 support and timely CVE patches. Ory's own guidance says Apache-2.0 open source suits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. The output is a short written fit note that records the edition choice, the reasons for it and the items you must confirm directly with Ory, such as current feature availability and license terms.
Agree a fixed written scope
Most engagements are fixed-scope, so the deliverables, the systems in scope, the target infrastructure (your cloud account, data center or air-gapped network), the components (Kratos, Hydra, Keto, Oathkeeper, Polis) and the acceptance criteria are agreed in writing before work starts. Your security, identity and platform leads sign off on the scope document, and DeployOpen issues a quote that follows from that written scope. The check is a signed scope that names every component and integration, so no one discovers a missing item during build.
Map identity sources and integrations
DeployOpen inventories the identity sources the Ory stack must work with, such as existing user directories, HR-driven account lifecycles, social or passkey sign-in, and the applications that consume tokens. For each source it defines how users are created, updated and deprovisioned, and whether that happens through Polis SCIM directory sync on the Enterprise License or through your own provisioning code on open source. Your identity team confirms the mapping. The output is an integration map that shows every login path and every account lifecycle event.
Build and configure the deployment
DeployOpen deploys the chosen Ory servers into your infrastructure, configures the database backend that each component supports (Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB) and connects Hydra to your login and consent flows through its headless APIs. Where the Enterprise License is chosen, the optimized builds are installed in place of the open source servers, which Ory describes as drop-in replacements. The check is a working test environment in which each login flow, token issuance and authorization decision matches the scope.
Harden and test the identity flows
DeployOpen applies hardening to the deployment, including the configuration of multi-factor methods such as TOTP, passkeys and session settings, and tests the identity and token flows against the acceptance criteria from the scope. Where security testing is in scope, the same team can run application and API testing against the Ory endpoints. The output is a test record that lists each acceptance criterion, its result and any open findings with an owner for each one.
Document operations and evidence
DeployOpen writes the operating documentation: deployment architecture, configuration baselines, backup and restore procedures, upgrade steps, and the runbook for handling CVE advisories on your chosen edition. For compliance readiness, it also assembles the control evidence your assessor will ask for. DeployOpen prepares that evidence but does not issue audit reports or certifications, which independent auditors and certification bodies provide. The check is a handover pack that your own staff can use without the implementation team present.
Hand over and choose ongoing support
Your team takes over operation with a handover session and a walkthrough of the runbooks. If you want continued help, DeployOpen offers retainers that cover ongoing support, upgrades and continuous testing, and the retainer scope is agreed separately in writing. Ask for the upgrade approach and the patching process in any retainer, and confirm with Ory which support terms apply to your edition. The output is a signed handover record and, where chosen, an agreed retainer scope.
