Container-Architektur

Tale läuft als sechs Docker-Container, die von Docker Compose verwaltet werden. Jeder Container hat genau eine Verantwortung und kommuniziert über ein internes Bridge-Netzwerk.

Phase-2-Split-Architektur (seit v0.2.34): Convex läuft als eigener Dienst (convex) statt im platform-Container. Platform wird ein schlanker Vite-Client, der Schema und Env über HTTP an Convex pusht. Siehe Upgrade von Pre-Split-Convex (vor v0.2.34) für den einmaligen Migrationsschritt.

​

Dienst-Übersicht

​

Image-Details

Das Abspalten von Convex aus Platform hat das Platform-Image von ca. 2,58 GB auf ca. 320 MB komprimiert reduziert; der Convex-Dienst ist ein neues ca. 485 MB großes Image. In Summe ist der Plattenbedarf ähnlich, aber der Platform-Layer baut für reine App-Änderungen viel schneller.

​

Port-Mapping

​

Entwicklungs-Ports (compose.yml)

​

Test-Ports (compose.test.yml)

​

Volume-Mapping

Wichtig: Führe niemals docker compose down -v aus. Das Flag -v löscht alle Docker-Volumes und vernichtet damit unwiderruflich deine Datenbank und sämtliche Plattform-Daten.

​

Build-Argumente

​

Multi-Stage-Build-Strategie

Alle Dienste nutzen als letzte Stage ein FROM scratch-Squash. Das flacht Docker-Layer ab, sodass Dateilöschungen in Cleanup-Stages wirklich Platz freigeben und nicht nur maskierende Layer ergänzen.

​

Platform (5 Stages, post-Split)

1. bun-bin — extrahiert das Bun-Binary.
2. workspace-deps — installiert alle npm-Abhängigkeiten (inkl. devDependencies).
3. builder — läuft vite build zur SPA.
4. pruner — reinstalliert nur Produktions-Deps, entfernt Dev-Pakete (@vitest, @storybook, typescript, etc.).
5. runner — finale Runtime auf dem convex-backend-Basis-Image (bleibt wegen der glibc-Binary generate_key, die Convex-Admin-Tokens signiert). Nur Vite-SPA + Bun-Server — kein Convex-Backend-Prozess.
6. squash — FROM scratch + COPY --from=runner. Läuft als root, wechselt via gosu im Entrypoint zum User app.

​

Convex (2 Stages, neu in Phase 2)

1. convex-dashboard — FROM ghcr.io/get-convex/convex-dashboard, um den Next.js-Standalone-Build zu kopieren.
2. runner — FROM ghcr.io/get-convex/convex-backend. Enthält den convex-local-backend-Daemon, das Dashboard, eingebaute Seed-Assets (agents/workflows/integrations/providers/branding) und Entrypoint. Entfernt LLVM/Clang (~155 MB).

​

Crawler (3 Stages)

1. builder — Python-Deps per uv installieren, Chromium headless_shell laden, tiefes Cleanup (entfernt vollständiges Chrome, FFmpeg, pip, __pycache__, .so-Debug-Symbole, Test-Verzeichnisse).
2. runtime — sauberes python:3.11-slim mit nur Runtime-System-Libs (Chromium-Deps, tini, curl). Entfernt LLVM/Adwaita-Icons.
3. squash — FROM scratch + COPY --from=runtime. Legt Volume-Mountpoints für /app/data und /app/platform-config im Voraus an.

​

RAG (3 Stages)

1. builder — Python-Deps mit build-essential + libpq-dev zum Kompilieren nativer Pakete installieren, danach pip/setuptools entfernen.
2. runtime — sauberes python:3.11-slim nur mit libpq5 + curl. Volume-Mountpoints im Voraus anlegen.
3. squash — FROM scratch + COPY --from=runtime.

​

DB (3 Stages)

1. cleanup — entfernt Debug-Symbole (~888 MB), LLVM-Shared-Libraries (~127 MB), PostGIS-Extension-Files, Locales und Docs aus dem ParadeDB-Basis-Image.
2. runtime — FROM scratch + COPY --from=cleanup. Frischer Layer nur mit bereinigten Dateien.
3. squash — deklariert PGDATA, PATH und andere ENV-Vars neu, die bei FROM scratch verloren gingen.

​

Health-Checks

Die Marker /tmp/<service>-ready werden vom Entrypoint jedes Dienstes gesetzt, sobald dessen Einmal-Init-Arbeit abgeschlossen ist (Convex: Backend läuft + Builtin-Seed; Platform: Env-Sync + convex deploy). Das verhindert, dass Traffic geroutet wird, bevor der Dienst wirklich bereit ist.

​

Container-Tests

Tale bringt drei Container-Testskripte mit: Siehe Contributing Docker guide für Details zum Ändern von Dockerfiles und Ausführen der Tests.