Aller au contenu
Auto-hébergé

Une image, sur votre infrastructure

Le dashboard s'expédie sous la forme d'une seule image Docker et tourne sur le matériel que vous contrôlez. Trois moteurs de base de données, aucune télémétrie sauf si vous la configurez, et aucun compte requis pour la récupérer.

Récupérer l'image

linux/amd64linux/arm64Épingler une version →

Aucun compte, aucune connexion à un registre, aucun clone de dépôt — l'image est publique sur Docker Hub.

Votre instance, sur votre propre domaine

i18n.example.com

Tous les systèmes sont opérationnels

v0.23.0mode serveur

  • Base de données1156 keysok
  • SMTPsmtp.example.comok
  • Fournisseur de traductiongoogle-freeok

Ce que GET /api/healthrapporte sur une instance en cours d'exécution — la même sonde que lisent votre orchestrateur et votre monitoring de disponibilité.

1

Conteneur à lancer

3

Moteurs de base de données

2

Architectures CPU

0

Télémétrie par défaut

La décision

Ce que l'auto-hébergement vous apporte, et ce qu'il vous coûte

Il n'existe pas de dashboard hébergé auquel se comparer — l'auto-hébergement est la façon dont le produit fonctionne. La vraie question n'est pas si ça en vaut la peine, mais ce que vous prenez à votre charge.

Reste de votre côté

  • Votre code source. Le scanner lit votre dépôt depuis l'intérieur de votre propre réseau. Rien n'est envoyé pour en extraire les clés.
  • Vos traductions. Elles vivent dans la base de données que vous avez indiquée au conteneur — un fichier SQLite dans un volume, ou un serveur Postgres/MySQL que vous exploitez déjà.
  • Vos clés de fournisseur. DeepL, Google, LibreTranslate : les appels partent de votre instance, chiffrés au repos avec votre propre secret de session.
  • Votre frontière réseau. Le port publié se lie à 127.0.0.1 par défaut. Rien n'est accessible depuis une autre machine tant que vous ne l'avez pas décidé.

Devient votre travail

  • Le TLS et le reverse proxy. Rien dans l'image ne termine le TLS. L'exposer au-delà de localhost implique de mettre Caddy, nginx ou Traefik devant.
  • Les sauvegardes, et leur test. Un volume ou un dump de base de données. La CLI embarquée exporte tout en JSON ; la restauration reste à votre charge.
  • Les mises à jour. Récupérez le nouveau tag et redémarrez. Les migrations s'exécutent seules au démarrage, et une migration échouée n'est pas enregistrée : le prochain démarrage la retente.
  • La connexion, en mode serveur. Plusieurs comptes sur une même instance nécessitent un fournisseur OIDC compatible JWKS — le vôtre, ou celui que nous opérons. Le mode local n'a aucune connexion du tout.
Choisir

Comment vous voulez le faire tourner

Trois modes, une seule image. Le mode détermine s'il y a un écran de connexion et de quoi l'instance dépend — il ne change pas le produit.

Local

Par défaut

Choisissez ceci si c'est vous, ou une petite équipe, derrière un réseau de confiance.

  • Aucun écran de connexion — quiconque atteint le port a accès à tous les projets.
  • SQLite dans un volume Docker. Aucun second service à faire tourner.
  • Rien en sortie. L'instance ne dépend de personne.

Serveur

Multi-équipe

Choisissez ceci si plusieurs personnes ont besoin de leur propre compte sur la même instance.

  • Connexion, rôles, et le workflow Brouillon → Relu → Approuvé.
  • Une base de données réseau — PostgreSQL ou MySQL.
  • Nécessite un fournisseur OIDC compatible JWKS, joignable en permanence : le vôtre, ou celui que nous opérons.

Desktop

Sans Docker

Choisissez ceci si vous préférez ne pas faire tourner de serveur du tout.

  • Build natif macOS, Windows et Linux avec le serveur embarqué.
  • Les traductions restent en SQLite local — rien ne quitte la machine.
  • La connexion passe toujours par votre compte en ligne.

Télécharger l'application →

Choisissez un moteur

Votre base de données, votre fichier compose

Les trois moteurs portent les 27 mêmes tables : le choix ne porte donc pas sur la correction, mais sur la façon dont vous sauvegardez l'instance et sur qui d'autre doit y accéder.

Un fichier, un conteneur

Ce que l'image publiée embarque et ce qu'utilise l'application desktop. Aucun second service, aucun identifiant à gérer. L'instance entière tient dans ce fichier plus un volume Docker.

docker-compose.yml
Desktop ou auto-hébergé

Ce qui change quand vous auto-hébergez

CritèreApplication desktopAuto-hébergé
InstallationTélécharger et ouvrirdocker compose up -d
Base de donnéesSQLite, intégréSQLite, PostgreSQL ou MySQL
Où vivent les donnéesVotre machineVotre infrastructure
Mises à jourAutomatiquesdocker compose pull && docker compose up -d
Accès de l'équipeVous seul, sur cette machineToute votre équipe — le mode serveur nécessite un fournisseur OIDC (le vôtre, ou le nôtre)
Ensuite

Le reste de la procédure vit dans la documentation

Cette page couvre la décision : le faire vous-même ou non, dans quel mode, avec quel moteur. Tout ce qui vient après le premier démarrage réussi est documenté à un seul endroit, pour qu'il n'en existe jamais qu'une seule version.

  • Variables d'environnement — chaque variable, sa valeur par défaut et sa portée.
  • SMTP — notifications de workflow, ou rien du tout si vous laissez l'hôte vide.
  • Rôles et permissions — qui peut approuver une traduction dès que plusieurs personnes partagent l'instance.
  • Webhooks — des événements signés que vos propres systèmes peuvent exploiter.
  • Sauvegarde et restauration — le volume, le dump, et la CLI qui exporte tout en JSON.
  • Dépannage — les erreurs qui arrivent vraiment, et ce que chacune signifie.

Ouvrir la documentation