What Logto actually is — and what it is not
Logto is an auth SDK platform: you integrate it into your application's code via a 15-line SDK snippet, and it handles the complete user lifecycle on your own server. This is different from the two other authentication tools in the ServOrbit catalogue:
- Authelia adds MFA and SSO *in front of* existing apps via forward auth, without changing their code — it protects apps that have no login at all.
- Authentik is a full identity provider for centralising SSO across your self-hosted tools (Grafana, Gitea, Nextcloud).
- Logto replaces Auth0 or Clerk: you call its SDK from your React, Python, or Go application, and it manages user accounts, sessions, social connectors, and tokens.
If you're building a product where users create accounts, Logto is the right tool.
Prerequisites
You need a ServOrbit VPS with at least 2 GB RAM — Logto (Node.js) and PostgreSQL 17 share the same instance. Docker and Docker Compose are pre-installed on all ServOrbit VPS plans. You also need a domain name (or subdomain) pointed to your VPS: Logto bakes the public domain into every OIDC token it issues, so the domain must be set before the first deployment and cannot be changed without resetting all user data.
How Logto works in production
Logto starts two containers: db (PostgreSQL 17 for users, apps, sessions, audit logs) and logto (Node.js serving the OIDC endpoint on port 3001 and the admin console on port 3002). The nginx reverse proxy on your VPS forwards HTTPS traffic on your domain to port 3001 — that's the endpoint your applications authenticate against. Port 3002 (admin console) is bound to localhost only and is accessible only via SSH tunnel, which keeps your user database management off the public internet.
What Logto provides out of the box
- OIDC/OAuth 2.0 compliant tokens — signed JWTs that any standard library (passport.js, python-jose, go-oidc) can verify without custom code.
- Social login connectors — enable Google, GitHub, Apple, Microsoft, Discord and 30+ providers from the admin console in one click; each requires a 5-minute OAuth App setup on the provider side.
- Passwordless authentication — send magic links (email) or OTP codes (SMS via Twilio, SendGrid, Mailgun) without maintaining a separate notification service.
- MFA — TOTP (Google Authenticator, Authy), WebAuthn/FIDO2 hardware keys, and backup codes, enforced by policy from the admin console.
- Role-based access control — define roles and permissions in the console; receive them as
scopeclaims in the JWT and enforce them in your API with a single middleware line. - SDKs for 20+ frameworks — React, Next.js, Vue, Angular, React Native, Flutter, Python, FastAPI, Go, PHP, Laravel, .NET, Java, Spring Boot and more.
One-click deploy with ServOrbit
Go to your ServOrbit dashboard → Marketplace → Security → Logto → Deploy. Choose the VPS size (2 GB RAM minimum), assign a domain, and click Deploy. ServOrbit provisions the VPS, configures the nginx vhost for your domain, generates the database credentials and the SECRET_VAULT_KEK (AES-256 key for encrypted field storage), and starts the two-container stack. The OIDC discovery document is live at https://your-domain/.well-known/openid-configuration within 60 seconds.
First-run admin setup via SSH tunnel
The admin console listens on port 3002, bound to localhost for security. Open an SSH tunnel from your machine with ssh -L 3002:127.0.0.1:3002 root@your-vps-ip.
Then open http://localhost:3002/console in your browser. The first-run wizard asks for your admin email and password, then takes you to the dashboard. This is a one-time setup — afterwards you only open the tunnel to manage applications or users.
Integrating Logto into a Next.js application
Install the SDK with npm install @logto/next, then create a logto.ts that exports a new LogtoClient({ … }) configured with endpoint (your Logto instance URL), appId and appSecret (from the Logto admin console), baseUrl (your application URL), cookieSecret and cookieSecure.
To protect a route, call getLogtoContext({ getAccessToken: true }) imported from @logto/next/server-component: it returns isAuthenticated and the user's claims. If isAuthenticated is false, redirect to /api/logto/sign-in; otherwise render the page from the claims you received.
That is the whole integration: fifteen lines of configuration, one import, one guard.
Enabling Google social login
In the Google Cloud Console, create an OAuth 2.0 Client ID (Web application type). Set the authorised redirect URI to https://your-logto-domain.com/callback/google. Copy the Client ID and Client Secret.
In the Logto admin console → Connectors → Social connectors → Google → Enable. Paste your Client ID and Secret, save. Google now appears as a sign-in option on your Logto sign-in page automatically — no code changes needed in your application.
Backup strategy
Logto stores all its state in the logto_db PostgreSQL volume. Back it up with a pg_dump cron job or mount the volume to a Backrest instance (also in the ServOrbit marketplace) for automated, deduplicated, encrypted backups to S3, Backblaze B2 or SFTP. Losing the logto_db volume means losing all user accounts, application configurations, and audit logs — back it up before any VPS migration.
Logging in for the first time
Logging in for the first time
The admin console is not published on the internet: first open an SSH tunnel (ssh -L 3002:127.0.0.1:3002 root@<IP>), then go to http://localhost:3002. Click “Create account” — there is no default login.
