Introduction: The Identity Dilemma for Modern Applications

When launching a new software product, developers and business stakeholders face a critical technical hurdle: Identity and Access Management (IAM). Building an enterprise-grade authentication system from scratch is no longer viable. It introduces severe security liabilities, requires adherence to complex protocols like OAuth 2.0 and OIDC, and consumes valuable engineering hours that could otherwise be spent on core product features.

For years, third-party Customer Identity and Access Management (CIAM) vendors like Auth0, Okta, and Firebase were the default choices. However, scaling costs, vendor lock-in, and strict data sovereignty requirements have led modern engineering teams to seek alternative pathways. Enter Logto—an open-source, beautifully designed CIAM solution that balances the simplicity of a SaaS product with the absolute control of self-hosting. In this architectural guide, we will explore how to configure and deploy Logto Auth Server on a Cloud Virtual Private Server (VPS) to establish a robust, centralized identity layer for your application infrastructure.

Why Logto? The Shift Toward Modern Open-Source CIAM

Logto stands out in a crowded market dominated by legacy systems like Keycloak and costly SaaS platforms. It provides a unique combination of developer experience (DX), exceptional UI/UX design, and production-ready security protocols. Here is why it represents an ideal solution for a newly launched application:

Stunning Out-of-the-Box UI: Unlike traditional open-source tools that require extensive custom CSS styling, Logto includes a meticulously crafted, fully customizable sign-in experience that supports dark mode, multi-language localization, and seamless branding alignment.
Comprehensive Protocol Support: Logto is built natively on top of standard OpenID Connect (OIDC) and OAuth 2.0 frameworks, ensuring immediate compatibility with web, mobile, and desktop client architectures.
Extensive Multi-Tenant Capabilities: For modern B2B SaaS initiatives, Logto delivers native support for organization management, RBAC (Role-Based Access Control), and enterprise Single Sign-On (SSO) configurations.
Cost-Efficiency on Cloud VPS: By hosting Logto on an isolated Cloud VPS, you eliminate unpredictable per-user monthly SaaS fees and retain total ownership of your user identity database.

Prerequisites and Infrastructure Requirements

Before initiating the deployment process, ensure your Cloud VPS infrastructure meets the following minimum specifications to maintain operational stability and security:

Operating System: Ubuntu 22.04 LTS or Ubuntu 24.04 LTS (highly recommended for kernel security updates).
Hardware Specifications: A minimum of 2 vCPUs, 4GB of RAM, and 40GB of NVMe SSD storage. High-traffic environments will require horizontal scaling.
Prerequisite Software: Docker Engine (v20.10+) and Docker Compose V2 installed and validated on the host machine.
Networking Requirements: A fully qualified domain name (FQDN) pointed via A/AAAA DNS records to your VPS public IP address, alongside open inbound ports for HTTP (80) and HTTPS (443).

Step-by-Step Deployment: Hosting Logto via Docker Compose

To ensure isolated execution and streamlined dependency management, we utilize a containerized architecture leveraging Docker Compose. Logto requires a relational database backend; it officially supports PostgreSQL (version 14 or higher).

Step 1: Setting Up the Working Directory and Environment

Connect to your Cloud VPS via SSH and initialize a dedicated project directory to maintain standard configuration control:

mkdir -p /opt/logto && cd /opt/logto

Create a centralized environment file named .env to securely inject operational variables into your container ecosystem:

