Self-hosted identity operations: beyond the login server

Plan self-hosted identity operations around the complete access lifecycle—not just the login server. Define how user journeys should work, which state must be recoverable, how changes will be controlled, and who responds when authentication or authorization fails.

Ory’s component boundaries offer a useful way to organize that work. Use them to assign responsibilities, then validate the behavior of your actual deployment.

Separate identity, protocols, and permissions

Ory’s Network documentation describes three service roles and the open-source projects behind them:

Responsibility	Documented Ory foundation	Operational question
Identity and user management	Kratos underpins Ory’s identity service.	Who owns account data, authentication flows, sessions, and recovery?
OAuth 2.0 and OpenID Connect	Hydra underpins Ory’s OAuth2 and OpenID Connect service.	Who owns protocol integration and application-client configuration?
Application permissions	Keto underpins Ory’s permissions service.	Who owns permission models, relationships, and access decisions?

Use these boundaries to define ownership, not as a requirement to deploy all three projects.

For example, Ory describes its Network OAuth2 and OpenID Connect service as a headless API that connects to Ory Identities by default but does not require a particular user-management system. That distinction provides a useful boundary between account management and protocol integration. Ory Hydra introduction

Keep deployment models separate. Do not assume that Network’s default integrations or hosted interfaces describe a self-hosted installation. Document the interfaces and integrations you will deploy, and verify their requirements for the releases you select.

Test complete user journeys, not just service health

Ory’s identity introduction documents registration, login, recovery, account-management, and session-management features. It also distinguishes identity workflows from interface rendering: the identity service has no HTML rendering engine, while Ory Network offers the Ory Account Experience. Ory Kratos introduction

Make your application and its interface part of acceptance testing. Do not use a successful API health check as the sole readiness criterion.

For each enabled journey, define an expected outcome and a representative failure case:

• Registration: Complete account creation through the application, including verification where configured. Test interrupted and repeated submissions.
• Login: Reach the intended application after authentication. Test rejected credentials and unavailable dependencies.
• Recovery: Complete the configured recovery path with a test account. Confirm that expired or invalid recovery material is rejected.
• Account changes: Exercise supported password, address, or profile changes. Verify that the application reflects the intended result.
• Logout and access removal: Exercise configured logout and access-removal paths. Verify that the application rejects further access as intended, testing session and token paths separately where present.
• Permissions: Check an allowed action and a denied action through the application—not only through a permissions API.

Use dedicated test identities with tightly limited privileges. Where a journey depends on message delivery, an external identity provider, or another service, include that dependency in the test and assign an owner for failures.

Make database recovery part of the identity design

Ory’s Kratos introduction lists SQLite, PostgreSQL, MySQL, and CockroachDB as supported databases for self-hosting. Before deployment, verify database and version support, along with production deployment guidance, for the server release you select. Do not treat the introductory list as evidence of equal suitability for your workload. Ory Kratos introduction

Treat durability as a concrete recovery exercise:

1. Set recovery targets. Decide how much lost state is acceptable and how long recovery may take.
2. Inventory recovery inputs. Include database state, configuration, identity schemas, permission models where used, deployed versions, and required secrets or keys.
3. Protect recovery material. Encrypt backups and restrict access. Establish an authorized recovery path for required secrets without placing their values in ordinary documentation.
4. Restore in isolation. Use an environment that cannot accidentally send production messages or expose restored accounts to normal traffic.
5. Validate behavior. Run the authentication, recovery, and permission tests used for release acceptance.

For systems with separate application, identity, and permissions stores, test how the restored states relate to one another. Include a restored account whose application record or group membership differs from the intended recovery point. Also test a case where access was removed after the selected backup, and define how to reconcile that removal before reopening traffic.

Record elapsed recovery time and discrepancies. Use the exercise—not merely the existence of backup files—to assess readiness.

Treat upgrades as state changes

Use a release checklist that covers more than replacing a container or binary:

• Pin the versions deployed to each environment.
• Review release-specific compatibility and migration instructions.
• Rehearse changes against representative, appropriately protected data.
• Run end-to-end journey tests before and after the change.
• Define stop conditions and a recovery path before production work begins.

Do not assume that reverting an executable will reverse a database migration. Establish whether recovery requires an application rollback, a database restore, a forward correction, or another release-supported procedure.

Apply similar discipline to identity-schema and permission-model changes. Ory’s Keto introduction describes fine-grained permissions and inheritance through groups, roles, and hierarchies. For a model using those relationships, test direct and inherited access, including expected denials after membership or relationship changes. Ory Keto introduction

Give secrets and privileged access explicit owners

Inventory sensitive credentials and keys used by the deployment. Depending on your architecture, include database credentials, application-client secrets, message-delivery credentials, and cryptographic keys.

For each item, record its owner, storage location, authorized consumers, and replacement procedure—never its value—in the operating documentation. Restrict administrative interfaces and credentials separately from normal application access.

Before rotation, verify the component’s documented behavior. Test what happens to existing sessions, tokens, and dependent applications rather than assuming that old and new material can overlap safely. Give emergency replacement its own procedure, including how operators regain authorized administrative access.

Monitor outcomes and prepare for access incidents

Organize monitoring around whether people and applications can complete intended actions. Track journey success and failure, latency, and dependency errors. Track permission decisions separately from errors that prevent a decision. Keep passwords, tokens, recovery codes, and session cookies out of routine logs.

Define application behavior when an access check cannot be completed. Keep an infrastructure error distinguishable from an explicit denial, and do not silently turn either into an allow decision.

Prepare separate response paths for:

• Availability failures: Users cannot sign in or complete recovery.
• Integrity failures: Account data or permission relationships are unexpectedly changed.
• Suspected compromise: Credentials, sessions, signing material, or privileged access may be exposed.

Assign incident ownership, escalation routes, containment options, and post-recovery validation for each path. Use access-controlled operational identifiers for troubleshooting rather than collecting authentication material.

The practical acceptance criterion is straightforward: demonstrate that intended user journeys work, unauthorized actions remain denied, and the team can restore those outcomes after a failed change or an incident.