Omnara mit Docker Compose: Plattform für KI-Agenten selbst hosten

Bei Claude Managed Agents und der Agents API von OpenAI steuert der Modellhersteller die Agenten auf seiner Plattform. Omnara macht dasselbe als Open Source unter Apache 2.0, der Verlauf liegt in Ihrer PostgreSQL-Datenbank. Das Projekt hat rund 3.100 Sterne auf GitHub (Stand 22. Oktober 2026). Diese Anleitung betreibt cluster-v0.2.9 vom 21. Oktober 2026 mit Docker Compose, lokalem Sprachmodell und eigenem Linux-Rechner. Der Preis: zehn Dienste und eine junge 0.x-Reihe mit mehreren Releases pro Woche.

Voraussetzungen

• Linux-Server mit Docker Engine und Docker Compose Plugin, getestet mit Docker 29.8.2 und Docker Compose v5.5.1 unter Debian 12. Grundlagen: Docker Compose unter Linux.
• x86-64 oder ARM64 (Images für beide), getestet mit einem Intel Core i7-12700T ohne Grafikkarte.
• Arbeitsspeicher: Der Stack belegte im Test rund 0,45 GB, das lokale Sprachmodell zusätzlich 2,2 GB. Planen Sie mit lokalem Modell mindestens 4 GB, ohne 2 GB ein.
• Speicher: Omnara- und llama.cpp-Images belegten im Test rund 1,8 GB, die Modelldatei hat 3,5 GB. Planen Sie mindestens 10 GB ein.
• Domain mit Reverse Proxy und HTTPS, zum Beispiel Caddy, der den Host-Header weiterreicht.
• Für Befehle der Agenten ein zweiter Linux- oder macOS-Rechner, am besten eine Wegwerf-VM.

Eckdaten	Wert
Images	ghcr.io/omnara-ai/omnara-api:v0.2.9, dazu -worker, -maintenance, -web, -migrations
Port	8000/tcp nur auf 127.0.0.1 (nginx-Gateway)
Volumes	postgres-data, rustfs-data, memory-data, llama-models

Schritt 1: Projektordner und compose.yaml anlegen

Der Schnellstart des Projekts zieht latest, öffnet PostgreSQL und Valkey an allen Schnittstellen und nutzt feste Passwörter. Die Fassung hier pinnt alle Tags und gibt nur das nginx-Gateway auf 127.0.0.1 frei, das API-Pfade an die API und den Rest an die Weboberfläche leitet. Seine Konfiguration kommt vom Release-Tag:

mkdir -p ~/omnara && cd ~/omnara
curl -fsSLO https://raw.githubusercontent.com/omnara-ai/omnara/cluster-v0.2.9/gateway.nginx.conf

x-app-env: &app-env
  OMNARA_DATABASE_URL: postgres://omnara:${OMNARA_DB_PASSWORD:?OMNARA_DB_PASSWORD fehlt in .env}@postgres:5432/omnara?sslmode=disable
  OMNARA_REDIS_URL: redis://redis:6379/0
  OMNARA_PUBLIC_URL: ${OMNARA_PUBLIC_URL:?OMNARA_PUBLIC_URL fehlt in .env}
  OMNARA_ALLOW_INSECURE_DEV_DEFAULTS: "1"
  OMNARA_SECRET_ENCRYPTION_KEYS: ${OMNARA_SECRET_ENCRYPTION_KEYS:?OMNARA_SECRET_ENCRYPTION_KEYS fehlt in .env}
  OMNARA_SECRET_ENCRYPTION_ACTIVE_KEY_ID: ${OMNARA_SECRET_ENCRYPTION_ACTIVE_KEY_ID:?OMNARA_SECRET_ENCRYPTION_ACTIVE_KEY_ID fehlt in .env}
  OMNARA_SKILL_DOWNLOAD_SIGNING_KEY: ${OMNARA_SKILL_DOWNLOAD_SIGNING_KEY:?OMNARA_SKILL_DOWNLOAD_SIGNING_KEY fehlt in .env}
  OMNARA_MEMORY_DIR: /var/lib/omnara/memory

