DÉPLOYER

Applications

Déployez depuis Git, un Dockerfile, un fichier Compose ou une image prête, et configurez ce qui tourne.

Une application est une unité déployable : un service web, une API, un worker. Elle appartient à un projet, tourne dans un conteneur, et DockBoard la reconstruit et la redémarre à chaque déploiement.

Créer une application

Depuis Applications → Nouvelle application, trois choix définissent ce qui sera construit :

Framework: Next.js, NestJS, Docker, Docker Compose et d’autres. Ce choix sélectionne la stratégie de build — prenez Docker si votre dépôt embarque déjà un Dockerfile.
Source: L’URL d’un dépôt Git et une branche, ou une image Docker déjà construite depuis un registre.
Port: Le port sur lequel votre application écoute dans le conteneur. Ce n’est pas le port public — le routage vers lui relève des domaines.

Ce que DockBoard donne à chaque application

Un nom de conteneur prédictible — dockboard-<slug>.
Un nom d’hôte interne prédictible, identique au nom du conteneur.
L’appartenance au réseau Docker partagé du projet.

Grâce au troisième point, les autres applications du même projet l’atteignent à http://dockboard-<slug>:<port> — sans URL publique et sans rien exposer à Internet. C’est toute la base du réseau de services.

Cycle de vie

Action	Effet
Démarrer / Arrêter / Redémarrer	Agit sur le conteneur tel quel. Sans rebuild : l’image en cours ne change pas.
Redéployer	Re-tire la branche Git et reconstruit. C’est ce qui prend en compte les nouveaux commits.
Supprimer	Démonte la stack et retire le conteneur. Les volumes suivent les règles décrites dans stockage.

Chacune est consignée dans le journal d’audit, et chaque redéploiement apparaît dans l’historique de déploiement où vous pouvez lire son log de build ou revenir en arrière.

Monorepos et Dockerfile versionnés

Quand votre dépôt est un monorepo (workspace pnpm, turbo, yarn ou lerna) et qu’une application vit dans un sous-dossier comme apps/api, son Dockerfile versionné a généralement besoin de fichiers de la racine du dépôt :

DOCKERFILE

COPY pnpm-lock.yaml pnpm-workspace.yaml ./
COPY packages/ui/package.json ./packages/ui/

Ces instructions COPY échouent si le contexte de build Docker est le sous-dossier, car pnpm-lock.yaml et packages/* se trouvent au-dessus de lui. C’est pourquoi un tel Dockerfile se construit normalement avec docker build -f apps/api/Dockerfile … . — le contexte est la racine du dépôt, pas le dossier de l’application.

Automatique, sans configuration

Si DockBoard détecte un workspace — un pnpm-workspace.yaml, turbo.json, lerna.json, ou un package.json déclarant workspaces — et un Dockerfile versionné dans le sous-dossier, il construit depuis la racine du dépôt avec -f <sous-dossier>/Dockerfile. Le lockfile racine et les packages voisins sont alors dans le contexte : un monorepo se déploie sans aucun réglage.

Reprendre la main explicitement

La carte Dockerfile et contexte de build sur la page de l’application expose deux champs optionnels quand la détection ne correspond pas à votre besoin :

Champ	Rôle	Laissé vide
Chemin du Dockerfile	Quel Dockerfile construire, relativement au dépôt — `apps/api/Dockerfile`, ou `apps/api/Dockerfile.prod`.	`<sous-dossier>/Dockerfile`
Contexte de build	Le dossier servant de contexte `docker build` — vide ou `/` pour la racine du dépôt, ou un chemin comme `apps/api`.	Racine du dépôt pour un workspace, sinon le sous-dossier

Renseigner un contexte de build *(vide)* et un chemin de Dockerfile apps/api/Dockerfile revient exactement à docker build -f apps/api/Dockerfile -t <app> . exécuté à la racine du clone. L’équivalence vaut pour les déploiements locaux comme pour les serveurs distants — l’agent synthétise un docker compose équivalent avec build: { context, dockerfile }.

Enregistrer l’un ou l’autre champ déclenche un redéploiement. Les deux sont validés contre la traversée de chemin — .. et les chemins absolus sont refusés — et doivent donc se résoudre à l’intérieur du dépôt cloné.

Une application en sous-dossier lit aussi ses fichiers .env à deux endroits : la racine du dépôt et son propre dossier, le dossier l’emportant. Voir monorepos et variables d’environnement.

Importer un monorepo

Lorsque vous importez un monorepo, DockBoard inspecte chaque sous-application. Si l’une se construit depuis un Dockerfile versionné et embarque un prisma/schema.prisma, l’assistant d’import coche pour elle Provisionner une base, en lisant le provider dans le schéma.

Au déploiement, DockBoard provisionne la base et injecte un DATABASE_URL frais qui écrase toute valeur localhost pré-remplie. Une sous-application ayant besoin d’une base démarre alors contre la vraie base provisionnée au lieu de crasher contre localhost. Décochez la case si la sous-application gère sa propre base.