Introduction: The Shift Toward Self-Hosted Authentication

In the modern software development landscape, Identity and Access Management (IAM) is a critical pillar of any application architecture. For years, third-party Software-as-a-Service (SaaS) providers like Auth0 have been the gold standard, offering robust feature sets and quick integration. However, as applications scale, organizations frequently encounter significant bottlenecks: skyrocketing monthly costs driven by Monthly Active User (MAU) pricing models, stringent data residency compliance requirements, and vendor lock-in.

To mitigate these challenges, engineering teams are increasingly turning toward a "local-first" architecture philosophy. In the context of authentication, local-first implies that your identity data and authentication server reside directly within your controlled infrastructure rather than a black-box cloud ecosystem. This article provides an end-to-end guide on building and deploying an open-source, production-ready IAM solution using Logto hosted on a self-managed Docker VPS, serving as a powerful, cost-effective drop-in replacement for Auth0.

---

Why Logto is the Ideal Auth0 Alternative

While open-source IAM solutions like Keycloak have existed for a long time, they often suffer from steep learning curves, bloated resource consumption, and outdated user interfaces. Logto bridges this gap by offering a modern, developer-centric experience heavily inspired by Auth0, but with the freedom of open-source licensing.

Modern Developer Experience: Logto provides pre-built, beautifully designed Sign-In Experiences (SIEs) out of the box, drastically reducing frontend development time.
Comprehensive Protocol Support: It natively supports OIDC (OpenID Connect) and OAuth 2.0, making integration with existing applications seamless.
Multi-Tenant Capability: Ideal for B2B applications requiring strict organization and workspace isolation.
Resource Efficiency: Unlike Java-based heavyweights, Logto is built on Node.js and Go, running optimally even on budget-friendly VPS instances.

---

Architecture Overview: Local-First on a Docker VPS

Before diving into configuration, it is essential to understand the architectural footprint of this deployment. By utilizing a virtual private server (VPS) combined with Docker containerization, we achieve environment isolation, reproducibility, and easy backups.

The architecture consists of three core components:

Logto Core Container: Executes the business logic, token issuance, and OIDC flows.
PostgreSQL Database Container: Acts as the single source of truth for user credentials, sessions, and configurations.
Reverse Proxy (Nginx or Caddy): Handles SSL/TLS termination, routes external traffic securely, and manages domain binding.

Security Note: Even though the solution is self-hosted, keeping the database inside an internal Docker network isolated from the public internet ensures that your user data remains highly secure.

---

Step-by-Step Deployment Guide

1. Prerequisites and VPS Preparation

To follow this guide, you will need a VPS (e.g., DigitalOcean, Linode, or AWS EC2) running a clean installation of Ubuntu 24.04 LTS. Ensure you have a fully qualified domain name (FQDN) pointed to your VPS IP address (e.g., auth.yourdomain.com).

First, update your system packages and install the Docker engine along with the Docker Compose plugin:

sudo apt update && sudo apt upgrade -y
sudo apt install docker.io docker-compose-plugin -y

2. Configuring the Docker Compose Environment

Create a dedicated directory for your Logto deployment and navigate into it. We will establish a docker-compose.yml file to orchestrate our containers.

mkdir logto-stack && cd logto-stack
nano docker-compose.yml

Paste the following optimized configuration into the file:

version: '3.8'

services:
  postgres:
    image: postgres:16-alpine
    container_name: logto-postgres
    environment:
      POSTGRES_USER: logto_admin
      POSTGRES_PASSWORD: secure_db_password_here
      POSTGRES_DB: logto
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - logto-network

  logto:
    image: ghcr.io/logto-io/logto:latest
    container_name: logto-core
    entrypoint: ["sh", "-c", "npm run cli db seed -- --no-input && npm start"]
    ports:
      - "3001:3001"
      - "3002:3002"
    environment:
      - DB_URL=postgresql://logto_admin:secure_db_password_here@postgres:5432/logto
      - ENDPOINT=[https://auth.yourdomain.com](https://auth.yourdomain.com)
      - ADMIN_ENDPOINT=[https://admin.yourdomain.com](https://admin.yourdomain.com)
    depends_on:
      - postgres
    networks:
      - logto-network

networks:
  logto-network:
    driver: bridge

volumes:
  pgdata:
    driver: local

Ensure you replace secure_db_password_here and the domain endpoints with your actual credentials and domain names.

3. Initializing and Launching the Services

With the file configured, initiate the stack in detached mode using Docker Compose:

docker compose up -d

Logto will automatically run database seed scripts during its initial entrypoint sequence. You can monitor the startup logs to ensure everything resolves successfully:

docker compose logs -f logto

---

Configuring the Reverse Proxy and SSL

To secure transmission of credentials, exposing Logto over HTTPS is mandatory. Using a reverse proxy like Caddy simplifies this process by automating Let's Encrypt SSL certificates.

Create a Caddyfile in your server configuration:

auth.yourdomain.com {
    reverse_proxy localhost:3001
}

admin.yourdomain.com {
    reverse_proxy localhost:3002
}

Once Caddy is reloaded, navigating to [https://admin.yourdomain.com](https://admin.yourdomain.com) will present you with the initial Logto admin account creation wizard. From this centralized dashboard, you can configure your login branding, set up multi-factor authentication (MFA), and create your target applications.

---

Migrating Apps from Auth0 to Logto

Transitioning codebases from Auth0 to Logto is remarkably straightforward due to their shared compliance with the OpenID Connect spec. The modification primarily involves updating configuration keys within your application environment files.

Configuration Parameter	Auth0 Equivalence	Logto Equivalence
Authority/Issuer URL	`https://YOUR_[TENANT.auth0.com/](https://TENANT.auth0.com/)`	`[https://auth.yourdomain.com/oidc](https://auth.yourdomain.com/oidc)`
Client Identifier	`Client ID`	`Application ID`
API Identifier	`Audience`	`API Resource Indicator`

Most official OIDC SDKs (such as NextAuth.js, passport-openidconnect, or native mobile wrappers) require only these variable changes to route authentication requests successfully to your new self-hosted cluster.

---

Conclusion: Total Autonomy Over Identity

By shifting from a rigid SaaS pricing model to a self-hosted "local-first" setup via Logto and Docker, businesses unlock unprecedented structural freedom. You eliminate unpredictable monthly active user fees, ensure complete data privacy compliance by hosting user records locally, and retain full customizability over the authentication experience. As your user base grows, scaling your infrastructure is as simple as upgrading your VPS resources, placing the keys to your ecosystem back where they belong: in your hands.

Migrating from Auth0: Building a Self-Hosted, Local-First Authentication Solution with Logto and Docker