Guide de déploiement

Héberger Logto sur un VPS : l'authentification chez vous

Déployer sur un VPS Cloud →

Tutoriel

Héberger Logto sur un VPS : l'authentification chez vous

Développement10 min de lecture10 étapes

Les services d'authentification hébergés facturent à l'utilisateur actif mensuel, et gardent les données de connexion de vos utilisateurs sur leurs serveurs. Logto est l'alternative open source : une plateforme d'authentification OIDC/OAuth 2.0 complète que vous déployez sur votre propre VPS et que vous maîtrisez de bout en bout. Un fichier Docker Compose, deux conteneurs (Logto et PostgreSQL 17), et vos applications disposent d'une authentification de production — inscription, connexion sociale, MFA, contrôle d'accès par rôles — sans coût par utilisateur.

Sommaire· Ce qu'est Logto — et ce qu'il n'est pas1/11
  1. 01Ce qu'est Logto — et ce qu'il n'est pas
  2. 02Prérequis
  3. 03Comment Logto fonctionne en production
  4. 04Ce que Logto apporte dès l'installation
  5. 05Déploiement Docker Compose pas à pas
  6. 06Se connecter la première fois
  7. 07Intégrer Logto dans une application Next.js
  8. 08Activer la connexion Google
  9. 09Logto, Authentik, Authelia, Keycloak — lequel choisir ?
  10. 10Dépannage fréquent
  11. 11Stratégie de sauvegarde

Ce qu'est Logto — et ce qu'il n'est pas

Logto est une plateforme d'authentification livrée comme un SDK : vous l'intégrez au code de votre application en une quinzaine de lignes, et elle prend en charge tout le cycle de vie des comptes, sur votre propre serveur. C'est différent des deux autres outils d'authentification du catalogue ServOrbit :

- Authelia ajoute MFA et authentification unique *devant* des applications existantes, par délégation, sans toucher à leur code — il protège des applications qui n'ont pas d'écran de connexion du tout.
- Authentik est un fournisseur d'identité complet, pour centraliser l'authentification unique de vos outils auto-hébergés (Grafana, Gitea, Nextcloud).
- Logto remplace un service d'authentification hébergé : vous appelez son SDK depuis votre application React, Python ou Go, et il gère comptes, sessions, connecteurs sociaux et jetons.

Si vous construisez un produit où les utilisateurs créent un compte, Logto est l'outil adapté.

Prérequis

Avant de déployer Logto 1.19+, vérifiez les points suivants sur votre VPS ServOrbit :

