Which Ory hosting model fits your identity team
If identity data must stay inside your own cloud accounts, data centers or air-gapped network, self-hosted Ory is the only option of the two. If your constraints are mainly in-house operations capacity and fast access to CVE patches, Ory Network carries more of the operating load. Ory's own guidance is that the Apache-2.0 open source servers suit evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Teams that need guaranteed patching, 24/7 support and enterprise features such as Kratos multi-tenancy and organizations should look at the Ory Enterprise License, which is Ory's commercially supported self-hosted path and is described as drop-in compatible with open source installations.
Start with four questions. First, where must Kratos identities and Hydra OAuth2 client data physically sit, and does any regulator or customer contract restrict that? Second, can your team run upgrades of Kratos, Hydra and Keto, including database migrations, with a maintenance window? Third, who will apply security releases within the timeframe your risk process requires? Fourth, which enterprise features do you need, such as SCIM, SAML, organization login or multi-tenancy? Ask Ory to confirm in writing which of these are included in Ory Network and which need the Enterprise License, and ask how each Ory Network tier handles data location and CVE response. Those answers, not the product names, should decide the model.
Be realistic about the cost of self-hosting. You pay for infrastructure, a supported relational database (Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB, and SQLite is for development rather than production), monitoring, backups and the people who run upgrades. With the Enterprise License, you also pay Ory for the license and support. Ory Network replaces most of that with a subscription, which is usually the lower operating load, but you accept Ory's hosting location, upgrade schedule and contract terms. If you go that route, confirm the data region, backup and restore commitments, and exit terms before you commit, and see Ory pricing for the current plan structure.
Ory Network and self-hosted Ory compared on the factors that matter
This table sets Ory Network, the managed cloud service, against running the Apache-2.0 Kratos, Hydra and Keto servers yourself, and against the self-hosted Ory Enterprise License. Read each row as a question to put to Ory and to your own team. The main takeaway is that the decision turns on where identity data must live, who carries patching and upgrade work, and which enterprise features you need.
| Factor | Ory Network (managed) | Self-hosted Ory (open source or OEL) |
|---|---|---|
| Control and data location | Ory operates the service. Confirm with Ory where identity data is stored and which regions are available. | Identity data stays in your cloud account, data center or air-gapped network, under your own controls. |
| Supported databases | Confirm with Ory which database backends apply to the managed service. | Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB. Choose the database you can back up, restore and patch. |
| Licensing and editions | Offered alongside the self-hosted open source components and the Ory Enterprise License. Terms are set in the Ory pricing page. | Kratos, Hydra, Keto, Oathkeeper and Polis are Apache-2.0. The Ory Enterprise License adds optimized builds of the same servers. |
| Enterprise features | Confirm with Ory which features (SCIM, SAML, organization login, Kratos multi-tenancy, Hydra ROPC grant) are included in your plan. | The Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features not in open source. The OEL adds multi-tenancy, organizations and the Hydra ROPC grant. |
| Support and CVE patch commitments | Ask Ory for written support hours, response targets and patch timing for the managed service. | Open source carries no guaranteed CVE patching. The OEL includes 24/7 support SLAs and timely CVE patches, per Ory's documentation. |
| Upgrade downtime | Ory handles upgrades of the managed service. Ask how maintenance windows and tenant notice are handled. | Ory says open source fits deployments where occasional upgrade downtime is acceptable. Plan maintenance windows and rollback steps yourself. |
| Patching and operations duties | Largely with Ory for the service. Your team still owns the integration, login flows and client configuration. | Your team or DeployOpen owns OS, database, container and Ory server patching, backups and monitoring. |
| Cost structure | Recurring, based on the plan you choose. See the Ory pricing page for current figures. Confirm what usage limits apply. | Software is free under Apache-2.0 for open source. Recurring costs are infrastructure, staff time and any OEL subscription. Quotes depend on the written scope. |
Where identity data lives and what compliance teams must prove
Choosing between Ory Network and self-hosted Ory is partly a question of where identity records sit, who can reach them and what evidence an assessor can inspect. The four cards below cover those decisions in parallel, so each can be checked against the contract, the architecture and your own control set before a platform is chosen.
Data location and residency
Identity records include user profiles, credentials, sessions and, in Kratos, the verification and recovery data tied to them. With self-hosted Ory, the database engine and the server location are your choice: Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB, so you decide which region and which network zone hold that data. With Ory Network, ask Ory which hosting regions apply to your tenant, whether backups stay in those regions, and where support staff can access data from. Get the answers in writing before you sign.
Administrative access and key control
Whoever runs the identity servers can read configuration, rotate signing keys and change how logins are verified. In a self-hosted deployment, your team holds those administrative credentials and the keys for Hydra's token signing, and it decides who gets privileged access. In a managed deployment, Ory administers the platform, so you need to confirm which administrative actions Ory staff can perform, how your team's own administrators are scoped, and how you would revoke access or export your configuration if the relationship ended.
Audit evidence for assessors
An assessor will ask for proof that access to identity data is logged, reviewed and limited to approved people. Self-hosted Ory means you collect those logs from your own servers and database, and you own retention, tamper protection and the review record. Under a managed service, check which audit logs the platform exposes to you, how long they are kept, whether you can export them into your own SIEM and whether the log set covers the administrative actions an assessor is likely to sample. DeployOpen can prepare the controls and evidence, but it does not issue audit reports or certifications.
Shared responsibility under a managed service
A managed service moves some duties to the vendor and leaves others with you. Ory Network runs the hosted service, while your team typically still owns user lifecycle, application integration, access reviews and the policy that defines who may sign in. Self-hosted Ory also divides duties, but you take on upgrades, patching and backups directly. Write a responsibility matrix that lists each control, the party that performs it and the evidence each party provides, and confirm the matrix against Ory's own service terms and security documentation.
Confirming hosting and certifications
Hosting regions, subprocessors and third-party certifications change over time and are set by the vendor, not by this comparison. Ask Ory for its current hosting locations, its list of subprocessors and any independent reports or certifications it holds, and confirm the scope and date of each one. Ask whether those reports cover Ory Network specifically or only the open source software, and whether they are available to your assessor under a non-disclosure agreement. Record the answers in your third-party risk file.
How Kratos, Hydra and Keto fit together in a self-hosted deployment
Kratos, Hydra and Keto each own a different question, and a self-hosted deployment is only as clear as the boundaries between them. Ory Kratos manages identities and login flows through headless APIs: registration, login, recovery, verification and multi-factor steps such as TOTP. Ory Hydra issues OAuth 2.0 and OpenID Connect tokens and integrates with your existing user system rather than holding the user store itself. Ory Keto answers permission questions using a Zanzibar-style model that supports ACL and RBAC. Your application asks Keto whether a subject may act on a resource; Kratos and Hydra do not make that decision for you.
In a self-hosted model, your team owns the parts Ory does not supply. You build the login and registration UI that calls the Kratos flow APIs, and you decide how sessions, consent screens and logout pages are presented. You operate the databases behind Kratos, Hydra and Keto (Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB), along with backups, network placement, TLS, secrets and the upgrade sequence across three separately versioned services. You also write the code that maps Hydra consent and login challenges to your user store, and the authorization checks your services make against Keto. Under Ory Network, Ory operates the hosted services, so the boundary moves: your team still owns the login UI, consent logic, application authorization model and the data your application sends.
Before choosing a model, map each component to an owner and confirm three things with Ory in writing: which features in your design sit in the open source servers and which need the Ory Enterprise License, such as SCIM, SAML, organization login and Kratos multi-tenancy; which database and retention settings you need; and what upgrade and patching terms apply under each option. If identity data must stay inside your own cloud account, data center or air-gapped network, the self-hosted boundary is the one to design first, and the Keto permission model should be tested with your real resource hierarchy before the first login flow ships.
What your team runs in each model
With the Apache-2.0 servers (Kratos, Hydra, Keto, Oathkeeper and Polis), your team installs, runs and maintains every component inside its own cloud accounts, data centers or air-gapped network. Kratos documents SQLite, PostgreSQL, MySQL and CockroachDB as database options, so the engine choice and its operation fall to you. Ory describes open source as a good fit for evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not a requirement, which sets the operating bar for this model.
- Database operation: You provision, tune, back up and fail over the chosen engine. Confirm with Ory which engine it expects for production before you commit.
- Upgrades: Plan each Kratos, Hydra and Keto upgrade as a maintenance window that includes schema migrations. Ory's own guidance accepts occasional downtime for this model.
- Patching and CVE response: Your security team watches advisories, tests fixes and deploys them. No vendor response timeline applies to open source.
- Backups and monitoring: Define backup scope across identity records, OAuth client configuration and any Keto permission data. Schedule restore tests, and alert on login and token endpoint health.
- On-call: Identity outages page your rota. Decide who owns the Hydra token path and who is called at night.
Before you choose this model, confirm that your team can staff an upgrade window and a CVE response without a vendor timeline behind them.
The Ory Enterprise License keeps the hosting model in your infrastructure but changes what you receive. OEL builds are optimized builds of the same open source servers and are described as drop-in replacements for open source installations. The license adds enterprise features such as Kratos multi-tenancy and organizations, the Hydra ROPC grant, and, according to the Kratos README, SCIM, SAML, organization login and CAPTCHAs. It also bundles 24/7 support SLAs and timely CVE patches. Your team still runs the infrastructure, so the operating load shifts in some areas and stays in others.
- Database operation: You still run the engine and its backups. Confirm in the license terms which engines are covered for your deployment.
- Upgrades: Because OEL builds are drop-in replacements for open source installations, migration planning stays close to the open source path. Confirm the upgrade procedure and any downtime expectations in writing.
- Patching and CVE response: Ory supplies timely CVE patches under the license. Your team still applies them in its environment and owns the change window.
- Support: The 24/7 support SLAs are contractual. Ask for severity definitions, response targets and escalation paths in the agreement.
- Backups and monitoring: These duties stay with your team. The license does not transfer data protection or observability work to Ory.
Ask Ory for the SLA text, the patch delivery method and the supported engines in writing before you assume the operating load drops.
Ory Network is Ory's managed cloud service, offered alongside the self-hosted open source components and the Enterprise License. Identity data and the servers run in Ory's hosted environment, so hosting, upgrades and patching move to Ory under the service agreement. Your team's work shifts toward configuration, integration with your applications, and vendor management. The specifics of database engines, upgrade windows, backup retention and monitoring access depend on the service terms, so treat them as open questions for the contract rather than assumptions.
- Database operation: Ask which engines and regions hold your identity data, and whether you can export it on request.
- Upgrades: Ask how releases roll out, whether downtime windows exist, and how you receive notice before a change.
- Patching and CVE response: Ask whether patch timing is written into the agreement and how Ory reports that patches have been applied.
- Backups and monitoring: Ask for backup frequency, restore testing results, and which logs and metrics you can access from your own tooling.
- On-call: Clarify who responds to a login outage, and how escalation runs between your security team and Ory.
Put these answers in writing and confirm whether identity data can leave the service, since that decides how easily you could move to another model later.
Moving identity data between Ory Network and self-hosted Ory
This sequence moves identity schemas, identities, credentials and login and token traffic in either direction with a known cutover point and a verified rollback path. It ends with the old environment decommissioned only after both sides have been checked against the same test flows.
Inventory schemas, flows and integrations
Before any data moves, list every identity schema, login, registration, recovery and verification flow, and each application that calls Kratos or Hydra for login, consent or token issuance. Include custom traits, hooks, webhooks, social sign-in providers, MFA methods in use and any Keto permission models. Your team and the Ory side should both sign this inventory off, because it defines what the migration must reproduce. Done when every flow and client has an owner and a documented target behavior in the destination.
Confirm portability of hashes and MFA secrets
Before scoping the export, ask Ory in writing whether password hashes and MFA secrets such as TOTP seeds can be exported from the source and imported into the destination, and under which hashing algorithms and formats. Ask whether passkeys, social account links and recovery codes move with identities. If any of these cannot move, record which users will need to re-enroll and how that affects your support load. Done when the answer for each credential type is documented and accepted in the written plan.
Agree the fixed-scope migration plan
Write down the scope in a fixed-scope plan before work starts: which identity populations move, which applications cut over, what deliverables and checks are included, and what is out of scope. DeployOpen typically agrees scope, deliverables and timelines in writing before work starts, and a quote follows from that scope. Ask any implementation partner to name who runs the export, who owns the import, and who signs off the cutover. Done when all parties have signed the plan and the rollback owner is named.
Export and import identities and credentials
Export identities, traits, verified contact addresses and credentials from the source using the supported export path for that deployment, then import them into the destination in a staging environment first. Compare record counts, schema validation results and a sample of accounts across both sides, checking that a test user can sign in with each credential type that was promised to move. Keep the export files encrypted and access-controlled, since they contain personal data. Done when counts match, the sampled logins succeed, and the exceptions list is complete.
Validate Hydra clients and token behavior
Recreate OAuth2 clients, redirect URIs, scopes, consent settings and signing configuration in the destination, then run token issuance, refresh and revocation tests against each relying application. Confirm that issuer URLs, JWKS endpoints and token lifetimes match what the applications expect, since a mismatch breaks sessions after cutover. Keep a record of the test cases and results. Done when every client completes the agreed test flows and the issuer change is listed in the cutover runbook.
Cut over login and token endpoints
Schedule the cutover in a change window agreed in the plan. Move DNS or gateway routing for login and token endpoints, freeze identity writes on the source during the final sync, and run a final delta import for changes made since the earlier export. Confirm that applications resolve the new endpoints and that sign-in, consent and token refresh succeed for test accounts. Done when production traffic is served by the destination and the rollback procedure has been rehearsed.
Run both sides in parallel
Keep the source available in read-only or fallback mode for a period set in the plan, while monitoring sign-in success rates, token errors and support tickets on the destination. Reconcile any identity change made on either side, and watch for users who cannot complete MFA or recovery. Decide in advance which metrics trigger rollback. Done when the agreed monitoring window closes with no open identity discrepancies and the rollback trigger was not met.
Decommission the old environment
Once the parallel run closes, revoke application secrets still pointing at the source, remove its routing entries, and archive the final export and audit logs under your retention policy. Delete any staged copies of identity data from working storage, and record the date and the person who approved each step. Done when the source has no live traffic, its data is archived or destroyed as the plan specifies, and the decommission record is filed with the change records.
When keeping identity data in your own infrastructure is the right call
Keep Kratos identity data in your own infrastructure when a regulator, contract or internal policy says the user records, credentials and session data must stay in a named region, network or account that you control. Ory Network is a managed cloud service, so the first check is the data residency and network placement it offers for your workload, which you should confirm in writing with Ory before you rule it in or out. Self-hosted Kratos, Hydra and Keto run in your cloud accounts, data centers or air-gapped networks, and you choose the database behind them. Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB, so the database region, backup location and encryption keys are decisions your team makes and can audit directly.
The same logic applies to logs and keys. If your security team must control where authentication logs go, how long they are kept and who can read them, self-hosting gives you direct access to those streams. It also keeps signing and encryption key custody under your own key management process. Air-gapped and sovereign deployments are the clearest cases, because a managed control plane outside the enclave is not an option. For data platform integration, self-hosting lets identity events flow into your existing warehouse, SIEM or access review tooling without crossing an external boundary. Confirm with Ory which of these hooks the Network exposes before assuming parity.
Self-hosting has a cost that the managed option removes. Your team owns patching, backups, restore testing, uptime and upgrades for every component, and Ory's own guidance says open source suits deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. If you need guaranteed CVE patch timing, you would look at the Ory Enterprise License, which is a separate decision. Teams without a platform or security operations group that can carry these duties around the clock may be better served by Ory Network, provided its data location and log access meet the requirements above. Write the operating model down before choosing: who patches within your policy window, who tests restores, and who is on call for identity outages.
Questions buyers ask before choosing Ory Network or self-hosted Ory
How does self-hosting Ory cost compare with Ory Network pricing?
Ory Network is a managed cloud service, so its cost is set by Ory's commercial terms, and you should read the current tiers on the Ory pricing page rather than rely on any figure from a third party. Self-hosted Ory has no license fee for the Apache-2.0 servers, but it moves cost into your own infrastructure and staff: compute and database hosting, backups, monitoring, upgrades, patching and on-call coverage. If you need the Ory Enterprise License, that is an additional commercial agreement. When you request a quote from DeployOpen, ask for the written scope to list each one-time item (design, integration, hardening, migration) separately from recurring items (retainers for upgrades, patch handling and continuous testing), and ask which parts are your own staff time.
How long does a self-hosted Ory rollout take?
Timing depends on how many of the Kratos, Hydra and Keto components you deploy, how many login flows and client applications you integrate, your database choice and how much custom login UI you build. Ory's documentation does not give a standard duration for these steps, so no figure is quoted here. DeployOpen timelines are not estimated in general terms: they come from the written scope, which is agreed before work starts and lists deliverables and milestones. Ask any implementation partner, DeployOpen included, to break the timeline into design, build, integration, testing and cutover, and to name which tasks depend on your own team's availability.
What does the work need from our internal team?
Running self-hosted Ory means owning the stack after go-live. Your team needs people who can operate PostgreSQL, MySQL, CockroachDB or SQLite as Kratos supports them, manage secrets and TLS, deploy and roll back new releases, and read Ory's changelogs before each upgrade. Someone must also build or maintain the login experience, since Kratos is API-first and you supply the UI, and own the client registrations and policies in Hydra and Keto. Ask the partner which runbooks, handover sessions and documentation are part of the scope, and which skills your staff must have before the engagement ends.
Can our team run self-hosted Ory alone?
A team with strong platform engineering and identity skills can run the open source servers alone, provided it accepts the trade-offs Ory itself describes: occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. If your environment needs predictable patch timing or formal support commitments, the team has to plan for that work. Many organizations split the job, keeping day-to-day operations in-house and using a partner for design, hardening, upgrade reviews or security testing on a retainer. DeployOpen operates this way: it plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside the client's own infrastructure, under written scope.
Do enterprise features require the Ory Enterprise License?
Yes, for the features Ory names as enterprise. The Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as not available in the open source version. The Ory Enterprise License documentation adds Kratos multi-tenancy and organizations, the Hydra ROPC grant, 24/7 support SLAs and timely CVE patches. Ory describes OEL builds as optimized versions of the same open source servers and drop-in replacements for open source installations. Ask Ory which features your use case needs, because some capabilities may also be available through Ory Network, and confirm current availability for each deployment model in writing.
How do we migrate between Ory Network and self-hosted Ory?
Migration is the step most teams underestimate, because identity data, password hashes, sessions, OAuth clients, signing keys and permission tuples all need to move with the correct configuration. Before you commit, confirm with Ory which export and import paths exist for each component and which data types they cover, and test the move in a non-production environment. Ask for a written plan that covers user cutover, session handling, rollback and how issuer URLs and redirect URIs change for each client application. Treat the migration scope as a separate line in any quote, since it depends on your user count, client count and integration complexity.
What compliance evidence does each model produce?
Neither model produces an audit report, attestation or certification by itself. Self-hosting gives you direct control over logs, access reviews, backups, change records and configuration, so your own evidence can be as complete as your processes make it. Ory Network shifts some operational controls to Ory, so you need its contractual and security documentation to show what the provider covers. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the reports. Ask each vendor which evidence it provides and which controls remain your responsibility, and confirm the framework mapping with your assessor before the engagement starts.
How DeployOpen scopes, delivers and supports self-hosted Ory
DeployOpen plans, implements, 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 Ory, that means working through whether identity data should stay in your infrastructure before any installation begins, then building and documenting the chosen deployment to your written scope.
How we scope
- We start by confirming which Ory components you need, such as Kratos, Hydra or Keto, and which features they must support.
- Engagements are fixed-scope, with deliverables, timelines and responsibilities agreed in writing before work starts.
- The written scope records where identity data will live, which database you will run, and who owns upgrades and patching.
How we build
- We plan and implement the self-hosted deployment inside your own cloud accounts, data centers or air-gapped networks.
- We integrate Kratos, Hydra and Keto with your existing user management systems, login pages and applications.
- We harden the deployment and run security testing of the login flows and APIs before it reaches production.
How we hand over
- We document the architecture, configuration, backup and upgrade procedures so your own team can operate the system.
- We prepare the controls and evidence your compliance assessors will ask for, without issuing any audit or certification.
- We walk your operators through runbooks for patching, upgrade downtime windows and recovery before handover closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
- A retainer can cover routine Ory upgrades and patch application, which you should confirm against your own patch obligations.
- Any Ory Enterprise License or Ory Network commitments remain between you and Ory, and we will confirm the scope before work begins.
