Logto OSS: self-hosted OIDC and OAuth 2.1 auth for SaaS and AI apps

What Logto solves for multi-tenant SaaS and agent platforms

Logto is positioned as "auth infrastructure for SaaS and AI apps", and the README lists the pieces that usually derail a first auth build: multi-tenancy, enterprise SSO, and RBAC. Those three are the expensive ones. A single-tenant app can get away with a users table and a session cookie; a product where each customer expects its own user pool, its own identity provider connections and its own role mapping cannot.

The project also claims full support for OIDC, OAuth 2.1 and SAML, and states that it works out of the box for Model Context Protocol and agent-based architectures. That framing matters for who should read further. If you are writing a CLI or a background worker that needs machine-to-machine tokens, the token endpoint and M2M integration path are part of the same server. If you are building a consumer app with a single tenant and no enterprise buyers, most of what Logto ships is weight you will never exercise.

The intended audience is a TypeScript-centric product team that wants a hosted-style auth service it can also run itself. Logto Cloud exists as the managed option, and the OSS build is the escape hatch.

How the OSS deployment is put together

The repository is a pnpm monorepo. The root package.json is private, licensed MPL-2.0, and its scripts fan out across packages: start:dev runs the workspace packages in parallel, start runs the core package, and cli exposes the logto command. There are separate packages/ directories for core, connectors and integration tests, and the Dockerfile builds the whole workspace with pnpm before pruning to a production install.

The runtime shape is two ports and one database. The compose file maps 3001 and 3002, runs a single app container based on svhd/logto, and depends on a postgres:17-alpine service with a health check. The app entrypoint is a shell command that seeds the database and then starts the server, which is why the compose file labels itself "for demonstration only, do not use in prod".

Two environment variables in that compose file deserve attention. TRUST_PROXY_HEADER is set to 1, so the server reads forwarded headers to reconstruct the public URL. ENDPOINT and ADMIN_ENDPOINT let you declare the public addresses explicitly, which the comments say is mandatory for GitPod and useful for local testing. Get these wrong behind a load balancer and redirect URIs will not match what the browser sees.

The connector model is also part of the architecture. The Dockerfile has a build argument, ADDITIONAL_CONNECTOR_ARGS, and runs pnpm cli connector link during the image build, so official connectors are selected at build time rather than enabled from a plugin directory at runtime.

Installing Logto with Docker and running a first sign-in

The README gives two local paths. The Docker Compose one pipes a compose file straight into Docker and starts a project named logto:

curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | \
docker compose -p logto -f - up

When the containers come up, the app service is listening on 3001 and 3002, and the Postgres service is healthy before the app starts because of the depends_on condition. The entrypoint runs `npm run cli db seed -- --swe && npm start`, so the first boot seeds the database before the server accepts traffic.

The second path is the npm initializer, which the README marks as requiring PostgreSQL:

npm init @logto

For a real deployment you would not use the demonstration compose file. The repository ships a Dockerfile that builds the monorepo on node:22-alpine, installs pnpm at version ^10.0.0, builds every package, links the connectors you pass in, then reinstalls with NODE_ENV=production and removes the scripts and cloud packages. Environment variables you will set on that image include DB_URL, ENDPOINT and ADMIN_ENDPOINT. The compose example uses `DB_URL=postgres://postgres:p0stgr3s@postgres:5432/logto`, which is a demo credential and should not survive contact with a real environment.

Once the server is up, the work moves to the admin console on 3002: create an application, pick the framework, and copy the client credentials into one of the SDKs. The README points at quick-start guides for React, Next.js, Angular, Vue, Flutter, Go, Python and others rather than embedding integration code, so the first real use is console configuration followed by an SDK install in your own app.

SSRF protection is on by default and will block private endpoints

The compose file documents a default that surprises people: SSRF protection for outbound requests is enabled by default. If you need Logto to reach a webhook, an SSO endpoint or an OIDC relying party on a private network, you have to list the address or CIDR range in SSRF_ALLOWED_ADDRESSES, for example `10.0.0.0/8`.

The blunt alternative is SSRF_PROTECTION_DISABLED=true, and the comment is explicit that this turns the protection off entirely and also disables features that depend on it, such as CIMD. OIDC_PROVIDER_SSRF_PROTECTION_DISABLED is supported as a legacy alias. So the choice is between maintaining an allowlist that grows with every internal integration, or turning off a protection that other features assume is present. That is a real trade-off, not a checkbox.

