Einen Allin-Worker installieren

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.

Docker Compose

Claude Code, Codex und das Allin-Paket sind im Image installiert. Bewahren Sie compose.yaml und .env im selben Ordner auf.

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

Docker Compose herunterladen

Docker-Profil herunterladen

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

Legen Sie allin-worker.seccomp.json neben compose.yaml ab. Das seccomp-Profil und die AppArmor-Ausnahme ermöglichen die Codex-Sandbox. Verwenden Sie einen dedizierten Host: Nur für diesen Container ist AppArmor deaktiviert. Er bleibt unprivilegiert, ohne Root-Rechte und Fähigkeiten, mit no-new-privileges.

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

Ersetzen Sie PASTE_YOUR_WORKER_KEY_HERE durch den aus Allin kopierten Schlüssel. Teilen Sie diese Datei nicht.

chmod 600 .env
docker compose pull

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.

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

Ersetzen Sie USER, WORKER_HOST und den Pfad durch die Angaben Ihrer Installation. Verwenden Sie bei Docker den Ordner mit compose.yaml und .env dieses Workers, damit seine Authentifizierungsvolumes verwendet werden.

Ö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.

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 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

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

Ö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.

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

Das Volume codex-config speichert die Codex-Anmeldung und Sitzungen. Es bleibt privat und ist nie Teil des veröffentlichten Images.

Offizielle Dokumentation

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

• 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

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.

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

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.

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.

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>
}

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

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.

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.

docker compose up -d --force-recreate

• 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.