- RAM : au moins 2 Go (4 Go recommandés si vous attendez plus de 5 000 utilisateurs actifs). Logto s'exécute sur Node.js 20 LTS et partage la même instance que PostgreSQL 17.
- CPU : 1 vCPU suffit pour un démarrage, mais 2 vCPU évitent les latences à la connexion sous charge.
- Disque : comptez au minimum 10 Go libres : PostgreSQL alloue des journaux WAL et les sessions actives s'accumulent rapidement avec la journalisation d'audit activée par défaut.
- Docker ≥ 24.0 et Docker Compose ≥ 2.20 — préinstallés sur toutes les offres VPS ServOrbit.
- PostgreSQL 17 minimum (inclus dans l'image officielle Logto) — les versions antérieures ne supportent pas les extensions requises.
- Un nom de domaine ou sous-domaine pointé vers votre VPS et résolu publiquement : Logto inscrit ce domaine dans chaque jeton OIDC qu'il émet. Il doit être défini avant le premier démarrage et ne peut plus être modifié sans réinitialiser toutes les données utilisateur.

Comment Logto fonctionne en production

Logto démarre deux conteneurs : db (PostgreSQL 17 pour les utilisateurs, les applications, les sessions et le journal d'audit) et logto (Node.js, qui sert le point d'accès OIDC sur le port 3001 et la console d'administration sur le port 3002). Le proxy inverse nginx de votre VPS transmet le trafic HTTPS de votre domaine vers le port 3001 — c'est le point d'accès auprès duquel vos applications s'authentifient. Le port 3002 n'est lié qu'à la boucle locale et n'est joignable que par un tunnel SSH, ce qui garde l'administration de votre base d'utilisateurs hors de l'internet public.

Ce que Logto apporte dès l'installation

  • Des jetons conformes OIDC/OAuth 2.0 — des JWT signés que n'importe quelle bibliothèque standard (passport.js, python-jose, go-oidc) vérifie sans code spécifique.
  • Des connecteurs de connexion sociale — activez Google, GitHub, Apple, Microsoft, Discord et une trentaine d'autres fournisseurs depuis la console, en un clic ; chacun demande une déclaration OAuth de quelques minutes côté fournisseur.
  • L'authentification sans mot de passe — liens magiques par courriel ou codes à usage unique par SMS (Twilio, SendGrid, Mailgun), sans maintenir un service de notification séparé.
  • La double authentification — TOTP (Google Authenticator, Authy), clés matérielles WebAuthn/FIDO2 et codes de secours, imposés par politique depuis la console.
  • Le contrôle d'accès par rôles — définissez rôles et permissions dans la console, recevez-les comme revendications scope du JWT, et appliquez-les dans votre API en une ligne d'intergiciel.
  • Des SDK pour plus de 20 cadres — React, Next.js, Vue, Angular, React Native, Flutter, Python, FastAPI, Go, PHP, Laravel, .NET, Java, Spring Boot et d'autres.

Déploiement Docker Compose pas à pas

  1. Créer le répertoire et le fichier Compose

    Connectez-vous en SSH à votre VPS, puis créez le répertoire de travail :

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

    Créez le fichier docker-compose.yml avec le contenu suivant. Remplacez auth.votre-domaine.com par votre propre domaine :

    version: '3.9'
    services:
      db:
        image: postgres:17-alpine
        restart: unless-stopped
        environment:
          POSTGRES_DB: logto
          POSTGRES_USER: logto
          POSTGRES_PASSWORD: ${DB_PASSWORD}
        volumes:
          - logto_db:/var/lib/postgresql/data
      logto:
        image: svhd/logto:latest
        restart: unless-stopped
        depends_on:
          - db
        ports:
          - '127.0.0.1:3001:3001'
          - '127.0.0.1:3002:3002'
        environment:
          DB_URL: postgresql://logto:${DB_PASSWORD}@db:5432/logto
          ENDPOINT: https://auth.votre-domaine.com
          ADMIN_ENDPOINT: https://auth.votre-domaine.com:3002
          SECRET_VAULT_KEK: ${SECRET_VAULT_KEK}
    volumes:
      logto_db:
  2. Générer les secrets et créer le fichier .env

    Générez un mot de passe de base de données et une clé AES-256 solides :

    DB_PASSWORD=$(openssl rand -hex 32)
    SECRET_VAULT_KEK=$(openssl rand -hex 32)
    printf "DB_PASSWORD=%s\nSECRET_VAULT_KEK=%s\n" "$DB_PASSWORD" "$SECRET_VAULT_KEK" > .env
    chmod 600 .env

    Vérifiez que .env contient bien deux lignes non vides avant de continuer.

  3. Configurer nginx en proxy inverse

    Créez le vhost /etc/nginx/sites-available/logto :

    server {
        listen 443 ssl;
        server_name auth.votre-domaine.com;
        ssl_certificate /etc/letsencrypt/live/auth.votre-domaine.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/auth.votre-domaine.com/privkey.pem;
    
        location / {
            proxy_pass 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 https;
        }
    }

    Activez le site et rechargez nginx :

    ln -s /etc/nginx/sites-available/logto /etc/nginx/sites-enabled/
    nginx -t && systemctl reload nginx
  4. Démarrer la pile et vérifier

    Lancez les deux conteneurs :

    docker compose up -d

    Suivez les logs pendant 60 secondes pour confirmer que PostgreSQL est prêt et que Logto a terminé ses migrations :

    docker compose logs -f --tail=50

    Vous devez voir la ligne App is running at https://auth.votre-domaine.com — c'est le signal que le service est opérationnel.

  5. Vérifier le document de découverte OIDC

    Depuis votre poste local, vérifiez que le point d'accès OIDC répond :

    curl -s https://auth.votre-domaine.com/.well-known/openid-configuration | python3 -m json.tool | head -10

    La réponse doit contenir issuer, authorization_endpoint et jwks_uri. Si la commande renvoie une erreur 502, Logto n'a pas encore terminé ses migrations — attendez 30 secondes et réessayez.

  6. Configurer les sauvegardes automatiques

    Ajoutez une tâche cron pour exporter la base de données quotidiennement :

    crontab -e
    # Ajouter la ligne suivante :
    0 3 * * * docker exec $(docker compose -f /opt/logto/docker-compose.yml ps -q db) pg_dump -U logto logto | gzip > /var/backups/logto_$(date +\%Y\%m\%d).sql.gz

    Pour des sauvegardes automatisées, dédupliquées et chiffrées vers S3 ou Backblaze B2, montez le volume logto_db dans une instance Backrest disponible dans le catalogue ServOrbit.

Se connecter la première fois

  1. Ouvrir le tunnel SSH vers la console d'administration

    La console d'administration écoute sur le port 3002, lié à la boucle locale pour des raisons de sécurité. Depuis votre poste, ouvrez un tunnel :

    ssh -L 3002:127.0.0.1:3002 root@ip-de-votre-vps

    Gardez ce terminal ouvert pendant toute votre session d'administration.

  2. Créer le compte administrateur

    Ouvrez http://localhost:3002 dans votre navigateur. L'assistant de première connexion s'affiche — il n'existe aucun identifiant par défaut. Saisissez une adresse courriel et un mot de passe robuste, puis cliquez sur Create account. Ces identifiants seront les vôtres pour administrer Logto ; conservez-les dans un gestionnaire de mots de passe.

  3. Explorer le tableau de bord

    Après la création du compte, vous accédez au tableau de bord Logto. Depuis ici vous pouvez : consulter le journal d'audit, gérer les utilisateurs, configurer les connecteurs sociaux et créer des Applications — c'est l'entité Logto qui représente un de vos projets.

  4. Créer votre première Application

    Dans la console : Applications → Create application. Choisissez le type correspondant à votre projet (Traditional Web, Single Page App, Native, ou Machine-to-machine). Donnez-lui un nom, puis renseignez l'Redirect URI — c'est l'URL vers laquelle Logto redirige après une connexion réussie (par exemple https://mon-app.com/api/logto/sign-in-callback pour une application Next.js). Logto génère alors un App ID et un App Secret que vous utiliserez dans votre SDK.

Intégrer Logto dans une application Next.js

Installez le SDK avec npm install @logto/next, puis créez un logto.ts qui exporte un new LogtoClient({ … }) configuré avec endpoint (l'URL de votre instance Logto), appId et appSecret (relevés dans la console Logto), baseUrl (l'URL de votre application), cookieSecret et cookieSecure.

Pour protéger une route, appelez getLogtoContext({ getAccessToken: true }) importé de @logto/next/server-component : il rend isAuthenticated et les claims de l'utilisateur. Si isAuthenticated est faux, redirigez vers /api/logto/sign-in ; sinon, servez la page en vous appuyant sur les revendications reçues.

C'est toute l'intégration : une quinzaine de lignes de configuration, un import, une garde.

Activer la connexion Google

Dans la console Google Cloud, créez un identifiant client OAuth 2.0 de type application web. Renseignez l'URI de redirection autorisée https://auth.votre-domaine.com/callback/google, puis copiez l'identifiant et le secret client.

Dans la console Logto → Connecteurs → Connecteurs sociaux → Google → Activer. Collez l'identifiant et le secret, puis enregistrez. Google apparaît dès lors comme une option de connexion sur votre page Logto, sans aucune modification de code dans votre application.

Logto, Authentik, Authelia, Keycloak — lequel choisir ?

Faites défiler le tableau

SolutionCas d'usage principalRAM minimaleComplexité d'intégration SDK
**Logto**Authentification pour un produit que vous développez (inscription, JWT, connecteurs sociaux)2 GoFaible — SDK officiel en 15 lignes pour React, Next.js, Python, Go, Flutter et 15+ autres
**Authentik**SSO centralisé pour vos outils auto-hébergés (Grafana, Gitea, Nextcloud, Proxmox)2 GoMoyenne — configuration via des *Providers* dans la console, pas de SDK applicatif
**Authelia**MFA et portail de connexion *devant* des applications existantes, sans modifier leur code256 MoNulle — délégation d'authentification par en-tête nginx, aucune intégration SDK
**Keycloak**SSO d'entreprise, fédération LDAP/AD, scénarios multi-tenant avancés4 Go minimumÉlevée — configuration OIDC manuelle, librairies client à configurer par framework

Pour un produit SaaS en construction, Logto est le point de départ naturel. Keycloak convient aux organisations qui ont déjà un annuaire d'entreprise à intégrer. Authelia et Authentik répondent à des besoins d'infrastructure plutôt qu'applicatifs.

Dépannage fréquent

Voici les quatre problèmes les plus courants lors d'une première installation de Logto sur VPS, et comment les résoudre.

La console d'administration est inaccessible (port 3002)

Le port 3002 est intentionnellement lié à 127.0.0.1 — il n'est pas accessible directement depuis internet. Si http://localhost:3002 ne répond pas, vérifiez d'abord que votre tunnel SSH est bien ouvert (ssh -L 3002:127.0.0.1:3002 root@<IP>). Vérifiez ensuite que le conteneur Logto tourne : docker compose ps. Si le conteneur est à l'état Exit, consultez les logs : docker compose logs logto --tail=50.

L'endpoint OIDC renvoie une erreur 502 (OIDC discovery 502)

Logto exécute ses migrations de base de données au premier démarrage — cela prend entre 30 et 90 secondes selon le VPS. Si le document de découverte /.well-known/openid-configuration renvoie 502, c'est que nginx transmet les requêtes avant que Logto ne soit prêt. Attendez 90 secondes, puis réessayez. Si l'erreur persiste, vérifiez que PostgreSQL est sain : docker compose logs db --tail=20 — cherchez la ligne database system is ready to accept connections.

Redirect URI mismatch

Logto valide strictement l'URI de redirection : si l'URI envoyée par votre application ne correspond pas exactement à celle déclarée dans la console Logto (Application → Redirect URIs), la connexion échoue avec l'erreur redirect_uri_mismatch. Vérifiez que vous avez enregistré l'URL complète, y compris le schéma (https://), le chemin exact et l'absence de barre oblique finale si votre SDK n'en envoie pas. Les URIs de développement (http://localhost:3000/…) doivent être ajoutées séparément dans la console.

Fatal: cannot connect to db

Si les logs Logto affichent Fatal: cannot connect to db, PostgreSQL n'était pas encore prêt quand Logto a tenté de s'y connecter. La déclaration depends_on de Docker Compose garantit l'ordre de démarrage des conteneurs, mais pas que PostgreSQL accepte des connexions. Relancez simplement le conteneur Logto : docker compose restart logto. Il se reconnectera dès que PostgreSQL sera prêt.

Stratégie de sauvegarde

Logto conserve tout son état dans le volume PostgreSQL logto_db. Sauvegardez-le par une tâche planifiée pg_dump, ou montez le volume dans une instance Backrest (également au catalogue ServOrbit) pour des sauvegardes automatisées, dédupliquées et chiffrées vers S3, Backblaze B2 ou SFTP. Perdre le volume logto_db, c'est perdre tous les comptes utilisateur, la configuration des applications et le journal d'audit — sauvegardez-le avant toute migration de VPS.

Votre couche d'authentification, sur votre VPS

Déployez Logto sur un VPS ServOrbit : gardez les données d'authentification de vos utilisateurs, sortez de la facturation par utilisateur, et intégrez les SDK React, Next.js, Python, Go, Flutter et bien d'autres.

Besoin d'aide ?

Parcourez notre centre d'aide et notre FAQ, ou contactez notre équipe — rappel, WhatsApp ou e-mail. Support en français, anglais et arabe.

Écrire sur WhatsApps'ouvre dans un nouvel onglet