Ory Hydra

Last reviewed Aug 26, 2026 · 752 words

Ory Hydra will not log anyone in. It has no user table, no password form, no recovery flow, and no admin screen for people. It is a certified OAuth 2.0 and OpenID Connect token server that hands the "who are you" question to a login and consent app you write or bring. Read that twice before deploying, because a large share of people who install Hydra expecting an Auth0 replacement find the gap on day two.

Two ports, and one must never leave the host

Hydra listens on 4444 (public: /oauth2/auth, /oauth2/token, /userinfo, /.well-known/openid-configuration) and 4445 (admin: client management, token introspection, the endpoints that accept login and consent challenges). The admin API has no authentication of its own. Anything that reaches 4445 can create clients and approve logins, so it binds to the Docker network or localhost and is reachable only by your login app and your deploy scripts.

services:
  hydra:
    image: oryd/hydra:latest
    command: serve all --dev
    environment:
      - DSN=postgres://hydra:hydra@postgres:5432/hydra?sslmode=disable
      - URLS_SELF_ISSUER=https://auth.example.com
      - URLS_LOGIN=https://auth.example.com/login
      - URLS_CONSENT=https://auth.example.com/consent
      - SECRETS_SYSTEM=replace-with-openssl-rand-hex-32
    ports:
      - "4444:4444"
    depends_on:
      - postgres
    restart: unless-stopped

Run hydra migrate sql -e --yes against that DSN once before the first serve. The --dev flag relaxes the HTTPS requirement so a reverse proxy can terminate TLS in front; without a proxy, drop it. The Postgres database is the only state Hydra holds, so back that up and nothing else.

You will write the login screen

The flow: a client redirects to /oauth2/auth; Hydra redirects to URLS_LOGIN carrying a login_challenge; your app authenticates the user however it likes (LDAP, a users table, a passkey), calls the admin API on 4445 to accept the challenge; Hydra bounces through consent and back to the client with an authorization code. Ory publishes a reference login-consent app in Node that is fine for a proof of concept and stores nothing. This is where the Hard difficulty rating lives. The OAuth half is done for you; the identity half is your codebase. Budget a weekend for a minimal version with sessions and remember-me, and more if you want MFA.

Kratos is the missing half

Ory's own answer is Ory Kratos, which handles registration, passwords, recovery and MFA and has a supported integration where Kratos plays the login and consent role for Hydra. The pair gives you a complete OIDC provider with headless APIs and no vendor UI, at the price of 2 Go services, 2 Postgres schemas, and a self-service UI that is still yours to render. The other legitimate path is the original design intent: an application with 5,000 accounts in its own table bolts Hydra onto its existing login and starts issuing standards-compliant tokens without migrating a single identity.

Who this is actually for

Hydra suits people building a product or platform that must be an OAuth provider: a SaaS exposing an API to third-party apps, a company with an existing user store that needs certified token issuance, an integrator who wants zero opinions about UI. The footprint matches that job: 256 MB of RAM, horizontal scaling with nothing shared but the database, and a Go codebase that has been in production since 2015.

It does not suit putting single sign-on in front of a homelab. For that, Authentik ships users, groups, a login page, forward-auth for reverse proxies and an OIDC provider in one deployment; Keycloak does the same with a heavier Java footprint and broader enterprise protocol coverage. Either protects a first app in under an hour. Hydra plus a hand-written login app is closer to a week, and the SSO comparison covers the homelab options properly.

What I'd do

If the question is "how do I add SSO to my services", skip Hydra and deploy Authentik. If the question is "my application needs to be an OpenID provider for other people's software, and I already own the accounts", deploy Hydra behind a reverse proxy, keep 4445 off the network, pair it with Kratos unless a user store already exists, and treat the login app as a real project with tests and a backup plan. Inside its remit it is the most correct OAuth server you can self-host. Outside it, it is a specification with the front door missing.