x-blob-env: &blob-env
  OMNARA_BLOB_S3_BUCKET: omnara
  OMNARA_BLOB_S3_REGION: us-east-1
  OMNARA_BLOB_S3_ENDPOINT: http://rustfs:9000
  OMNARA_BLOB_S3_ACCESS_KEY_ID: ${RUSTFS_ACCESS_KEY:?RUSTFS_ACCESS_KEY fehlt in .env}
  OMNARA_BLOB_S3_SECRET_ACCESS_KEY: ${RUSTFS_SECRET_KEY:?RUSTFS_SECRET_KEY fehlt in .env}
  OMNARA_BLOB_S3_USE_PATH_STYLE: "1"

services:
  redis:
    image: valkey/valkey:9.1.2-alpine
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "valkey-cli", "ping"]
      interval: 5s
      retries: 20

  postgres:
    image: postgres:18.6-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: omnara
      POSTGRES_PASSWORD: ${OMNARA_DB_PASSWORD}
      POSTGRES_DB: omnara
    volumes:
      - postgres-data:/var/lib/postgresql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U omnara -d omnara"]
      interval: 5s
      retries: 20

  rustfs:
    image: rustfs/rustfs:1.0.0
    command: /data
    restart: unless-stopped
    environment:
      RUSTFS_ACCESS_KEY: ${RUSTFS_ACCESS_KEY}
      RUSTFS_SECRET_KEY: ${RUSTFS_SECRET_KEY}
    volumes:
      - rustfs-data:/data
    healthcheck:
      test: ["CMD", "curl", "-f", "http://127.0.0.1:9000/health/ready"]
      interval: 5s
      retries: 20

  rustfs-init:
    image: rustfs/rustfs:1.0.0
    depends_on:
      rustfs:
        condition: service_healthy
    environment:
      RUSTFS_ACCESS_KEY: ${RUSTFS_ACCESS_KEY}
      RUSTFS_SECRET_KEY: ${RUSTFS_SECRET_KEY}
    entrypoint:
      - /bin/sh
      - -ec
      - |
        curl -fsS -o /dev/null -X PUT --aws-sigv4 'aws:amz:us-east-1:s3' --user "$$RUSTFS_ACCESS_KEY:$$RUSTFS_SECRET_KEY" http://rustfs:9000/omnara \
          || curl -fsS -o /dev/null -I --aws-sigv4 'aws:amz:us-east-1:s3' --user "$$RUSTFS_ACCESS_KEY:$$RUSTFS_SECRET_KEY" http://rustfs:9000/omnara
    command: []

  migrate:
    image: ghcr.io/omnara-ai/omnara-migrations:v0.2.9
    environment:
      OMNARA_DATABASE_URL: postgres://omnara:${OMNARA_DB_PASSWORD}@postgres:5432/omnara?sslmode=disable
    depends_on:
      postgres:
        condition: service_healthy

  api:
    image: ghcr.io/omnara-ai/omnara-api:v0.2.9
    restart: unless-stopped
    environment:
      <<: [*app-env, *blob-env]
      OMNARA_AUTH_SIGNUP_ENABLED: ${OMNARA_AUTH_SIGNUP_ENABLED:-1}
      OMNARA_DAEMON_RELEASE_URL: https://github.com/omnara-ai/omnara/releases/download/omnarad-stable
    volumes:
      - memory-data:/var/lib/omnara/memory
    depends_on:
      migrate:
        condition: service_completed_successfully
      redis:
        condition: service_healthy
      rustfs-init:
        condition: service_completed_successfully

  worker:
    image: ghcr.io/omnara-ai/omnara-worker:v0.2.9
    restart: unless-stopped
    environment:
      <<: [*app-env, *blob-env]
    volumes:
      - memory-data:/var/lib/omnara/memory
    depends_on:
      migrate:
        condition: service_completed_successfully
      redis:
        condition: service_healthy
      rustfs-init:
        condition: service_completed_successfully

  maintenance:
    image: ghcr.io/omnara-ai/omnara-maintenance:v0.2.9
    restart: unless-stopped
    environment:
      <<: *app-env
    volumes:
      - memory-data:/var/lib/omnara/memory
    depends_on:
      migrate:
        condition: service_completed_successfully
      redis:
        condition: service_healthy

  web:
    image: ghcr.io/omnara-ai/omnara-web:v0.2.9
    restart: unless-stopped

  gateway:
    image: nginxinc/nginx-unprivileged:1.29.5-alpine
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8080"
    volumes:
      - ./gateway.nginx.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      api:
        condition: service_started
      web:
        condition: service_started