# Core Logto Configurations
PORT=3002
ADMIN_PORT=3001
ENDPOINT=[https://auth.yourdomain.com](https://auth.yourdomain.com)
ADMIN_ENDPOINT=[https://admin.yourdomain.com](https://admin.yourdomain.com)

# Database Configurations
POSTGRES_USER=logto_admin
POSTGRES_PASSWORD=SecureDatabasePassword2026
POSTGRES_DB=logto_identity
DB_URL=postgresql://logto_admin:SecureDatabasePassword2026@postgres:5432/logto_identity

# Security Secrets
COOKIE_SECRET=GenerateALongRandomStringForCookieSecurity
JWT_SECRET=GenerateAnotherLongRandomStringForJWTSigning

Security Warning: Replace SecureDatabasePassword2026 and the secret strings with high-entropy cryptographic keys. Compromise of these variables can lead to total system vulnerability.

Step 2: Defining the Orchestration Layer (docker-compose.yml)

Create a docker-compose.yml file within the directory. This configuration defines the structural dependency between Logto's primary core engine, its administrative portal, and the PostgreSQL persistence layer:

version: '3.8'

services:
  postgres:
    image: postgres:16-alpine
    container_name: logto-database
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - logto_postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
      interval: 5s
      timeout: 5s
      retries: 5
    networks:
      - logto-network

  logto:
    image: svhd/logto:latest
    container_name: logto-core
    entrypoint: ["sh", "-c", "npm run cli db seed -- --no-interaction && npm run start"]
    environment:
      - PORT=${PORT}
      - ADMIN_PORT=${ADMIN_PORT}
      - ENDPOINT=${ENDPOINT}
      - ADMIN_ENDPOINT=${ADMIN_ENDPOINT}
      - DB_URL=${DB_URL}
      - COOKIE_SECRET=${COOKIE_SECRET}
    ports:
      - "127.0.0.1:3002:3002"
      - "127.0.0.1:3001:3001"
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - logto-network

volumes:
  logto_postgres_data:

etworks:
  logto-network:
    driver: bridge

Note that mapping the application ports to 127.0.0.1 prevents unauthorized public internet exposure before going through our reverse proxy layer.

Configuring Nginx Reverse Proxy and Let\'s Encrypt SSL

To safely route external traffic and implement modern transport security protocols, we use Nginx alongside Certbot for automated SSL/TLS management.

Step 1: Constructing the Nginx Virtual Host File

Construct a configuration file under /etc/nginx/sites-available/logto.conf. This serves both the public-facing authentication terminal and the internal administrative portal:

server {
    listen 80;
    server_name auth.yourdomain.com;
    location / {
        proxy_pass [http://127.0.0.1:3002](http://127.0.0.1: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;
    }
}

server {
    listen 80;
    server_name admin.yourdomain.com;
    location / {
        proxy_pass [http://127.0.0.1:3001](http://127.0.0.1:3001);
        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;
    }
}

Activate the configuration block by creating a symbolic link and initializing the background containers:

ln -s /etc/nginx/sites-available/logto.conf /etc/nginx/sites-enabled/
nginx -t && systemctl restart nginx

cd /opt/logto && docker compose up -d

Step 2: Enforcing HTTPS with Certbot

Execute the Certbot ACME client to acquire and automatically inject Let\'s Encrypt TLS certificates, upgrading connections to strict HTTPS:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d auth.yourdomain.com -d admin.yourdomain.com

Certbot will adjust the Nginx architecture, configuring redirect patterns that mandate SSL/TLS encryption for all incoming payloads.

Post-Deployment Optimization and Best Practices

Now that your identity server is live, focus on operational steps to ensure long-term stability, performance, and security:

1. Secure the Admin Portal

During the initial launch of admin.yourdomain.com, create your primary administrator account immediately. This locks down control-plane access. For production systems, it is recommended to apply network IP constraints via Nginx to limit access to the admin panel to internal corporate networks or trusted VPN gateways.

2. Configure Transactional Email Engines (SMTP)

User sign-up verification, multi-factor authentication (MFA), and password resets rely on reliable email dispatch. Navigate to the Connectors section within Logto Console and establish direct links to specialized transactional mail relays such as SendGrid, Amazon SES, or Postmark.

3. Implement Automated Database Backups

Your user identities are your application's most sensitive data assets. Configure a periodic cron task on the host VPS to handle transactional snapshots of the internal database container:

0 2 * * * docker exec logto-database pg_dumpall -U logto_admin | gzip > /backups/db_$(date +\%F).sql.gz

Conclusion

Deploying Logto on a dedicated Cloud VPS offers a powerful combination of full infrastructure sovereignty and a premium user experience. By replacing custom-built authentication layers or high-cost SaaS providers with this OIDC-compliant open-source engine, you build a scalable foundation for your application. This setup gives your development team peace of mind, allowing them to focus entirely on building value for your end-users.

Self-Hosting Logto on Cloud VPS: A Premium, Developer-Friendly Identity Management Solution for Modern Applications