# Installer un worker Allin — Docker Compose

Déployez votre worker sur Coolify ou Docker Compose, puis connectez Claude Code, Codex et GitHub depuis le serveur.

## Avant de déployer

Ce guide installe un worker relié à votre espace Allin, pas un nouveau serveur Allin. L’image publique inclut le paquet Allin, Claude Code, Codex et GitHub CLI.

- Préparez un serveur Linux amd64 avec Docker, un accès SSH et, si vous utilisez Coolify, un serveur déjà connecté à Coolify.
- Dans Allin → Workers, créez un worker de type Conteneur, choisissez ses agents et copiez sa clé. Vérifiez les jobs en attente : ils peuvent démarrer dès qu’un moteur est connecté.
- ALLIN_URL est l’adresse de votre instance Allin, accessible depuis le conteneur. ALLIN_WORKER_API_KEY est la clé de ce worker. Ne lancez pas deux conteneurs avec la même clé.
- Le serveur doit pouvoir joindre Allin, GHCR, les services du moteur choisi et GitHub si utilisé. Les intégrations MCP distantes sont appelées par le serveur Allin.

Les valeurs USER, WORKER_HOST, WORKER_CONTAINER et PASTE_YOUR_WORKER_KEY_HERE sont à remplacer. Ne demandez pas à l’utilisateur de coller des secrets dans le chat : utilisez les variables privées de Coolify. Les connexions dans le navigateur sont à terminer par l’utilisateur.

Avant de créer une ressource payante ou de lancer un job facturé, obtenez l’accord de l’utilisateur. Ce guide n’autorise aucune dépense.

## Docker Compose

Claude Code, Codex et la librairie Allin sont déjà installés dans l’image. Gardez compose.yaml et .env dans le même dossier.

Se connecter au serveur du worker

```sh
ssh USER@WORKER_HOST
mkdir -p ~/allin-worker
cd ~/allin-worker
```