volumes:
  postgres-data:
  rustfs-data:
  memory-data:

OMNARA_ALLOW_INSECURE_DEV_DEFAULTS steht auf 1, weil Omnara sonst HTTPS zum S3-Speicher verlangt und Modelle auf localhost ablehnt. Die unsicheren Ersatzwerte für Datenbank und Schlüssel greifen nicht, da alle gesetzt sind. Laut Quellcode landen außerdem Bestätigungsmails im Log, und Anfragen an localhost prüft die API nicht auf den Hostnamen. Für öffentlichen Betrieb beschreibt die Deployment-Anleitung externen S3-Speicher und SMTP.

Verifizieren: grep -c ':v0.2.9' compose.yaml ergibt 5, je ein Treffer für die fünf Omnara-Images.

Schritt 2: Schlüssel und .env erzeugen

Omnara verschlüsselt gespeicherte Zugangsdaten mit dem Schlüsselbund aus OMNARA_SECRET_ENCRYPTION_KEYS, ohne ihn sind sie nach einem Neuaufbau unbrauchbar. Der Block erzeugt alle Werte zufällig, die Domain ersetzen Sie durch Ihre:

cat > .env <<EOF
OMNARA_PUBLIC_URL=https://omnara.example.com
OMNARA_DB_PASSWORD=$(openssl rand -hex 24)
RUSTFS_ACCESS_KEY=omnara
RUSTFS_SECRET_KEY=$(openssl rand -hex 24)
OMNARA_SECRET_ENCRYPTION_ACTIVE_KEY_ID=key-2026-10
OMNARA_SECRET_ENCRYPTION_KEYS='{"key-2026-10":"$(openssl rand -base64 32)"}'
OMNARA_SKILL_DOWNLOAD_SIGNING_KEY=$(openssl rand -base64 32)
OMNARA_AUTH_SIGNUP_ENABLED=1
EOF
chmod 600 .env

Die API beantwortet nur Anfragen, deren Host-Header zu OMNARA_PUBLIC_URL passt, localhost ausgenommen.

Verifizieren: docker compose config -q && echo ok gibt ok aus.

Schritt 3: Omnara starten und Version prüfen

docker compose up -d --pull always
curl -s http://127.0.0.1:8000/healthz
docker inspect --format '{{.Config.Image}} {{index .Config.Labels "org.opencontainers.image.version"}}' \
  $(docker compose ps -q api worker maintenance web)

Erst legt der Einmal-Container migrate das Schema an, dann starten API, Worker und Wartungsdienst. Im Test antwortete die Neuinstallation nach 36 Sekunden:

{"status":"ok"}
ghcr.io/omnara-ai/omnara-api:v0.2.9 v0.2.9
ghcr.io/omnara-ai/omnara-maintenance:v0.2.9 v0.2.9
ghcr.io/omnara-ai/omnara-web:v0.2.9 v0.2.9
ghcr.io/omnara-ai/omnara-worker:v0.2.9 v0.2.9

