Prérequis

Badlen est en développement actif : ce que vous installez depuis ces pages est construit sur les sources du moment et avance avec elles.

Docker avec Docker Compose, et quelques minutes pour la première compilation. Il n’y a aucun environnement d’exécution à installer, aucune base de données à monter à la main et aucun serveur web à configurer ; ce que la machine elle-même doit être, c’est la section ci-dessous.

La machine

N’importe quel hôte Linux 64 bits qui fait tourner Docker. Les deux images sur lesquelles la pile est bâtie, node:24-alpine et postgres:18-alpine, sont toutes deux publiées pour amd64 et arm64, si bien qu’un serveur x86 ordinaire et une carte ARM 64 bits (un Raspberry Pi sur un système 64 bits, un NAS ARM) conviennent l’un comme l’autre. Un système ARM 32 bits ne convient pas : l’image de base de l’application n’a pas de compilation pour lui.

La mémoire est demandée par la compilation plutôt que par la pile en marche. Mesuré sur une machine à deux cœurs : compiler l’interface a culminé près de 800 Mo dans un seul processus et compiler l’API près de 660 Mo, tandis que l’application s’installe ensuite autour de 225 Mo et un PostgreSQL au repos autour de 50 Mo. Ce sont des chiffres d’une machine et non un minimum certifié, et ce qu’ils tranchent est l’ordre de grandeur : des centaines de mégaoctets pour tourner, près d’un gigaoctet pour compiler. La compilation est le plancher, pas le service.

Ce qui tourne

La pile, c’est deux conteneurs. L’un est PostgreSQL 18. L’autre est l’application, qui sert l’interface compilée et son API depuis la même origine, si bien qu’il y a une image, un processus et une adresse à mettre derrière un reverse proxy, sans aucun arrangement CORS à faire, puisque le cookie de session ne traverse jamais d’origine.

L’application applique elle-même ses migrations en attente avant d’accepter la moindre requête. Rien d’autre n’a à être lancé contre la base de données, ni au premier démarrage ni à aucun suivant.

Disque et temps

Le premier docker compose up -d --build construit l’image depuis les sources, ce qui sur une petite machine domestique se compte en minutes et non en secondes, l’essentiel étant la compilation de l’interface. Chaque démarrage suivant répond en une quinzaine de secondes.

L’image construite fait près de 800 Mo, et chaque mise à jour ultérieure en construit une autre à côté. Mettre à jour dit ce que devient celle qu’elle remplace.

Récupérer les sources

Il n’existe aucune image publiée : la pile se construit depuis un clone du dépôt, que Docker Compose prend pour première étape avec les quatre commandes qui la suivent. Cette page est la procédure ; rien ici n’a à être lancé.

Une archive des sources téléchargée sans l’historique git fonctionne aussi : la version que l’instance annonce vient du fichier VERSION commité dans le dépôt, que l’image emporte, et non d’une étiquette.

À côté d’une copie de développement

Faire tourner la pile auto-hébergée à côté d’une copie de développement du même dépôt est sans danger. Les deux fichiers compose déclarent un service nommé db, mais chacun fixe son propre nom de projet (badlen pour la pile auto-hébergée, badlen-dev pour celle de développement), si bien que compose distingue les deux par projet plus service et qu’aucune ne remplace les conteneurs ni le volume de l’autre.

Aucun service ne fixe de container_name, et c’est délibéré : ce nom est global au démon Docker plutôt que limité à un projet, si bien qu’un nom fixé ici plafonnerait la machine à une seule pile quoi que dise -p.

Ensuite : Configuration, les trois secrets qu’il faut poser avant le premier démarrage.