Architecture des conteneurs

Tale tourne comme six conteneurs Docker gérés par Docker Compose. Chacun a une seule responsabilité et communique sur un réseau bridge interne.

Architecture split phase 2 (depuis v0.2.34) : Convex tourne comme son propre service (convex) au lieu d’être intégré au conteneur platform. Platform devient un client Vite léger qui pousse schéma + env à Convex en HTTP. Voir Upgrade depuis pre-split-convex (pre-v0.2.34) pour l’étape de migration unique.

​

Vue des services

​

Détails des images

Séparer Convex de platform a réduit l’image platform de ~2,58 Go à ~320 Mo compressé ; le service convex est une nouvelle image ~485 Mo. Le disque total est similaire mais le layer platform rebuild bien plus vite pour des changements app-only.

​

Mapping des ports

​

Ports dev (compose.yml)

​

Ports test (compose.test.yml)

​

Mapping des volumes

Important : Ne lance jamais docker compose down -v. Le flag -v supprime tous les volumes Docker, effaçant définitivement ta base et toutes les données plateforme.

​

Arguments de build

​

Stratégie multi-stage

Tous les services utilisent un squash FROM scratch en stage final. Ça aplati les layers Docker pour que les suppressions de fichiers dans les étapes de cleanup libèrent vraiment du disque, au lieu d’ajouter des layers masquants. Ça garde les outils de build (gcc, build-essential, libpq-dev) hors de l’image finale.

​

Platform (5 stages, post-split)

1. bun-bin — extrait le binaire Bun.
2. workspace-deps — installe toutes les dépendances npm (dont devDependencies).
3. builder — lance vite build pour produire la SPA.
4. pruner — réinstalle uniquement les prod deps, retire les paquets dev (@vitest, @storybook, typescript, etc.).
5. runner — runtime finale sur l’image base convex-backend (conservée pour le binaire glibc generate_key qui signe les tokens admin Convex). SPA Vite + serveur Bun seulement — pas de backend Convex.
6. squash — FROM scratch + COPY --from=runner. Tourne en root, bascule sur user app via gosu dans l’entrypoint.

​

Convex (2 stages, nouveau en phase 2)

1. convex-dashboard — FROM ghcr.io/get-convex/convex-dashboard pour copier le build Next.js standalone.
2. runner — FROM ghcr.io/get-convex/convex-backend. Contient le daemon convex-local-backend, le Dashboard, les assets builtin de seed (agents/workflows/integrations/providers/branding) et l’entrypoint. Retire LLVM/Clang (~155 Mo).

​

Crawler (3 stages)

1. builder — installe les deps Python via uv, télécharge Chromium headless_shell, cleanup profond (retire Chrome complet, FFmpeg, pip, __pycache__, symboles debug .so, répertoires de test).
2. runtime — python:3.11-slim propre avec seulement les libs système runtime (deps Chromium, tini, curl). Retire LLVM/icônes Adwaita.
3. squash — FROM scratch + COPY --from=runtime. Pré-crée les mountpoints de volume pour /app/data et /app/platform-config.

​

RAG (3 stages)

1. builder — installe deps Python avec build-essential + libpq-dev pour compiler les paquets natifs, puis retire pip/setuptools.
2. runtime — python:3.11-slim propre avec seulement libpq5 + curl. Pré-crée les mountpoints.
3. squash — FROM scratch + COPY --from=runtime.

​

DB (3 stages)

1. cleanup — retire les symboles debug (~888 Mo), les libs LLVM partagées (~127 Mo), les fichiers d’extension PostGIS, les locales et docs de l’image ParadeDB de base.
2. runtime — FROM scratch + COPY --from=cleanup. Layer frais avec seulement les fichiers nettoyés.
3. squash — redéclare PGDATA, PATH et autres ENV perdus lors de FROM scratch.

​

Health checks

Les marqueurs /tmp/<service>-ready sont posés par l’entrypoint de chaque service après ses tâches d’init one-shot (Convex : backend up + seed builtin ; Platform : env sync + convex deploy). Ça empêche le trafic d’être routé avant que le service soit vraiment prêt.

​

Tests conteneurs

Tale inclut trois scripts de tests : Voir le guide de contribution Docker pour la modification des Dockerfiles et le lancement des tests.