Toute votre infrastructure Docker, pilotée depuis un seul écran.
Applications, bases de données, réseau privé, domaines, SSL, sauvegardes et serveur mail. DockBoard déploie depuis Git ou une image Docker, sur un VPS ou sur toute votre flotte, sans fichier de configuration à écrire.
Installez DockBoard sur votre propre VPS en une commande
Un seul VPS, ou toute une flotte.
Tout sur ce VPS
Le setup le plus simple : l'API crée le réseau du projet et y attache vos apps. La page Serveurs reste masquée.
- Aucun agent à installer
- Réseau Docker géré par l’API
- Bascule vers Multi à tout moment
Régions, isolation, charge
Un one-liner en SSH : l'agent s'installe, le serveur passe ONLINE, et vous choisissez sa destination pour chaque projet.
- Un projet vit sur un serveur
- Réseau et override compose écrits par l'agent
- Déplacement de projet entre VPS
Du dépôt au domaine, en quatre étapes.
Chaque déploiement suit le même chemin, que la cible soit ce VPS ou un serveur distant piloté par l’agent.
- 01
Source
Dépôt Git et branche, ou image Docker pré-construite. Framework détecté.
- 02
Build
Contexte de build résolu, monorepo compris. Image construite et taguée.
- 03
Réseau
Container attaché au réseau du projet, variables et bases injectées.
- 04
Exposition
Caddy régénéré, domaine attaché, certificat émis et renouvelé.
Vos services se parlent par leur nom.
Chaque projet possède son réseau Docker. Les apps se résolvent via le DNS interne : un seul domaine public, le reste reste privé.
Un domaine sur le frontend seulement. api et db restent internes, sans port public ni règle de firewall.
Les bons records, et l’état réel.
Vous gardez vos nameservers. DockBoard réconcilie ce qui est attendu avec ce qui est publié, et émet le certificat dès que le DNS pointe correctement.
| HOST | TYPE | VALEUR | ÉTAT |
|---|---|---|---|
| @ | A | 51.83.42.17 | OK |
| api | CNAME | athexis.xyz | OK |
| A | 51.83.42.17 | OK | |
| @ | MX 10 | mail.athexis.xyz | PENDING |
| @ | TXT | v=spf1 mx ~all | OK |
Jusqu’à 24 h de propagation est normal. Le bouton « Vérifier » relance le contrôle à la demande.
Ce que la plateforme gère pour vous.
Git ou image, un port
Framework, branche, port d’écoute. Démarrer, arrêter, redéployer, supprimer : la stack suit.
Provisionnées, pas exposées
PostgreSQL, MySQL, MongoDB, Redis, ClickHouse. Identifiants générés, chaîne de connexion prête.
Ce qui doit survivre, survit
Volumes nommés ré-attachés à chaque redéploiement et découverts par les sauvegardes.
Un serveur par domaine
Postfix et Dovecot en containers. MX, SPF, DKIM, DMARC, PTR : la page dit ce qui manque.
Journaux et état en direct
Sortie de build et runtime par app, état du container et historique des déploiements.
Accès par projet
Membres et rôles au niveau du projet : le réseau et les permissions suivent le projet.
Le contexte de build, deviné correctement.
Workspace pnpm, turbo, yarn ou lerna détecté avec un Dockerfile en sous-dossier : la construction part de la racine du dépôt. Lockfile et packages voisins sont dans le contexte.
COPY pnpm-lock.yaml pnpm-workspace.yaml ./
COPY packages/portal-kit/package.json ./packages/
# résolu par DockBoard :
docker build -f apps/licensing-api/Dockerfile .Une sous-app contenant un prisma/schema.prisma voit sa base provisionnée au déploiement, et un DATABASE_URL frais écrase le localhost pré-rempli.
Déplacer un projet de VPS à VPS.
Un bouton sur la card serveur. Les volumes source restent intacts sur l’ancien serveur, dans tous les cas.
- 01Apps et bases démontées sur la source, volumes conservés.
- 02Le serveur du projet bascule vers la cible.
- 03Transfert asynchrone des volumes Docker.
- 04Redéploiement une fois les données arrivées.
- 05Caddy régénéré : les domaines suivent.
- uploads
- /app/uploads
- pgdata
- /var/lib/postgresql
Volumes nommés uniquement : tout chemin hôte est rejeté par sécurité.
- Découverte automatique des volumes de la plateforme
- Planification quotidienne ou horaire selon la formule
- Restauration sur un autre serveur
- Rétention externe S3 compatible en option
Quatre rôles, des permissions explicites.
| RÔLE | DÉPLOYER | MEMBRES | MIGRER | SUPPRIMER |
|---|---|---|---|---|
| OWNER | autorisé | autorisé | autorisé | autorisé |
| ADMIN | autorisé | autorisé | autorisé | non autorisé |
| DEVELOPER | autorisé | non autorisé | non autorisé | non autorisé |
| VIEWER | non autorisé | non autorisé | non autorisé | non autorisé |
Gratuit pour commencer, par serveur ensuite.
La facturation suit vos serveurs, pas vos déploiements. Changez de formule ou arrêtez quand vous le souhaitez, sans engagement.
Les questions qui reviennent.
Le SSL reste bloqué sur PENDING.
DNS pas encore propagé, record A vers la mauvaise IP, ou ports 80/443 fermés sur le VPS. Relancez « Vérifier » dans l’onglet Records.
L'app est RUNNING mais l'URL ne répond pas.
Domaine non attaché, reverse proxy désynchronisé (bouton « Sync »), ou port container différent de celui attendu par Caddy.
Deux projets peuvent-ils communiquer en interne ?
Non : le réseau est limité au projet. Passez par l’URL HTTPS publique, ou regroupez les services dans un même projet.
Puis-je répartir un projet sur plusieurs VPS ?
Pas aujourd’hui : un projet vit sur un hôte Docker. Séparez en deux projets et exposez les services en HTTPS via Caddy.
Que devient une app si je repasse en mode Local ?
Elle continue de tourner sur le serveur distant, simplement masquée dans le dashboard jusqu’au rebascule.
Faut-il un fichier compose maison ?
Non, mais si votre app en embarque un, il fait autorité : la plateforme n’y injecte rien et respecte vos volumes.
Votre VPS est prêt. Le reste tient en une commande.
Créez un projet, ajoutez une app, attachez un domaine. DockBoard s’occupe du réseau, des bases, du SSL et des sauvegardes.