Installer Takuto Core

C’est la voie construisez-votre-propre-container : clonez le moteur Takuto Core, éditez config.toml et faites-le tourner directement avec Docker Compose. Choisissez-la quand vous voulez un contrôle total sur l’image, le déploiement et le réseau en façade.

Vous voulez juste l’essayer rapidement sur un projet ? Le Takuto CLI génère ces fichiers et lance Compose à votre place. Les deux voies font tourner le même moteur.

Prérequis

Voir Vue d’ensemble → Prérequis. En bref : Docker (ou Podman) avec docker compose, ≥ 8 Gio de RAM, ≥ 30 Gio de disque libre, un token GitHub et un compte chez un fournisseur d’IA.

Développeur individuel (local)

Faites tourner Takuto Core sur votre ordinateur portable. Comptez quinze à vingt minutes, car cette voie construit l’image du container en local.

1. Cloner et configurer

git clone https://github.com/takuto-team/takuto-core && cd maestro-core
cp config.toml.example config.toml
cp takuto.env.example takuto.env

Éditez config.toml :

  • Réglez [general] ticketing_system sur "jira", "github" ou "none".
  • Pour Jira : renseignez [jira] site, project_keys et email.
  • Pour GitHub Issues : le dépôt est détecté à partir du remote git du dépôt cloné.

Mettez les secrets dans takuto.env (jamais dans config.toml) :

export ANTHROPIC_API_KEY="sk-ant-..."
export GH_TOKEN="github_pat_..."

2. Construire

docker compose build

3. S’authentifier (première fois seulement)

docker compose run --rm -it takuto setup

Cela vous guide à travers GitHub CLI → Atlassian CLI (optionnel) → Claude Code ou Cursor Agent → clonage de votre dépôt.

Podman sur macOS : augmentez d’abord les ressources de la VM :

podman machine stop && podman machine set --memory 12288 --cpus 4 && podman machine start

4. Démarrer

docker compose up

Le dashboard est sur http://localhost:8080. Au premier démarrage, créez le compte admin initial. Si vous utilisez Jira ou GitHub Issues, le polling démarre automatiquement ; sinon, cliquez sur + pour lancer un workflow manuellement.

Déploiement en équipe (serveur)

Auto-hébergez Takuto Core sur un serveur Linux. Votre équipe utilise le dashboard via un navigateur ; l’agent tourne en arrière-plan.

1. Cloner et configurer sur le serveur

git clone https://github.com/takuto-team/takuto-core && cd maestro-core
cp config.toml.example config.toml
cp takuto.env.example takuto.env

Réglages clés pour un déploiement partagé :

[general]
ticketing_system = "jira"          # ou "github"
max_concurrent_workflows = 3       # ajustez au CPU/RAM de votre serveur

[web]
host = "0.0.0.0"
port = 8080

Takuto Core utilise une base de données multi-utilisateur pour l’authentification. Au premier démarrage, le dashboard vous invite à créer le compte admin initial ; cet admin peut ensuite créer d’autres utilisateurs depuis Configuration → Users.

2. Construire et s’authentifier

docker compose build
docker compose run --rm -it takuto setup

3. Démarrer en tant que service

docker compose up -d

4. Placer un reverse proxy en façade (recommandé)

Takuto Core écoute en HTTP simple. Terminez le TLS en façade avec nginx ou Caddy pointé sur le port 8080.

Exemple de snippet Caddy :

takuto.yourcompany.com {
    reverse_proxy localhost:8080
}

Derrière un terminateur TLS, définissez les origines autorisées du dashboard pour que les cookies et CORS fonctionnent correctement :

[web]
cors_origins = ["https://takuto.yourcompany.com"]

cookie_secure détecte automatiquement HTTPS à partir de cors_origins ou d’un en-tête entrant X-Forwarded-Proto: https ; forcez-le à true si votre proxy n’envoie pas cet en-tête. Voir la référence de Configuration pour la table [web] complète.

Modèle multi-utilisateur

Takuto Core est multi-utilisateur, mono-tenant : chaque utilisateur a sa propre vue du dashboard, mais tous les utilisateurs d’une instance partagent les mêmes identifiants Jira, GitHub et IA.

  • admin — peut créer, éditer, suspendre et supprimer des utilisateurs, et modifier les réglages partagés (polling, concurrence, changement d’espace de travail, clonage de dépôt).
  • user — voit et agit uniquement sur les workflows qu’il a créés. Aucune visibilité inter-utilisateurs, même pour les admins.

La connexion se fait par nom d’utilisateur + mot de passe (haché en argon2). Les sessions ont un TTL d’inactivité de 24 heures et un TTL absolu de 30 jours ; les comptes se verrouillent après 5 tentatives échouées en 10 minutes. Des codes de récupération à usage unique délivrés à la création du compte permettent de réinitialiser un mot de passe oublié.

Toute personne à qui vous donnez un compte peut exécuter du code dans les containers worker sous l’identité du déploiement — y compris les tokens de takuto.env. N’accordez pas de comptes à des personnes en qui vous n’avez pas confiance.

Persistance entre les redémarrages

Tout l’état d’authentification (GitHub, Atlassian, Claude/Cursor), les snapshots de workflow et le cache npm vivent dans des volumes Docker nommés. Les workflows survivent à docker compose restart — les exécutions en pause ou en cours reprennent automatiquement.

Sidecars optionnels

  • Docker-in-Docker — fusionnez docker-compose.dind.yml pour faire tourner les étapes de chaque workflow dans des containers Docker éphémères (évite les conflits de port et de système de fichiers entre workflows concurrents). Voir Étendre Takuto Core.
  • Pont vers un modèle auto-hébergé — fusionnez docker-compose.lm-bridge.yml quand vous pointez le fournisseur OpenCode sur un serveur de modèle tournant sur le Mac hôte. Voir Modèles auto-hébergés.

Étapes suivantes