Démarrage rapide en auto-hébergement

Démarrer MulticaCopy Anchor Link

Sur la machine qui fera tourner le service :

git clone --depth 1 https://github.com/multica-ai/multica.git
cd multica
make selfhost

Relancer make selfhost réutilise le .env et les volumes existants ; les secrets ne sont pas régénérés.

git fetch --tags --depth 1
git checkout $(git tag -l 'v*' --sort=-v:refname | head -1)

Vérifier que les services sont prêtsCopy Anchor Link

Vérifiez l'état des conteneurs :

docker compose -f docker-compose.selfhost.yml ps

postgres doit afficher healthy, et backend et frontend doivent être en cours d'exécution. Vérifiez ensuite le backend, la base de données et les migrations :

curl -fsS http://localhost:8080/readyz

La réponse attendue est :

{"status":"ok","checks":{"db":"ok","migrations":"ok"}}

Le conteneur backend exécute les migrations de base de données à chaque démarrage, avant de servir les requêtes ; il n'y a aucune commande de migration manuelle à lancer.

Choisir le mode d'accèsCopy Anchor Link

Se connecter et créer un espace de travailCopy Anchor Link

Ouvrez http://localhost:3000 en local, ou le https://app.example.com que vous venez de configurer, puis saisissez votre adresse e-mail pour demander un code de vérification.

Aucun service d'e-mail n'est configuré par défaut. Après avoir demandé un code, lisez-le dans les journaux du backend :

docker compose -f docker-compose.selfhost.yml logs backend \
  | grep "Verification code"

Les journaux contiennent une ligne comme celle-ci :

[DEV] Verification code for you@example.com: 123456

Saisissez le code et créez votre premier espace de travail. Une fois Resend ou SMTP configuré, les codes sont envoyés par e-mail et les membres n'ont plus besoin de lire les journaux des conteneurs ; consultez Configuration de l'authentification.

Connecter un ordinateurCopy Anchor Link

Lancez les commandes ci-dessous sur l'ordinateur qui fait tourner vos outils de codage IA, qui n'est pas forcément le serveur qui fait tourner Docker.

Installez d'abord le CLI Multica :

curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash

Reliez ensuite le CLI à votre service. Choisissez l'endroit où tourne le service Multica :

multica setup self-host

Si le service tourne sur une autre machine, passez les deux URL configurées précédemment. La commande vérifie d'abord <server-url>/health, puis ouvre un navigateur pour terminer la connexion. Une fois la connexion effectuée, elle enregistre les identifiants en local et démarre le daemon. Une erreur Server not reachable à cette étape signifie que la sonde n'a pas obtenu de 200 sur /health. Trois causes sont possibles : le proxy transmet tout à une version web qui ne relaie pas ce chemin ; le proxy ne route pas du tout /health vers le backend ; ou une défaillance de plus bas niveau (DNS, TLS, pare-feu, délai d'attente dépassé, 5xx renvoyé par le backend). Consultez Dépannage.

Vérifiez la connexion :

multica daemon status

La sortie doit afficher :

• Daemon: running
• Agents, qui liste les outils de codage IA installés sur cette machine
• Workspaces supérieur à 0

Terminer la première exécutionCopy Anchor Link

De retour dans Multica, dès qu'un runtime en ligne apparaît dans la liste des runtimes, créez un agent et assignez-lui votre première tâche.

Lorsque l'exécution apparaît comme terminée et que la réponse de l'agent s'affiche dans la chronologie, le service auto-hébergé, l'ordinateur et l'outil de codage IA sont tous connectés. Pour le détail, consultez les étapes 3 à 5 du démarrage rapide.

Vérifier que le tag d'image n'est pas figéCopy Anchor Link

Les deux images sont résolues en ${MULTICA_IMAGE_TAG:-latest} (docker-compose.selfhost.yml, services.backend.image / services.frontend.image), et .env.example fournit MULTICA_IMAGE_TAG=latest.

grep MULTICA_IMAGE_TAG .env
# MULTICA_IMAGE_TAG=v0.4.5   ← figé : remplacez-le d'abord par `latest` (ou la version souhaitée)

Sauvegarder PostgresCopy Anchor Link

Les migrations ne vont que vers l'avant ; faites donc un dump avant de mettre à niveau un déploiement auquel vous tenez :

docker compose -f docker-compose.selfhost.yml exec -T postgres \
  pg_dump -U multica multica > multica-backup.sql && gzip multica-backup.sql

Utilisez vos propres POSTGRES_USER / POSTGRES_DB de .env si vous avez modifié les valeurs par défaut multica. Les données résident dans le volume nommé multica_pgdata, qui survit à docker compose down, mais pas à down -v.

Télécharger les nouvelles images et recréer les conteneursCopy Anchor Link

Sur une installation existante, les deux commandes produisent le même résultat : la cible selfhost du Makefile exécute les mêmes docker compose pull + up -d, et en plus crée .env s'il est absent et attend /health avant d'afficher un résumé de l'état. Choisissez celle que vous préférez :

cd multica
git pull --ff-only
make selfhost

Comme à l'étape 2, le conteneur backend exécute ./migrate up au démarrage (docker/entrypoint.sh) avant de servir le trafic. Il n'y a pas de commande de mise à niveau distincte : démarrer la nouvelle image est l'étape de migration. Pour suivre le déroulement :

docker compose -f docker-compose.selfhost.yml logs -f backend

Les migrations qui complètent rétroactivement des données historiques (comme la 103) terminent aussi ce remplissage automatiquement. Dans de rares cas, le remplissage automatique échoue avec refusing to drop legacy daily rollups ; consultez Dépannage.

Vérifier avec /readyz, pas /healthCopy Anchor Link

curl -s localhost:8080/readyz
# {"status":"ok","checks":{"db":"ok","migrations":"ok"}}

Toute réponse autre qu'un HTTP 200 avec les deux vérifications à ok signifie que la nouvelle version n'a pas terminé ses migrations ; consultez les journaux du backend avant de lui envoyer du trafic.

/health est une sonde de vivacité (liveness) : elle renvoie {"status":"ok"} tant que le processus tourne, y compris lorsque les migrations ont échoué. /readyz (readyHandler, enregistré dans server/cmd/server/router.go ; /healthz en est un alias) vérifie la base de données et l'ensemble des migrations appliquées : c'est donc elle qui détecte une mise à niveau ratée.