The second operational constraint is the release cadence. The releases listed are v1.41.0 on 2026-06-30, v1.42.0 on 2026-07-30 and v1.43.0 on 2026-08-31, roughly monthly, with the last push to master on 2026-09-20. A self-hosted instance therefore has a monthly upgrade rhythm to absorb, plus whatever database migrations the core package applies. The repository has an alteration script exposed as `logto db alt`, and the root package.json includes a test script that compares database schemas, which tells you schema changes are treated as a first-class concern. It does not tell you that rollback is supported; the README does not document rollback.

Logto versus Keycloak, Zitadel and Authentik

The most common comparison is against Keycloak. Keycloak is a long-established Java identity server with its own admin console and a broad protocol surface. Logto is TypeScript, ships a monorepo with framework SDKs, and frames itself around SaaS multi-tenancy and pre-built sign-in flows. If your team already runs the JVM and wants a battle-tested server with a large install base, Keycloak is the conservative choice; if your team is JavaScript-native and wants the SDK and the sign-in UI to come from the same project, Logto's shape fits better.

Zitadel and Authentik sit closer to Logto in positioning, both open source and both aimed at self-hosting. The practical difference to check is the tenancy and organization model, since that is where Logto puts its emphasis: organization RBAC, member invites and just-in-time provisioning appear in the README as first-class features rather than add-ons.

Against a managed service, the difference is ownership. Logto Cloud is offered as the zero-setup path, and the OSS build is the same project run by you, with PostgreSQL, the container image and the monthly releases as your responsibility. That is the actual decision: not feature parity, but who holds the database.

Licence and what self-hosting costs you

The root package.json declares MPL-2.0, and the repository carries a LICENSE file at the top level. MPL-2.0 is file-level copyleft: modifications to covered files stay under the same licence, while larger works that combine with them can be licensed differently. That is a different posture from a permissive licence, and it is worth a look from whoever handles your distribution obligations, particularly if you patch Logto source and ship the result. This is a description of the licence identifier, not legal advice.

The upgrade cost is the part teams underestimate. A monthly release train means a monthly decision: apply and test, or pin and accumulate. The Dockerfile shows the build is not trivial, since it installs a full toolchain (python3, make, g++, rsync) and builds every workspace package, so you are unlikely to be building custom images casually. The connector set is fixed at image build time through ADDITIONAL_CONNECTOR_ARGS, which means adding a connector later is an image rebuild, not a config toggle.

There is also a telemetry surface to check. The Dockerfile takes a logto_oss_survey_endpoint build argument, and the comment states the default is empty so external survey relaying stays opt-in for controlled builds.

When Logto is the wrong tool

If you are building a single-tenant application with email and password sign-in and nothing else, Logto is more infrastructure than the problem requires. You would be running PostgreSQL, a container and a monthly upgrade cycle to replace a few hundred lines of session code.

If you have no appetite for operating a database, the OSS path is the wrong one. Every install route in the README either requires PostgreSQL explicitly (the npm initializer) or bundles it (the compose file). The managed option exists, but that is a different product decision.

If you need a guarantee about rollback, the documentation does not provide one. The README documents installation and the alteration command, and the repository contains schema-comparison tests, but nothing in the supplied documentation describes downgrading a database after an upgrade. Treat that as an open question to resolve before you migrate a production user table, not after.

Finally, if your internal integrations live on private networks and you cannot maintain an allowlist, you will be choosing between SSRF_ALLOWED_ADDRESSES upkeep and disabling a protection that other features depend on.

Editorial conclusion

Adopt Logto if you are building a multi-tenant SaaS or agent platform, you are comfortable running PostgreSQL, and you want OIDC, OAuth 2.1 and SAML behind a pre-built sign-in UI instead of assembling them yourself. Skip it if you need an auth service that ships with no database, no container and no operational owner, because the OSS path always leaves the database, backups and upgrades with you. Before committing, verify the SSRF_ALLOWED_ADDRESSES and SSRF_PROTECTION_DISABLED behaviour against your own webhook and OIDC relying-party endpoints, and confirm how you will apply the weekly-to-monthly release cadence to a production instance.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. logto-io/logto on GitHub
3. Project website
4. README
5. Releases