[Télécharger Docker Compose](https://tryallin.com/downloads/allin-worker.compose.yaml)

[Télécharger le profil Docker](https://tryallin.com/downloads/allin-worker.seccomp.json)

Télécharger Docker Compose

```sh
curl --fail --location 'https://tryallin.com/downloads/allin-worker.compose.yaml' -o compose.yaml
curl --fail --location 'https://tryallin.com/downloads/allin-worker.seccomp.json' -o allin-worker.seccomp.json
```

Placez allin-worker.seccomp.json à côté de compose.yaml. Ce profil seccomp et l’exception AppArmor du Compose permettent le sandbox Codex. Utilisez un hôte dédié : AppArmor est désactivé uniquement pour ce conteneur, qui reste non privilégié, non root, sans capacités et avec no-new-privileges.

.env

```dotenv
ALLIN_WORKER_NAME=allin-worker
ALLIN_URL=https://tryallin.com
ALLIN_WORKER_API_KEY=PASTE_YOUR_WORKER_KEY_HERE
```

Remplacez PASTE_YOUR_WORKER_KEY_HERE par la clé copiée dans Allin. Ne partagez pas ce fichier.

Télécharger l’image du worker

```sh
chmod 600 .env
docker compose pull
```

## Sur quelle machine lancer les commandes ?

Si le worker est sur un serveur distant, connectez-vous d’abord en SSH à ce serveur. Toutes les commandes Claude, Codex et GitHub ci-dessous doivent être exécutées dans ce terminal distant, pas sur votre ordinateur.

Se connecter au serveur du worker

```sh
ssh USER@WORKER_HOST
cd /path/to/allin-worker
```

Remplacez USER, WORKER_HOST et le chemin par ceux de votre installation. Avec Docker, utilisez le dossier contenant le compose.yaml et le .env de ce worker pour retrouver ses volumes d’authentification.

Ouvrez les liens de connexion dans le navigateur de votre ordinateur. Saisissez le code affiché si demandé, puis revenez au terminal du worker. Les identifiants restent sur le serveur du worker. Pour un worker local, utilisez simplement son terminal local.

Connectez GitHub en premier si vos agents l’utilisent. Les jobs peuvent démarrer dès qu’un moteur est connecté.

Connectez uniquement Claude Code et/ou Codex selon les moteurs choisis sur vos agents. Redémarrez le worker après l’ajout d’un compte pour qu’il reconnaisse le nouveau moteur.

## GitHub pour cloner les dépôts

La connexion gh sert à Git et au clonage des dépôts. Elle ne remplace pas les identifiants du connecteur MCP GitHub dans Allin.

Connexion GitHub

```sh
docker compose run --rm worker gh auth login --hostname github.com --git-protocol https --web
docker compose run --rm worker gh auth setup-git --hostname github.com
docker compose run --rm worker gh auth status --hostname github.com
```

GitHub CLI est installé dans l’image. Connectez votre compte avec le code affiché dans le terminal ; le volume github-config conserve la connexion.

Si GH_TOKEN ou GITHUB_TOKEN est défini dans le conteneur ou la machine, gh utilise ce jeton en priorité. Vérifiez qu’il correspond au compte attendu, sans l’afficher ni le partager.

Pour utiliser gh dans un job, activez « Exécuter des commandes » dans le profil de l’agent, puis créez un nouveau job.

## Compte Claude du worker

Connexion Claude

```sh
docker compose run --rm worker claude auth login --claudeai
docker compose run --rm worker claude auth status
docker compose run --rm worker allin-worker doctor claude
```

Ouvrez le lien affiché dans le terminal, connectez votre compte Claude, puis collez le code de retour dans le terminal si demandé. Attendez « Login successful ».

Le volume claude-config conserve la connexion et les sessions. Ne le supprimez pas lorsque vous recréez le conteneur.

## Compte Codex du worker

Connectez le moteur choisi sur vos agents. Pour Codex, activez la connexion par code d’appareil dans les paramètres de sécurité ChatGPT, puis ouvrez le lien affiché dans le terminal.

Connexion Codex

```sh
docker compose run --rm worker codex login --device-auth
docker compose run --rm worker codex login status
docker compose run --rm worker allin-worker doctor codex
```

Le volume codex-config conserve l’authentification et les sessions Codex. Il reste privé et ne fait jamais partie de l’image publiée.

[Documentation officielle](https://developers.openai.com/codex/auth/#login-on-headless-devices)

## GitHub pour les outils MCP et les reviews

Les jobs utilisent la connexion GitHub autorisée dans Allin. Modifiez ses identifiants dans Connexions, puis vérifiez les outils activés et ceux autorisés sur le profil de l’agent.

[Ouvrir les connexions Allin](https://tryallin.com/app#connections)

- Le compte et le jeton doivent avoir accès aux dépôts concernés. Pour un jeton à permissions fines, sélectionnez le bon propriétaire et les bons dépôts.
- Contents : Read pour lire le code. Pull requests : Read pour lire les PR et leurs fichiers, Read and write pour créer ou publier une review, même PENDING.
- Si l’organisation l’exige, faites approuver le jeton ou l’application et autorisez son accès SSO.

Lire le code ne prouve pas que le jeton peut lire les PR ou créer une review. Corrigez les droits de la connexion utilisée, puis réessayez la lecture de la PR. Une lecture réussie ne valide pas les droits d’écriture.

[Permissions GitHub pour les reviews](https://docs.github.com/en/rest/pulls/reviews#create-a-review-for-a-pull-request)

Le profil de l’agent permet aussi de choisir le modèle, l’effort de réflexion, l’accès aux fichiers et les sous-agents.

## Vérifier la connexion

La commande doctor vérifie le moteur et sa connexion ; doctor codex teste aussi de vraies commandes dans les sandboxes lecture seule et écriture. Aucun modèle ni API Allin n’est appelé. Le badge Connecté dans Allin confirme le heartbeat du worker.

Connecté ne signifie pas que tous les moteurs sont disponibles. En preview.4, un échec du diagnostic Codex au démarrage exclut ce moteur : Claude peut fonctionner pendant que les jobs Codex restent en attente. Consultez les logs et relancez le worker après correction, une fois les jobs en cours terminés.

Terminez les connexions avant de démarrer. Si le worker a déjà des jobs en cours, attendez leur fin avant de le redémarrer.

Démarrer et suivre

```sh
docker compose up -d
docker compose logs --tail=50 -f worker
```

Dès son démarrage, le worker peut exécuter les jobs en attente avec les comptes et les outils autorisés. Le MCP Allin est configuré automatiquement.

Dans Allin → Workers, vérifiez le badge Connecté et les agents attribués. Vérifiez chaque moteur avec doctor et les logs du worker. Configurez les dépôts dans sa fiche. Un job de test valide ensuite le parcours complet, avec votre accord pour sa consommation.

## Codex sur Ubuntu : restriction AppArmor de l’hôte

Sur Ubuntu récent, apparmor=unconfined dans le Compose peut ne pas suffire. Si bwrap affiche « loopback: Failed RTM_NEWADDR: Operation not permitted », vérifiez sur l’hôte les refus du profil unprivileged_userns pour setpcap ou net_admin. Un test unshare -U réussi ne valide pas tout le sandbox.

Diagnostic depuis le serveur en SSH

```sh
sysctl kernel.apparmor_restrict_unprivileged_userns kernel.apparmor_restrict_unprivileged_unconfined
sudo journalctl -k --since "10 minutes ago" | grep -Ei 'apparmor="DENIED"|userns'
docker exec WORKER_CONTAINER sh -c 'id; cat /proc/self/attr/current'
docker exec WORKER_CONTAINER codex sandbox -- true
docker exec WORKER_CONTAINER find /usr/local/lib/node_modules/@openai/codex -type f -path '*/codex-resources/bwrap'
```

Remplacez WORKER_CONTAINER par le nom réel du conteneur. Avec Codex 0.160.0, utilisez codex sandbox -- true, sans ajouter linux. Le worker doit tourner sous node (uid 1000). Vérifiez le chemin du bwrap embarqué avant d’appliquer le profil ci-dessous.

Si les logs confirment cette restriction, un administrateur peut installer ce profil ciblé sur l’hôte Ubuntu, hors du conteneur. Il autorise userns pour le bwrap embarqué par Codex ; il ne désactive pas la restriction pour tout l’hôte. Cette exception a été validée avec l’image preview.4 sur Ubuntu ; revérifiez le chemin et le diagnostic après une mise à jour.

Profil hôte /etc/apparmor.d/codex-bwrap

```text
abi <abi/4.0>,
include <tunables/global>
profile codex-bwrap /usr/local/lib/node_modules/@openai/codex/**/codex-resources/bwrap flags=(unconfined) {
  userns,
  include if exists <local/codex-bwrap>
}
```

Charger le profil et vérifier Codex

```sh
sudo apparmor_parser -r /etc/apparmor.d/codex-bwrap
docker exec WORKER_CONTAINER codex sandbox -- true
docker exec WORKER_CONTAINER allin-worker doctor codex
```

Après réussite du diagnostic et connexion à Codex, redémarrez le worker quand ses jobs en cours sont terminés : les moteurs disponibles sont détectés au démarrage. Conservez seccomp, cap_drop: ALL, no-new-privileges et le sandbox Codex. Documentez l’exception AppArmor ; ne désactivez pas globalement la restriction userns de l’hôte.

[Documentation officielle du sandbox Codex](https://learn.chatgpt.com/docs/sandboxing)

## Fichiers des jobs et stockage persistant

Placez les dépôts, documents et données à partager entre jobs sous /workspace, couvert par un volume du Compose officiel. /tmp convient aux fichiers temporaires. L’accès à un chemin sous /home/node dépend du sandbox et des permissions : ne l’utilisez pas comme emplacement des documents de travail des agents.

Persistance et accès au sandbox sont distincts. Un volume conserve les fichiers lors d’une recréation du conteneur, mais n’accorde pas à Codex de nouveaux droits. Hors des volumes, les fichiers sont perdus lors d’un redéploiement. /home/node/.cache n’est pas persistant dans le Compose officiel.

Volume de cache facultatif : à fusionner avec le Compose existant

```yaml
services:
  worker:
    volumes:
      - worker-cache:/home/node/.cache
volumes:
  worker-cache:
```

Ajoutez ce montage et la déclaration du volume sans remplacer les volumes existants. Sauvegardez le cache à conserver avant de recréer le conteneur : un nouveau volume ne récupère pas les données de l’ancien conteneur. Les caches et authentifications restent privés, jamais intégrés à une image publiée.

## Mises à jour et dépannage

Conservez les volumes et le même worker lors des mises à jour : ils contiennent les sessions et les dépôts. N’utilisez pas docker compose down -v, docker volume prune ou docker commit sur un conteneur connecté.

Après une rotation de clé, remplacez ALLIN_WORKER_API_KEY dans les variables privées de Coolify et redéployez, ou dans .env puis recréez le conteneur Compose. Un simple redémarrage ne recharge pas les variables d’environnement.

Appliquer la nouvelle clé

```sh
docker compose up -d --force-recreate
```

- Worker en attente : terminez la connexion à Claude Code ou Codex dans le bon conteneur et ses volumes.
- Worker hors ligne ou erreur 401 : vérifiez ALLIN_URL, la clé active du worker et l’accès réseau depuis le serveur, sans afficher les secrets.
- Erreur GitHub 403 : vérifiez le compte utilisé, les dépôts autorisés, les permissions PR et l’approbation SSO. gh et le MCP GitHub utilisent des connexions distinctes.
- Erreur de sandbox Codex : utilisez le Compose officiel, son profil seccomp et apparmor=unconfined sur un hôte dédié. Recréez le conteneur après la fin des jobs en conservant les volumes, puis lancez allin-worker doctor codex en SSH. Ne désactivez pas le sandbox Codex.