Den Reverse Proxy richten Sie auf 127.0.0.1:8000, bei Caddy genügt im Caddyfile dieser Block:

omnara.example.com {
    reverse_proxy 127.0.0.1:8000
}

Im Test lief Omnara hinter einem Proxy mit HTTPS.

Verifizieren: docker compose ps -a zeigt migrate und rustfs-init mit Exit-Code 0, alle anderen Dienste laufen.

Schritt 4: Ersten Account anlegen und Registrierung schließen

Öffnen Sie https://omnara.example.com/signup und tragen Sie Ihre E-Mail-Adresse ein. Den Bestätigungslink schreibt die API ins Log:

docker compose logs api | grep verify-email

api-1  | https://omnara.example.com/verify-email?token=<gekürzt>

Über den Link vergeben Sie ein Passwort mit mindestens zwölf Zeichen. Danach gehört das Konto noch zu keiner Organisation. Legen Sie eine an, Omnara erzeugt dazu das Projekt Default. Damit sich niemand sonst registriert, schalten Sie die Registrierung ab:

sed -i 's/^OMNARA_AUTH_SIGNUP_ENABLED=1/OMNARA_AUTH_SIGNUP_ENABLED=0/' .env
docker compose up -d

Verifizieren: Ein POST auf /api/auth/signup wird jetzt abgewiesen, im Test mit HTTP 404 {"code":"not_found","error":"not found"}.

Schritt 5: Sprachmodell anbinden

Unter Models legen Sie Anbieter, Modell und Projektfreigabe an, mit Voreinstellungen für OpenAI, Anthropic und OpenRouter oder jedem Endpunkt im OpenAI- oder Anthropic-Format.

Lokale Modelle erreicht Omnara nur über localhost oder eine Loopback-Adresse. HTTP an den Dienstnamen llama lehnt die API ab, und laut Quellcode sperrt der Worker auch per HTTPS private Adressen wie die des Docker-Netzes:

{"code":"invalid_request","error":"invalid request: base_url must use https unless it targets localhost or a loopback IP: invalid model provider config"}

Deshalb nutzt der Worker das Netzwerk des llama.cpp-Containers und erreicht das Modell unter http://127.0.0.1:8090/v1. Andersherum ginge die Verbindung bei jedem Neustart des Workers verloren. Compose liest die compose.override.yaml automatisch mit:

# compose.override.yaml: llama.cpp mit einem Slot, der Worker nutzt dessen Netzwerk
services:
  llama:
    image: ghcr.io/ggml-org/llama.cpp:server-b11804
    restart: unless-stopped
    environment:
      LLAMA_ARG_HOST: 127.0.0.1
      LLAMA_ARG_PORT: "8090"
      LLAMA_ARG_HF_REPO: bartowski/google_gemma-4-E2B-it-GGUF
      LLAMA_ARG_HF_FILE: google_gemma-4-E2B-it-Q4_K_M.gguf
      LLAMA_ARG_CTX_SIZE: "32768"
      LLAMA_ARG_N_PARALLEL: "1"
      LLAMA_ARG_JINJA: "1"
    volumes:
      - llama-models:/root/.cache/huggingface
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:8090/health"]
      interval: 10s
      retries: 60

  worker:
    network_mode: "service:llama"
    depends_on:
      llama:
        condition: service_started
        restart: true

volumes:
  llama-models:

Danach starten Sie den Stack mit dem Override:

docker compose up -d --pull always

Gemma 4 E2B passt auf die CPU. llama.cpp teilt den Kontext durch die Slots, deshalb genau ein Slot. restart: true startet den Worker mit, wenn Compose llama.cpp neu startet. Im Test war das Modell nach 145 Sekunden geladen.

