# Einen Allin-Worker installieren — Coolify Stellen Sie Ihren Worker mit Coolify oder Docker Compose bereit und melden Sie sich auf dem Server bei Claude Code, Codex und GitHub an. ## Vor der Bereitstellung Diese Anleitung installiert einen Worker für Ihren Allin-Workspace, keinen neuen Allin-Server. Das öffentliche Image enthält das Allin-Paket, Claude Code, Codex und GitHub CLI. - Bereiten Sie einen Linux-amd64-Server mit Docker und SSH-Zugang vor. Bei Verwendung von Coolify muss der Server bereits mit Coolify verbunden sein. - Erstellen Sie unter Allin → Workers einen Worker vom Typ Container, wählen Sie seine Agenten aus und kopieren Sie seinen Schlüssel. Prüfen Sie wartende Jobs: Sie können starten, sobald eine Engine angemeldet ist. - ALLIN_URL ist die vom Container erreichbare Adresse Ihrer Allin-Instanz. ALLIN_WORKER_API_KEY ist der Schlüssel dieses Workers. Starten Sie nicht zwei Container mit demselben Schlüssel. - Der Server muss Allin, GHCR, die Dienste der gewählten Engine und bei Bedarf GitHub erreichen können. Remote-MCP-Integrationen werden vom Allin-Server aufgerufen. Ersetzen Sie USER, WORKER_HOST, WORKER_CONTAINER und PASTE_YOUR_WORKER_KEY_HERE. Fordern Sie den Benutzer nicht auf, Geheimnisse in den Chat einzufügen: Verwenden Sie private Coolify-Variablen. Der Benutzer muss die Browser-Anmeldung abschließen. Holen Sie die Zustimmung des Benutzers ein, bevor Sie kostenpflichtige Ressourcen erstellen oder kostenpflichtige Jobs starten. Diese Anleitung autorisiert keine Ausgaben. ## Worker auf Coolify bereitstellen Erstellen Sie eine Docker-Compose-Ressource in Coolify und fügen Sie die folgende Datei ein. Sie enthält das Sicherheitsprofil; auf dem Server muss keine zusätzliche Datei erstellt werden. [Coolify-Compose herunterladen](https://tryallin.com/downloads/allin-worker.coolify.compose.yaml) Legen Sie in Coolify ALLIN_URL und ALLIN_WORKER_API_KEY als Laufzeitvariablen fest. Worker konfigurieren ```dotenv ALLIN_URL=https://tryallin.com ALLIN_WORKER_API_KEY=PASTE_YOUR_WORKER_KEY_HERE ``` Behalten Sie die vier persistenten Volumes. Dieser Worker benötigt weder Domain noch öffentlichen Port oder HTTP-Healthcheck. - /workspace - /home/node/.claude - /home/node/.codex - /home/node/.config/gh Bereitstellen. Der Container wartet auf eine Claude-Code- oder Codex-Anmeldung, bevor er Jobs übernimmt. ## Auf welcher Maschine führe ich die Befehle aus? Wenn der Worker auf einem entfernten Server läuft, verbinden Sie sich zuerst per SSH mit diesem Server. Führen Sie alle folgenden Claude-, Codex- und GitHub-Befehle in diesem entfernten Terminal aus, nicht auf Ihrem Computer. Mit dem Worker-Server verbinden ```sh ssh USER@WORKER_HOST docker ps --format "table {{.Names}}\t{{.Image}}" ``` Ersetzen Sie WORKER_CONTAINER durch den von Coolify bereitgestellten Containernamen. Verwenden Sie docker exec, um genau dessen Volumes zu nutzen; starten Sie kein separates Compose-Projekt zur Anmeldung. Öffnen Sie die Anmeldelinks im Browser Ihres Computers. Geben Sie bei Bedarf den angezeigten Code ein und kehren Sie dann zum Terminal des Workers zurück. Die Zugangsdaten bleiben auf dem Worker-Server. Verwenden Sie bei einem lokalen Worker dessen lokales Terminal. Verbinden Sie zuerst GitHub, wenn Ihre Agenten es verwenden. Jobs können starten, sobald eine Engine angemeldet ist. Melden Sie sich je nach den für Ihre Agenten gewählten Engines bei Claude Code und/oder Codex an. Starten Sie den Worker nach dem Hinzufügen eines Kontos neu, damit er die neue Engine erkennt. ## GitHub zum Klonen von Repositories Die gh-Anmeldung dient Git zum Klonen von Repositories. Sie ersetzt nicht die Zugangsdaten des GitHub-MCP-Connectors in Allin. GitHub-Anmeldung ```sh docker exec -it WORKER_CONTAINER gh auth login --hostname github.com --git-protocol https --web docker exec -it WORKER_CONTAINER gh auth setup-git --hostname github.com docker exec -it WORKER_CONTAINER gh auth status --hostname github.com ``` GitHub CLI ist im Image installiert. Melden Sie sich mit dem im Terminal angezeigten Code an; das Volume github-config speichert Ihre Anmeldung. Wenn GH_TOKEN oder GITHUB_TOKEN im Container oder auf dem Rechner gesetzt ist, verwendet gh vorrangig dieses Token. Prüfen Sie das zugehörige Konto, ohne das Token anzuzeigen oder zu teilen. Um gh in einem Job zu nutzen, aktivieren Sie „Befehle ausführen“ im Agent-Profil und erstellen Sie einen neuen Job. ## Claude-Konto des Workers Claude-Anmeldung ```sh docker exec -it WORKER_CONTAINER claude auth login --claudeai docker exec -it WORKER_CONTAINER claude auth status docker exec -it WORKER_CONTAINER allin-worker doctor claude ``` Öffnen Sie den Link aus dem Terminal, melden Sie sich bei Claude an und fügen Sie bei Aufforderung den Rückgabecode im Terminal ein. Warten Sie auf „Login successful“. Das Volume claude-config speichert Anmeldung und Sitzungen. Behalten Sie es beim Neuerstellen des Containers. ## Codex-Konto des Workers Melden Sie sich bei der für Ihre Agenten gewählten Engine an. Aktivieren Sie für Codex die Gerätecode-Anmeldung in den ChatGPT-Sicherheitseinstellungen und öffnen Sie den Link im Terminal. Codex-Anmeldung ```sh docker exec -it WORKER_CONTAINER codex login --device-auth docker exec -it WORKER_CONTAINER codex login status docker exec -it WORKER_CONTAINER allin-worker doctor codex ``` Das Volume codex-config speichert die Codex-Anmeldung und Sitzungen. Es bleibt privat und ist nie Teil des veröffentlichten Images. [Offizielle Dokumentation](https://developers.openai.com/codex/auth/#login-on-headless-devices) ## GitHub für MCP-Tools und Reviews Jobs verwenden die in Allin autorisierte GitHub-Verbindung. Aktualisieren Sie deren Zugangsdaten unter Verbindungen und prüfen Sie die aktivierten und im Agentenprofil erlaubten Tools. [Allin-Verbindungen öffnen](https://tryallin.com/app#connections) - Konto und Token benötigen Zugriff auf die betreffenden Repositories. Wählen Sie bei einem fein abgestuften Token den richtigen Eigentümer und die richtigen Repositories. - Contents: Read zum Lesen von Code. Pull requests: Read für PRs und deren Dateien, Read and write zum Erstellen oder Veröffentlichen einer Review, auch im Status PENDING. - Falls die Organisation dies verlangt, lassen Sie das Token oder die App genehmigen und autorisieren Sie den SSO-Zugriff. Lesbarer Code bestätigt nicht, dass das Token PRs lesen oder Reviews erstellen kann. Korrigieren Sie die Berechtigungen der verwendeten Verbindung und lesen Sie die PR erneut. Erfolgreiches Lesen bestätigt keinen Schreibzugriff. [GitHub-Berechtigungen für Reviews](https://docs.github.com/en/rest/pulls/reviews#create-a-review-for-a-pull-request) Im Agent-Profil können Sie auch Modell, Denkaufwand, Dateizugriff und Unteragenten festlegen. ## Verbindung prüfen Der doctor-Befehl prüft Engine und Anmeldung; doctor codex führt auch echte Befehle in den Sandboxes read-only und workspace-write aus. Weder Modell noch Allin-API werden aufgerufen. Das Badge Verbunden bestätigt den Worker-Heartbeat. Verbunden bedeutet nicht, dass alle Engines verfügbar sind. In preview.4 wird Codex bei einem fehlgeschlagenen Starttest ausgeschlossen: Claude kann laufen, während Codex-Jobs warten. Prüfen Sie die Logs und starten Sie den Worker nach der Korrektur neu, sobald laufende Jobs beendet sind. Schließen Sie die Anmeldungen vor dem Start ab. Falls auf dem Worker bereits Jobs laufen, warten Sie vor dem Neustart auf deren Abschluss. Führen Sie diese Befehle per SSH auf dem Server aus, nicht im Container-Terminal. Sie können den Dienst auch in Coolify neu starten und dort seine Logs ansehen. Starten und Logs verfolgen ```sh docker restart WORKER_CONTAINER docker logs --tail=50 -f WORKER_CONTAINER ``` Nach dem Start kann der Worker wartende Jobs mit autorisierten Konten und Tools ausführen. Allin MCP wird automatisch konfiguriert. Prüfen Sie unter Allin → Workers den Status Verbunden und die zugewiesenen Agenten. Prüfen Sie jede Engine mit doctor und den Worker-Logs. Konfigurieren Sie dort die Repositories. Ein Testjob prüft anschließend den gesamten Ablauf, mit Ihrer Zustimmung zu den Nutzungskosten. ## Codex auf Ubuntu: AppArmor-Einschränkung des Hosts Auf neueren Ubuntu-Versionen reicht apparmor=unconfined in Compose möglicherweise nicht aus. Meldet bwrap „loopback: Failed RTM_NEWADDR: Operation not permitted“, prüfen Sie auf dem Host Ablehnungen des Profils unprivileged_userns für setpcap oder net_admin. Ein erfolgreicher unshare -U-Test prüft nicht die gesamte Sandbox. Diagnose auf dem Server über 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' ``` Ersetzen Sie WORKER_CONTAINER durch den tatsächlichen Containernamen. Verwenden Sie mit Codex 0.160.0 codex sandbox -- true, ohne linux hinzuzufügen. Der Worker muss als node (uid 1000) laufen. Prüfen Sie vor Anwendung des folgenden Profils den Pfad des mitgelieferten bwrap. Bestätigen die Logs diese Einschränkung, kann ein Administrator dieses gezielte Profil auf dem Ubuntu-Host außerhalb des Containers installieren. Es erlaubt userns für das mit Codex gelieferte bwrap, ohne die Einschränkung hostweit zu deaktivieren. Diese Ausnahme wurde mit dem Image preview.4 auf Ubuntu validiert; prüfen Sie Pfad und Diagnose nach einem Update erneut. Host-Profil /etc/apparmor.d/codex-bwrap ```text abi , include profile codex-bwrap /usr/local/lib/node_modules/@openai/codex/**/codex-resources/bwrap flags=(unconfined) { userns, include if exists } ``` Profil laden und Codex prüfen ```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 ``` Starten Sie nach erfolgreicher Diagnose und Codex-Anmeldung den Worker neu, sobald laufende Jobs beendet sind: verfügbare Engines werden beim Start erkannt. Behalten Sie seccomp, cap_drop: ALL, no-new-privileges und die Codex-Sandbox bei. Dokumentieren Sie die AppArmor-Ausnahme; deaktivieren Sie die userns-Einschränkung des Hosts nicht global. [Offizielle Dokumentation der Codex-Sandbox](https://learn.chatgpt.com/docs/sandboxing) ## Job-Dateien und persistenter Speicher Legen Sie Repositories, Dokumente und zwischen Jobs geteilte Daten unter /workspace ab, das im offiziellen Compose durch ein Volume gesichert ist. Nutzen Sie /tmp für temporäre Dateien. Der Zugriff auf Pfade unter /home/node hängt von Sandbox und Berechtigungen ab: speichern Sie dort keine Arbeitsdokumente der Agenten. Persistenz und Sandbox-Zugriff sind getrennt. Ein Volume bewahrt Dateien beim Neuerstellen des Containers, erteilt Codex aber keine zusätzlichen Rechte. Dateien außerhalb von Volumes gehen beim erneuten Deployment verloren. /home/node/.cache ist im offiziellen Compose nicht persistent. Optionales Cache-Volume: in das vorhandene Compose einfügen ```yaml services: worker: volumes: - worker-cache:/home/node/.cache volumes: worker-cache: ``` Ergänzen Sie diesen Mount und die Volume-Deklaration, ohne bestehende Volumes zu ersetzen. Sichern Sie benötigte Cache-Daten vor dem Neuerstellen des Containers: ein neues Volume übernimmt keine Daten aus dem alten Container. Caches und Anmeldedaten bleiben privat und gehören niemals in ein veröffentlichtes Image. ## Updates und Fehlerbehebung Behalten Sie bei Updates die Volumes und denselben Worker bei: Sie enthalten Sitzungen und Repositories. Verwenden Sie bei einem angemeldeten Container weder docker compose down -v noch docker volume prune oder docker commit. Ersetzen Sie nach einer Schlüsselrotation ALLIN_WORKER_API_KEY in den privaten Coolify-Variablen und stellen Sie den Dienst neu bereit, oder aktualisieren Sie .env und erstellen Sie den Compose-Container neu. Ein einfacher Neustart lädt keine neuen Umgebungsvariablen. - Worker wartet: Schließen Sie die Anmeldung bei Claude Code oder Codex im richtigen Container mit seinen Volumes ab. - Worker offline oder Fehler 401: Prüfen Sie ALLIN_URL, den aktiven Worker-Schlüssel und den Netzwerkzugriff vom Server, ohne Geheimnisse anzuzeigen. - GitHub-Fehler 403: Prüfen Sie das Konto, die erlaubten Repositories, PR-Berechtigungen und die SSO-Freigabe. gh und der GitHub-MCP verwenden separate Verbindungen. - Codex-Sandbox-Fehler: Verwenden Sie das offizielle Compose, sein seccomp-Profil und apparmor=unconfined auf einem dedizierten Host. Erstellen Sie den Container nach Abschluss der Jobs unter Beibehaltung der Volumes neu. Führen Sie dann allin-worker doctor codex per SSH aus. Deaktivieren Sie die Codex-Sandbox nicht.