​

v0.2.34 — Séparer Convex dans son propre service

​

TL;DR

# Dev :
tale upgrade
tale start              # détecte les migrations en attente, demande confirmation

# Production :
tale upgrade
tale deploy             # détecte les migrations en attente, demande confirmation
# Ou non-interactif (CI) :
tale deploy --yes

​

Pourquoi

​

Ce qui change

​

Architecture

• Nouveau service convex qui fait tourner convex-local-backend + Convex Dashboard. Il possède le volume convex-data (migré depuis platform-data).
• Nouvelle image Docker tale-convex (~485 Mo compressé).
• Image platform allégée de ~2,58 Go à ~320 Mo compressé — garde le binaire generate_key de la base convex-backend (nécessaire pour signer les tokens admin du push distant) mais sans le daemon backend, le Dashboard ni les assets builtin de seed.
• Les chemins upstream Caddy (/ws_api, /http_api, /api/storage, /convex-dashboard, /api/*/sync, …) sont re-routés de platform:* vers convex:*.
• Les services rag et crawler lisent leur config provider partagée depuis convex-data:/app/platform-config:ro au lieu de platform-data.

​

Démarrage platform (modèle push)

1. attend http://convex:3210/version (le service convex voisin) ;
2. pousse 24 variables d’env via bunx convex env set (secrets, URLs, sémantique de chemins de fichiers) ;
3. lance bunx convex deploy --url http://convex:3210 avec un timeout par défaut de 300 s ;
4. classifie les échecs de deploy en étapes start_push / wait_for_schema / finish_push avec diagnostics adaptés ;
5. pose /tmp/platform-ready — le gate du health check compose qui empêche le trafic jusqu’au deploy réussi.

​

Framework de migration

• Pas de nouveau flag utilisateur dans ce release. Le pipeline lance tout ce qui est en attente, dans l’ordre du registry.
• tale deploy --yes accepte toutes les migrations en attente de manière non-interactive (remplace --migrate-volumes déprécié, qui fonctionne encore comme alias pour un release).
• L’état persistant vit dans .tale/migrations.json (applied[] append-only) ; le marqueur legacy .tale/migration-pending est auto-migré au premier run.

​

Workflow dev

• bun run dev par défaut marche toujours (spawn bunx convex dev localement sur 127.0.0.1:3210).
• Nouveau mode CONVEX_EXTERNAL=true bun run dev pour faire tourner Vite contre un convex containerisé (docker compose up convex).
• vite.config.ts lit CONVEX_URL / CONVEX_SITE_PROXY_URL comme cibles proxy.

​

Instructions d’upgrade

tale upgrade            # n'écrit rien de destructif ; log les migrations en attente
tale start              # dev : détecte les migrations, demande [y/N], puis démarre
# ou en production :
tale deploy             # détecte, demande [y/N], puis déploie
# Non-interactif (CI) :
tale deploy --yes       # accepte les migrations sans demande

1. détecte chaque migration en attente du registry (set actuel : split-convex, plus namespace-volumes pour les utilisateurs encore en pré-v0.2.33) ;
2. imprime le plan : quelles migrations, quels conteneurs seront brièvement arrêtés, impact estimé ;
3. demande [y/N] (défaut Non). Refus → exit propre avec code 2 ; rien n’a changé.
4. Sur confirmation : arrête les conteneurs impactés, copie les données avec cp -a --user 1001:1001, vérifie strictement le compteur de fichiers (src + 1 sentinelle == dst), enregistre la migration dans .tale/migrations.json.
5. Laisse l’ancien volume intact.

docker volume rm <projectId>_platform-data
docker volume rm <projectId>-dev_platform-data   # si dev mode utilisé

​

Breaking changes

• Le conteneur platform ne monte plus /app/data en lecture-écriture. Si tu avais des bind mounts custom vers platform-data, réécris-les vers convex-data.
• platform n’expose plus les ports 3210, 3211, 6791 — ils vivent sur convex maintenant. Le routage Caddy gère la transition de façon transparente ; seuls les test harnesses custom qui tapent les ports directement doivent être mis à jour.
• Les mounts platform-data:/app/platform-config:ro sur rag / crawler deviennent convex-data:/app/platform-config:ro. Si tu lances ces services en standalone avec des compose files écrits à la main, mets à jour la source du mount.
• Le health check Docker du conteneur platform ne sonde plus que Vite (/api/health) — il n’exige plus Convex sain. Convex a son propre health check indépendant.

​

Rollback

# Cleanup optionnel : retirer le volume convex-data inutile
docker volume rm <projectId>_convex-data

​

Limitations connues

• Fenêtre transitoire blue-green (~10–30 s) : pendant le cutover, blue platform sert encore des utilisateurs alors que green a déjà déployé de nouvelles fonctions Convex. Si le nouveau deploy retire ou renomme une fonction, les clients blue peuvent voir des 404 pendant la fenêtre. Utilise expand-contract pour les breaking changes.
• Schéma forward-only : tale rollback revient aux images mais pas aux données Convex. Ajouts de champs requis, renommages et changements de types suivent le pattern expand-contract deux-releases documenté dans Compatibilité de schéma et rollback.
• Premier deploy après migration plus long que les suivants parce que les variables d’env Convex sont toutes “nouvelles” — compte ~30–60 s pour l’env sync + la complétion du deploy au premier boot.