In Omnara folgt der Anbieter lokal-llama im Format OpenAI Chat Completions mit Basis-URL http://127.0.0.1:8090/v1, Platzhalter-Schlüssel und Leerlauf-Timeout 900.000 ms für langsame CPU-Antworten. Die Modellsuche der API erreicht llama.cpp nicht, legen Sie das Modell von Hand an: Name gemma-4-e2b, Slug gemma-4-e2b-it, 32.768 Token Kontext, 2.048 Ausgabetoken, Werkzeugnutzung an. Schreiben Sie die IP-Adresse statt localhost: Im ersten Testlauf löste localhost zur IPv6-Adresse ::1 auf, llama.cpp lauscht aber nur auf 127.0.0.1.

Verifizieren: docker compose exec llama curl -s http://127.0.0.1:8090/health liefert {"status":"ok"}, das Modell steht unter Models mit Freigabe für Ihr Projekt.

Schritt 6: Eigenen Rechner als Maschine verbinden

Agenten führen Befehle auf Maschinen aus: Sandboxen von Anbietern wie E2B oder eigene Rechner mit dem Daemon omnarad, der sich ausgehend verbindet. Unter Machines und Connect machine vergeben Sie den Namen lab-maschine und teilen die Maschine mit Ihrem Projekt. Den einmal angezeigten Token fügen Sie auf dem Zielrechner in den Installer ein:

curl -fsSL https://omnara.example.com/install/omnarad.sh | sh

Laut Dokumentation landet omnarad unter ~/.omnarad und läuft als systemd-Benutzerdienst, ohne systemd im Vordergrund. Ohne Terminal übergeben Sie den Token als Variable OMNARA_MACHINE_TOKEN, so lief der Daemon im Test in einem Debian-12-Container und war nach 25 Sekunden verbunden. Der Agent hat die Rechte dieses Benutzers, nehmen Sie nie Ihr Admin-Konto.

Verifizieren: Die Maschine steht unter Machines als verbunden, per API im Test:

[{"display_name":"lab-maschine","connection_state":"online","lifecycle_state":"active"}]

Schritt 7: Ersten Agenten mit Freigabe starten

Beim Anlegen eines Agenten fügen Sie die Konfiguration im YAML-Editor ein. Sie erlaubt nur Befehle auf lab-maschine, jeder wartet auf Ihre Freigabe. Laut Dokumentation laufen eingebaute Werkzeuge ohne always_ask sofort. Zu einer Maschine ergänzt Omnara Prozess- und Dateiwerkzeuge, die Konfiguration schaltet Prozesse sowie Up- und Download ab. Dateien lesen und auflisten blieb im Test erlaubt.

version: v1
instruction: |
  Sie sind ein Assistent für Linux-Administration. Führen Sie Befehle nur auf
  der Maschine lab-maschine aus und antworten Sie kurz auf Deutsch.
model:
  provider_config: lokal-llama
  name: gemma-4-e2b
tools:
  run_command:
    permission:
      mode: always_ask
  write_process: { enabled: false }
  read_process: { enabled: false }
  stop_process: { enabled: false }
  list_processes: { enabled: false }
  upload_file: { enabled: false }
  download_file: { enabled: false }
machine_sources:
  - machine_name: lab-maschine
    cwd: /tmp

Die erste Nachricht im Test: „Führen Sie auf lab-maschine den Befehl cat /etc/os-release aus und nennen Sie den Wert von PRETTY_NAME.“ Der Agent hält vor dem Befehl an, Sie geben ihn in der Agentenansicht mit Allow frei. Im Test übergab das Modell zuerst den Namen statt der ID der Maschine, las nach der Meldung malformed public id die Maschinenliste und startete den Befehl erneut. Mit Freigabe dauerte das auf der CPU 77 Sekunden, die Antwort:

Der Wert von `PRETTY_NAME` ist: Debian GNU/Linux 12 (bookworm).

Verifizieren: Die Agentenansicht zeigt Befehle, Ausgabe und Antwort. docker compose logs llama | grep -c 'exceeds the available context size' ergibt 0.

