Logto

Last reviewed Aug 26, 2026 · 810 words

Logto is the wrong tool for putting a login page in front of Jellyfin, and the right one for the app you are writing yourself. It is an Auth0 or Clerk replacement: hosted sign-in pages, social and passwordless login, SDKs for a dozen frameworks, and a management API, all licensed MPL-2.0 with 14,463 GitHub stars. If your problem is "SSO for the services on my homelab", stop reading and go to Authentik. If your problem is "my side project needs accounts and I refuse to write password reset flows again", keep going.

Two ports, one Postgres, and a domain you must get right

Logto runs as a single Node process listening on 2 ports: 3001 for the core service (sign-in pages, OIDC endpoints, your users) and 3002 for the admin console. It needs PostgreSQL and nothing else; the 512 MB RAM floor in the catalogue is realistic for a small instance with a shared database. The minimum compose is short:

services:
  logto:
    image: svhd/logto:latest
    ports:
      - "3001:3001"
      - "3002:3002"
    environment:
      - DB_URL=postgres://logto:logto@postgres:5432/logto
      - ENDPOINT=https://auth.example.com
      - ADMIN_ENDPOINT=https://auth-admin.example.com
      - TRUST_PROXY_HEADER=1
    depends_on:
      - postgres
  postgres:
    image: postgres:16
    environment:
      - POSTGRES_USER=logto
      - POSTGRES_PASSWORD=logto
    volumes:
      - ./pg:/var/lib/postgresql/data

The trap is ENDPOINT. OIDC issuers are baked into every token and every SDK config, so changing the public URL later means reissuing everything. Decide the hostname on day 1, put both ports behind Caddy with 2 site blocks, and never expose 3002 to the internet at all; the admin console is yours alone.

Where it beats Authentik and Keycloak: developer time

The reason to pick Logto over the general-purpose identity servers is the shape of the work afterward. You create an application in the console, pick a type (SPA, traditional web, native, machine-to-machine), and get a redirect URI form and an SDK snippet. The official SDKs cover React, Next.js, Vue, Express, Go, Python, PHP, .NET, Flutter and a few more, and they do the token dance for you. The sign-in experience is a hosted page you theme with a colour, a logo and a choice of identifiers (email, phone, username), with social providers (Google, GitHub, Apple, Microsoft and about 20 others) added as connectors. Passwordless email codes and passkeys are switches, not projects.

Compare that to Keycloak, where the same result is a realm, a client, a client scope, a mapper and 2 hours of reading. Logto's "younger project with evolving APIs" con from the catalogue is real, but the flip side is a product designed in 2022 rather than 2014.

Organizations and RBAC are there, with a catch

Logto has role-based access control at 2 levels: global roles with API-resource scopes, and organizations, which give you multi-tenant SaaS semantics (a user belongs to org A as admin and org B as member) without building it yourself. Scopes show up in the access token; your API checks them. This is genuinely the feature that separates it from "just OIDC".

The catch is the protocol surface. Logto is OIDC-native. It can consume enterprise SAML and OIDC identity providers for sign-in, and SAML application support arrived later than the rest, so if your main requirement is being a SAML identity provider for a pile of third-party apps, Casdoor or Keycloak have the longer track record. Check the current docs before betting on it.

Cloud or self-hosted, and what the licence means

Logto Cloud has a free tier and a paid tier; self-hosting is free of charge at any scale, and the MPL-2.0 licence is permissive enough that embedding it in a commercial product is fine. What you take on is the operational side: Postgres backups (a pg_dump nightly is enough), keeping up with releases, and monitoring. Since a broken auth server means every app behind it is down, I would treat it like a password manager: put it on a box that does little else, back it up like it matters, and read the SSO explainer first if OIDC terms are new to you. The identity category lists the alternatives if the fit above is wrong.

What I'd do

Building an app with real users: Logto self-hosted, Postgres on the same host, both ports behind Caddy, ENDPOINT fixed before the first user registers, admin console on a Tailscale-only hostname. Turn on passkeys and email codes, skip passwords entirely for new projects. Protecting existing self-hosted services with a forward-auth login wall: not Logto; use Authentik or Authelia and save yourself the mismatch. And if you are coming from a paid provider, the Auth0 switching notes cover what does and does not migrate.