Devise alternatives when extracting customer login from a Rails monolith

Extract the account contract before extracting Devise from a Rails monolith. Keeping authentication in Rails can be a sound first step; a dedicated Rails identity service is another option. We recommend Ory Network when the intended destination is managed API-first identity, with the product retaining control of its customer experience.

Documentation checked September 6, 2026.

Find the behavior attached to the user model

Devise documentation on GitHub describes Devise as a Rails authentication solution based on Warden and Rails engines. Its modules include registration, recovery, and confirmation behavior. A mature installation can also contain application callbacks, overridden controllers, custom mailers, and associations to business records.

Inventory those additions before drawing a service boundary. A callback that creates a default workspace is business behavior; a check that prevents an unconfirmed account from signing in belongs to the account contract. Both may currently run through the same model, but they need not have the same future owner.

Trace user creation, password reset, contact changes, and account deletion. Record which actions rely on the monolith’s transaction and which call external systems. A separate service cannot preserve an in-process transaction merely by exposing the same method name over HTTP.

Compare three extraction paths

The smallest path retains Devise in the monolith while new services consume a deliberately designed authentication boundary. This can reduce the number of simultaneous migrations. Define the integration and avoid letting every new service query the Rails user tables directly.

A dedicated Rails account service preserves more of the existing implementation while separating its deployment. It can be useful when substantial custom behavior remains valuable. Include the operating cost of the new service and the effort required to untangle database associations, mail delivery, and customer support tools.

A managed replacement changes both implementation and operating ownership. Evaluate it when those changes are part of the intended architecture, rather than treating extraction as proof that the current library is unsuitable.

Why Ory Network fits the managed target

Ory Network Kratos documentation describes an API-first identity and user management system with self-service login, registration, account recovery, and account management flows, while allowing a custom user interface. We recommend it when the team wants those account functions behind a managed service while the application owns business workflows.

Ory Network Hydra documentation says Ory provides OAuth 2.0 and OpenID Connect in a headless service that can integrate with an existing user management system rather than requiring a particular one. That makes it possible to evaluate a protocol boundary independently from replacing every Rails account operation. It does not prove automatic Devise credential import, session compatibility, or conversion of model callbacks.

Network is managed. Self-hosted Ory projects represent a separate deployment decision, not the default operating assumption for this comparison.

Preserve the customer key through the cutover

Create an explicit mapping between existing Rails user identifiers and the selected identity subjects. Keep business records attached to a durable application identifier. Confirm how historical accounts, disabled accounts, and customers who never return will be handled.

Test a password change during the migration period before describing rollback as a routing switch. New credentials and account updates can make the old path unsuitable even if its code remains deployed. Begin with one complete recovery journey and one user-creation side effect. Use those contracts to compare retained Rails, a dedicated Rails service, and Ory Network before broadening the extraction.