Schritt 8: Backup anlegen

Die Daten liegen in PostgreSQL (Agenten, Verläufe, verschlüsselte Secrets), im Memory-Verzeichnis und in RustFS (Anhänge, Werkzeugausgaben). Das Memory-Verzeichnis gehört laut Dokumentation immer mit PostgreSQL gesichert. Für einen konsistenten Stand halten Sie die Omnara-Dienste kurz an:

mkdir -p backup
docker compose stop api worker maintenance
docker compose exec -T postgres pg_dump -U omnara -d omnara -Fc > backup/omnara-db.dump
docker run --rm --volumes-from "$(docker compose ps -aq api)" -v "$PWD/backup:/backup" alpine:3.24.3 \
  tar czf /backup/omnara-memory.tgz -C /var/lib/omnara/memory .
docker run --rm --volumes-from "$(docker compose ps -aq rustfs)" -v "$PWD/backup:/backup" alpine:3.24.3 \
  tar czf /backup/omnara-blobs.tgz -C /data .
cp .env backup/omnara.env
docker compose start api worker maintenance

--volumes-from findet die Volumes unabhängig vom Projektnamen. Die .env enthält den Schlüsselbund, legen Sie das Backup deshalb verschlüsselt ab.

Verifizieren: ls -lh backup zeigt vier Dateien, im Test:

-rw-r--r-- 1 root root 5.5K Oct 22 19:39 omnara-blobs.tgz
-rw-r--r-- 1 root root 471K Oct 22 19:39 omnara-db.dump
-rw-r--r-- 1 root root  475 Oct 22 19:39 omnara-memory.tgz
-rw------- 1 root root  467 Oct 22 19:39 omnara.env

Schritt 9: Wiederherstellung nach Totalverlust

Nach einem Totalverlust (im Test docker compose down -v) starten Sie erst Datenbank und RustFS, spielen den Dump ein und füllen die Volumes, bevor Omnara startet. docker compose create api legt das Memory-Volume an, ohne den Dienst zu starten. Auf einem neuen Server liegen vorher Compose-Dateien, gateway.nginx.conf und die gesicherte .env im Projektordner.

docker compose up -d --wait postgres rustfs
docker compose exec -T postgres pg_restore -U omnara -d omnara --exit-on-error < backup/omnara-db.dump
docker compose stop rustfs
docker compose create api
docker run --rm --volumes-from "$(docker compose ps -aq api)" -v "$PWD/backup:/backup:ro" alpine:3.24.3 \
  tar xzf /backup/omnara-memory.tgz -C /var/lib/omnara/memory
docker run --rm --volumes-from "$(docker compose ps -aq rustfs)" -v "$PWD/backup:/backup:ro" alpine:3.24.3 \
  tar xzf /backup/omnara-blobs.tgz -C /data
docker compose up -d

Das Sprachmodell lädt llama.cpp danach neu herunter.

Verifizieren: Anmeldung, Projekte, Secrets, Modellanbieter, Maschine, Agentenverlauf, die Datei im Memory-Store und persönliche Tokens sind wieder da. Im Test:

projekte: ["Marker Projekt","Default"]
secrets: ["llama-dummy"]
provider: [{"name":"lokal-llama","base_url":"http://127.0.0.1:8090/v1"}]
maschinen: [{"display_name":"lab-maschine","connection_state":"online"}]
memory-datei: MARKER-OMNARA-1792697859
Agentenverlauf nach Restore: Debian GNU/Linux 12 (bookworm)
alte Sitzung nach Restore: HTTP 200

Schritt 10: Update auf eine neue Version

Zum Release cluster-v0.2.9 gehören die Image-Tags v0.2.9. Lesen Sie vorher die Release Notes, vergleichen Sie compose.yaml und gateway.nginx.conf des neuen Tags (von v0.2.8 auf v0.2.9 gleich) und sichern Sie. Im Test mit Bestand v0.2.8 und lokalem Modell:

