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

Introduction: The Shift Toward Sovereignty in Identity Management

In the modern software architecture landscape, Identity and Access Management (IAM) serves as the gatekeeper for user data and system security. For years, cloud-native solutions like Auth0, Firebase Authentication, and AWS Cognito have been the default choices for development teams. They offer rapid deployment and abstract away the complexities of cryptographic protocols. However, as organizations scale, the trade-offs of relying entirely on proprietary, third-party cloud identity providers become increasingly apparent.

Escalating subscription costs tied to Monthly Active Users (MAU), strict vendor lock-in, and stringent compliance requirements regarding data residency (such as GDPR or local sovereignty laws) are driving architectural shifts. Engineering teams are increasingly adopting a 'local-first' or self-hosted paradigm. This article provides an end-to-end engineering guide to architecting and deploying a robust, self-hosted authentication infrastructure using Logto, an open-source identity solution, deployed via Docker on a Virtual Private Server (VPS).

Why Transition from Auth0 to Logto?

Auth0 is undeniably a feature-rich platform, but its pricing model can become prohibitive for consumer-facing applications experiencing rapid user growth. Furthermore, relying on an external cloud provider introduces network latency during authentication handshakes and limits your control over the underlying user database.

Logto emerges as a powerful open-source alternative that bridges the gap between the ease of use found in commercial SaaS products and the control offered by self-hosted solutions. Here is why Logto is an ideal candidate for a self-hosted IAM strategy:

• Developer-Centric Experience: Logto provides a polished, modern web admin console and a pre-built sign-in experience that rivals Auth0’s Universal Login.
• Standardized Protocols: Built natively on top of OAuth 2.0 and OpenID Connect (OIDC), ensuring compatibility with standard libraries and frameworks.
• Multi-Tenancy and RBAC: Out-of-the-box support for Role-Based Access Control (RBAC) and multi-tenant architectures, making it highly suitable for B2B SaaS applications.
• Cost Predictability: By hosting Logto on your own VPS, your infrastructure costs scale linearly with compute resources rather than arbitrarily with user counts.

Architectural Overview: The Local-First Topology

When implementing a self-hosted authentication solution, maintaining high availability, isolation, and security perimeter defenses is paramount. The production topology for this deployment consists of three primary layers:

1. The Reverse Proxy Layer (Nginx / Caddy / Traefik): Acts as the entry point, handling SSL/TLS termination, enforcing modern cipher suites, and forwarding clean traffic to the application container.
2. The Application Layer (Logto Core): The stateless Logto engine running inside an isolated Docker container, exposing endpoints for authentication, token issuance, and administrative APIs.
3. The Storage Layer (PostgreSQL): A persistent database instance responsible for storing user identities, session states, and configuration metadata.

Security Note: In a production environment, ensure that your PostgreSQL instance is isolated within a private Docker network and is not exposed to the public internet. Access should be restricted strictly to the Logto core container.

Step-by-Step Deployment Guide on a Docker VPS

1. Prerequisites and Server Provisioning

Before initiating the deployment, secure a VPS from a reliable provider (e.g., DigitalOcean, Linode, or AWS EC2) running a stable Linux distribution such as Ubuntu LTS. Ensure the following specifications are met:

• Minimum Hardware: 2 vCPUs, 4GB RAM (to comfortably run PostgreSQL, Logto, and a reverse proxy).
• Docker Engine and Docker Compose V2 installed and configured.
• A fully qualified domain name (FQDN) pointed via A/AAAA records to your VPS public IP address (e.g., auth.yourdomain.com).

2. Orchestrating with Docker Compose

To ensure a repeatable and declarative deployment, we define our entire infrastructure within a docker-compose.yml file. This orchestrates both the PostgreSQL database and the Logto application instance, utilizing Docker volumes for persistent storage and an isolated bridge network.

Create a dedicated directory on your VPS and deploy the following configuration:

version: '3.8'

services:
  postgres:
    image: postgres:15-alpine
    container_name: logto-database
    environment:
      POSTGRES_USER: logto_admin
      POSTGRES_PASSWORD: a_highly_secure_random_password
      POSTGRES_DB: logto_metadata
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - logto-network
    restart: always

  logto:
    image: svhd/logto:latest
    container_name: logto-core
    entrypoint: ["sh", "-c", "npm run cli db seed && npm run cli db alter -- --no-interaction && npm start"]
    ports:
      - "3002:3002"
      - "3003:3003"
    environment:
      - DB_URL=postgresql://logto_admin:a_highly_secure_random_password@postgres:5173/logto_metadata
      - ENDPOINT=[https://auth.yourdomain.com](https://auth.yourdomain.com)
      - ADMIN_ENDPOINT=[https://admin-auth.yourdomain.com](https://admin-auth.yourdomain.com)
    depends_on:
      - postgres
    networks:
      - logto-network
    restart: always

networks:
  logto-network:
    driver: bridge

volumes:
  pgdata:
    driver: local

In this configuration, the entrypoint command is configured to automatically run database migrations (db seed and db alter) on container initialization. This guarantees that your schema stays up to date during image updates without requiring manual CLI interventions.

3. Configuring Reverse Proxy and SSL Termination

Exposing raw container ports directly to the web poses severe security risks. To implement proper SSL termination and secure headers, we leverage Nginx as a reverse proxy. Below is an optimized server block configuration to manage routing securely:

server {
    listen 443 ssl http2;
    server_name auth.yourdomain.com;

    # SSL Configuration (Use Certbot to generate Let's Encrypt certificates)
    ssl_certificate /etc/letsencrypt/live/[auth.yourdomain.com/fullchain.pem](https://auth.yourdomain.com/fullchain.pem);
    ssl_certificate_key /etc/letsencrypt/live/[auth.yourdomain.com/privkey.pem](https://auth.yourdomain.com/privkey.pem);

    # Security Headers
    add_header X-Frame-Options "DENY";
    add_header X-Content-Type-Options "nosniff";
    add_header X-XSS-Protection "1; mode=block";

    location / {
        proxy_pass http://localhost:3002;
        proxy_set_header Host $$host;
        proxy_set_header X-Real-IP $$remote_addr;
        proxy_set_header X-Forwarded-For $$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $$scheme;
    }
}

Production Considerations: Hardening and Scaling

Migrating to a self-hosted architecture shifts operational responsibilities to your internal engineering team. To guarantee enterprise-level resilience, consider the following best practices:

Automated Database Backups

Implement a cron job on the host machine that performs daily logical backups of the PostgreSQL database using pg_dump. Securely upload these backups to an offsite, encrypted object storage bucket (such as AWS S3 or Cloudflare R2) with strict retention policies.

Horizontal Scaling Strategy

The Logto core application layer is completely stateless. As authentication traffic spikes, you can easily scale horizontally by spinning up additional Logto containers across multiple nodes or within a Docker Swarm / Kubernetes cluster, using an upstream load balancer to distribute traffic evenly.

Conclusion: True Autonomy in Identity Infrastructure

By transitioning from a cloud-managed service like Auth0 to a self-hosted Logto deployment on a Docker VPS, you unlock total autonomy over your authentication stack. This setup mitigates unpredictable scaling costs, ensures absolute data sovereignty, and guarantees ultra-low latency profiles by bringing the identity layer closer to your core applications. While self-hosting demands systematic infrastructure management, the long-term architectural control and financial optimization provide a massive competitive advantage for growing enterprises.