DÉMARRER

Installer DockBoard

Installez DockBoard sur votre propre serveur en une commande, puis accédez au tableau de bord et activez votre licence.

Une commande sur un serveur neuf. L’installateur ne pose aucune question — tout vient de variables d’environnement ou de valeurs par défaut raisonnables, ce qui le rend utilisable depuis un script de provisioning.

Avant de commencer

Un serveur Ubuntu 22.04+ ou Debian 12+ neuf, avec accès root.
Au moins 2 Go de RAM et 20 Go de disque.
Une adresse IPv4 publique, avec les ports 80 et 443 joignables depuis Internet — Let’s Encrypt valide en HTTP sur le port 80.
Les ports 3000 et 4000 joignables depuis votre poste, le temps de la première connexion avant la mise en place d’un domaine.
Optionnel mais recommandé : un domaine dont vous pouvez éditer l’enregistrement A.

Vous n’avez pas besoin d’installer Docker, Node, PostgreSQL, Redis ou Caddy au préalable. L’installateur s’en charge.

La commande

BASH

curl -fsSL https://get.dockboard.io/install.sh | sudo sh

Aucun accès GitHub n’est nécessaire et aucun code source n’est téléchargé — le script tire des images pré-construites depuis Docker Hub. Il ensuite :

01Détecte votre OS et installe curl, openssl, Docker et le plugin docker compose s’ils manquent.
02Écrit le fichier Compose dans /opt/dockboard avec des références d’images figées.
03Détecte l’IP publique de la machine.
04Génère /opt/dockboard/.env (mode 0600) avec des valeurs aléatoires cryptographiques pour le mot de passe de la base, les deux secrets JWT et la clé de chiffrement.
05Amorce les cibles de bind-mount pour que Docker ne les crée pas comme répertoires vides.
06Tire les images, démarre la stack, et attend jusqu’à 180 secondes que l’API réponde.

Relancer l’installateur est sans danger. Il préserve .env et le volume de la base, et ne reconstruit le tableau de bord que si l’URL publique de l’API a changé — cette valeur est figée à la compilation, une image périmée appellerait donc la mauvaise origine.

Surcharges

Variable	Défaut	Rôle
`DOCKBOARD_DIR`	`/opt/dockboard`	Racine d’installation.
`DOCKBOARD_TAG`	`latest`	Tag d’image à tirer.
`PUBLIC_API_URL`	autodétecté	Force l’URL publique de l’API figée dans le build du tableau de bord.
`PUBLIC_DASHBOARD_URL`	même hôte, port 3000	Origine du tableau de bord utilisée dans les liens des emails sortants.
`DOCKBOARD_RESET=1`	désactivé	Destructif. Efface `.env` et tous les volumes Docker, puis réinstalle à zéro.

Première connexion

Ouvrez http://<ip-du-serveur>:3000 et inscrivez-vous. Le premier compte créé devient SUPERADMIN — faites-le donc maintenant, depuis votre poste, avant que l’adresse ne soit publique.

Un assistant vous guide ensuite pour le SMTP, le domaine public et l’ouverture ou non des inscriptions. On peut fermer les inscriptions à tout moment depuis Admin → Paramètres.

Configurez le SMTP tôt, depuis Admin → Configuration système. Sans lui, les réinitialisations de mot de passe et les emails d’alerte deviennent silencieusement inopérants — le panneau fonctionne toujours, mais ne peut plus joindre personne.

Mettre un domaine devant

01Pointez un enregistrement A vers l’IP publique du serveur et attendez la propagation.
02Dans Domaines → Ajouter un domaine, saisissez le nom d’hôte et rattachez-le au tableau de bord.
03Le certificat est émis à la première requête sur ce nom d’hôte. Rien d’autre à faire.
04Puis fixez DASHBOARD_BIND=127.0.0.1 dans .env et redémarrez, pour que le port 3000 cesse de répondre en direct et que tout passe par TLS.

C’est cette dernière étape qu’on oublie. Tant que le port 3000 reste ouvert, le tableau de bord est joignable en HTTP simple autant qu’en HTTPS — formulaire de connexion compris.

Pré-amorcer une licence (hébergeurs)

Une installation sans intervention peut arriver déjà licenciée, pour que le client n’ait jamais à passer par Admin → Licence :

BASH

curl -fsSL https://get.dockboard.io/install.sh \
  | sudo DOCKBOARD_LICENSE_KEY='<signed token>' sh

Passez-le en variable d’environnement, pas en argument. Un argument de ligne de commande est visible dans ps par tout utilisateur de la machine, et il atterrit dans l’historique du shell appelant.

C’est une amorce, pas une surcharge — la distinction compte dès qu’un client gère ensuite sa propre licence :

Importée uniquement lors d’un démarrage qui ne trouve aucune clé déjà enregistrée.
Une clé posée depuis le panneau l’emporte toujours.
Supprimer la clé depuis le panneau reste effectif — un redémarrage ne la ressuscite pas.
Un jeton qui ne se vérifie pas n’est pas enregistré. L’instance tourne en formule gratuite et le log dit pourquoi — état honnête, plutôt qu’une clé stockée que le panneau signalerait indéfiniment comme refusée.

Le jeton et une commande d’installation prête à l’emploi reviennent d’un même appel de provisioning — voir l’API de licence.

Rester à jour

L’API vérifie l’existence d’une image plus récente toutes les cinq minutes. Le cas échéant, elle effectue un basculement bleu/vert : démarrer les nouveaux conteneurs, attendre qu’ils soient sains, basculer le proxy, puis retirer les anciens. À aucun moment plus rien ne répond.

L’application automatique exige DOCKBOARD_AUTO_UPDATE=true. Sans elle, le tableau de bord affiche simplement *mise à jour disponible* dans Admin → Mises à jour, où vous l’appliquez — et lisez le log — quand cela vous arrange.

Le watchdog hôte

Le healthcheck de Docker se contente d’étiqueter un conteneur comme malsain — il n’agit jamais. Et restart: unless-stopped ne couvre qu’un processus qui se termine réellement. Une API vivante mais bloquée reste donc hors service jusqu’à ce qu’un humain le remarque. Le watchdog comble ce trou, depuis l’extérieur de Docker :

BASH

sudo sh scripts/watchdog/install.sh

Il sonde l’endpoint de santé chaque minute. Après trois échecs consécutifs, il redémarre le conteneur d’API ; si le tour suivant échoue encore, il recrée toute la stack, puis observe dix minutes de repos pour qu’une installation réellement cassée ne soit pas redémarrée en boucle.

Il sonde la vivacité, jamais la disponibilité. Redémarrer l’API ne répare pas une base injoignable, et un watchdog qui essaierait ne ferait qu’ajouter du bruit à la panne.

Où vivent les choses ensuite

TEXT

/opt/dockboard/
  .env                          secrets, mode 0600
  .dockboard/
    update.log                  the most recent update run
    apps/<slug-id>/             generated stack, one per application
    databases/<slug>/           database stacks
    mail/                       mail server configuration
    reverse-proxy/Caddyfile     regenerated on every domain change

N’éditez rien à la main sous .dockboard/. Ces fichiers sont régénérés depuis la base — le Caddyfile à chaque changement de domaine, le script de mise à jour à chaque exécution — une modification survit donc jusqu’à la prochaine écriture, pas au-delà.

Si l’installation ne démarre pas, le dépannage couvre les pannes qui surviennent réellement.