sed -i -E 's#(ghcr.io/omnara-ai/omnara-[a-z]+):v0.2.8#\1:v0.2.9#' compose.yaml
docker compose pull
docker compose up -d

migrate spielt neue Schemaänderungen ein, bevor die Dienste starten, von v0.2.8 auf v0.2.9 die Migration 000054_machine_connection_state_current_runtime:

{"time":"2026-10-22T19:38:12.017224662Z","level":"info","message":"database migrations applied"}

Verifizieren: docker inspect wie in Schritt 3 zeigt v0.2.9. docker compose exec -T postgres psql -U omnara -d omnara -Atc 'select max(version_id) from goose_db_version' meldete im Test 53 vor und 54 nach dem Update. Sitzung, Daten und Maschine blieben erhalten.

Troubleshooting

Symptom	Ursache und Lösung
required variable OMNARA_DB_PASSWORD is missing a value: OMNARA_DB_PASSWORD fehlt in .env	.env fehlt oder ein Wert ist leer. Datei wie in Schritt 2 anlegen.
Weboberfläche lädt, Anmeldung und API antworten mit 404	Der Proxy schickt einen anderen Host als in OMNARA_PUBLIC_URL (Test: HTTP 404 {"code":"not_found","error":"not found"}). Host durchreichen oder Adresse korrigieren.
{"code":"csrf_check_failed","error":"csrf check failed"} bei Anmeldung per Skript	Anmeldung und Registrierung verlangen einen Origin-Header mit der öffentlichen Adresse, bei curl -H 'Origin: https://omnara.example.com'.
base_url must use https unless it targets localhost or a loopback IP	Modell über einen Dienstnamen im Docker-Netz eingetragen. Lokale Modelle wie in Schritt 5 über 127.0.0.1 anbinden, entfernte per HTTPS mit öffentlicher Adresse.
API startet ständig neu, im Log OMNARA_SKILL_DOWNLOAD_SIGNING_KEY must be base64-encoded: illegal base64 data at input byte 4	Signierschlüssel in der .env beschädigt (Base64, 32 Byte). Wert aus der gesicherten .env holen, den Schlüsselbund nie neu erzeugen.

Häufige Fragen

Was unterscheidet Omnara von Claude Managed Agents?

Bei Claude Managed Agents betreibt Anthropic die Agentensteuerung für Claude, nur die Sandbox darf laut Anthropic auf eigener Infrastruktur laufen. Bei Omnara liegen Steuerung und Verlauf auf Ihrem Server, mit jedem kompatiblen Modell. Updates, Backups und Überwachung übernehmen Sie selbst.

Reicht ein lokales Modell auf der CPU?

Für einen Funktionstest ja, eine einfache Aufgabe dauerte 77 Sekunden. Für echte Arbeit nehmen Sie ein größeres Modell mit Grafikkarte oder einen Cloud-Anbieter.

Fazit

Omnara bringt verwaltete Agenten auf eigene Server und läuft mit wenigen Anpassungen unter Docker Compose. Freigaben für Befehle und ausgehend verbundene Maschinen passen zu kleinen Teams, die Agenten kontrolliert auf eigene Rechner lassen. Bei der jungen 0.x-Reihe gehören häufige Updates mit Backup vorab zum Betrieb.

Weiterführende Anleitungen und Quellen

• Docker Compose unter Linux als Grundlage für Selfhosting
• Docker Compose absichern: Secrets, Healthchecks und Non-Root
• KI-Agenten absichern: Prompt-Injection abwehren
• OpenHands mit Docker und Ollama selbst betreiben
• Omnara auf GitHub und Release Notes cluster-v0.2.9
• Omnara-Dokumentation: Konfiguration und Maschine verbinden
• Anthropic: Claude Managed Agents im Überblick