Mehrere KI-Agenten auf einem VPS mit einem OpenClaw-Stack betreiben

Warum dieses Setup für Camphire relevant ist

Bei Camphire sehen wir in Projekten immer wieder denselben Fehler: Teams starten mit einem Agenten, bauen dann den zweiten und dritten dazu und verlieren sofort die Kontrolle über Netzwerkgrenzen, Credentials und Logs. Ein einzelner VPS kann für viele Workloads reichen - aber nur mit einer sauberen Architektur.

Dieser Leitfaden zeigt ein Setup, mit dem mehrere spezialisierte KI-Agenten auf einem Server laufen, ohne dass Sessions, Dateien oder Zugangsdaten durcheinandergeraten.

Das Kernprinzip: ein Ingress, mehrere isolierte Dienste

Die robuste Standardarchitektur ist einfach:

• ein offentlich erreichbarer Reverse Proxy (z. B. Caddy oder Nginx)
• ein privates Docker-Netzwerk für Agenten-Container
• ein eigener Workspace pro Agent
• getrennte Auth-Profile und Token je Agent
• gemeinsame Beobachtbarkeit (Logs, Health, Alarme)

Damit bleibt die Bedienung einfach, wahrend die Isolation erhalten bleibt.

Schritt 1: VPS absichern, bevor Agenten starten

Bevor du OpenClaw oder Agenten installierst, sollte der Host gehartet sein:

• SSH nur mit Keys
• Root-Login deaktivieren
• automatische Sicherheitsupdates aktivieren
• Firewall-Regeln auf notwendige Ports beschranken
• Backups für Konfiguration und Volumes planen

Für viele Camphire-Projekte ist nicht der Agent selbst das Risiko, sondern ein unsauberer Host mit zu vielen offenen Ports.

Schritt 2: Verzeichnisstruktur für Isolation festlegen

Wir empfehlen eine Struktur, die sofort sichtbar macht, welcher Agent wohin schreibt:

• /srv/openclaw/gateway
• /srv/agents/sales-bot
• /srv/agents/support-bot
• /srv/agents/research-bot
• /srv/shared/observability

Wichtig: Kein gemeinsames Arbeitsverzeichnis für mehrere Agenten, wenn Schreibzugriffe erlaubt sind.

Schritt 3: Compose-Muster für mehrere Agenten nutzen

Ein wiederholbares Compose-Muster ist besser als individuelle Sonderlosungen. Jeder Agent bekommt:

• eigenen Container-Namen
• eigenes Volume/Workspace
• eigene Umgebungsvariablen
• eigenes Auth-Profil
• explizite Restart-Policy

services:
  agent-support:
    image: openclaw-agent:latest
    environment:
      - AGENT_NAME=support
    volumes:
      - /srv/agents/support-bot:/workspace
    networks: [app_private]

Schritt 4: Ein Reverse Proxy als offentliche Grenze

Der Reverse Proxy ubernimmt TLS, Routing und Basis-Schutz. Praktische Regeln:

• nur der Proxy exponiert Ports nach aussen
• Agenten laufen nur im privaten Netzwerk
• Rate-Limits für sensible Endpunkte
• Request-Size-Limits für Uploads
• klare Hostnamen/Routes pro Agent oder pro Channel

Das reduziert Betriebsfehler massiv, weil neue Agenten nicht direkt ins Internet gestellt werden.

Schritt 5: Credential-Strategie bewusst entscheiden

Viele Multi-Agent-Setups scheitern an Tokens. Best Practice für Produktion:

• ein Token pro Integration und Agent (nicht ein globaler Token)
• kurze Laufzeiten, wo moglich
• dokumentierte Rotation
• Secrets nie im Workspace speichern
• .env nur serverseitig, nie in Repos committen

Wenn ein Agent kompromittiert wird, darf nicht die ganze Plattform betroffen sein.

Schritt 6: Observability und Guardrails früh einbauen

Mindestens diese Signale solltest du sehen:

• Container-Health pro Agent
• Restart-Haufigkeit
• Fehlerrate pro Kanal/Tool
• Latenz und Queue-Rückstand
• Token-/Auth-Fehler nach Integration

Erganzend sinnvoll:

• strukturierte Logs mit Agent-ID
• Alerting auf Crash-Loops
• einfache Health-Checks über Reverse Proxy

Haufige Fehler in Multi-Agent-VPS-Setups

• Ein gemeinsames Verzeichnis für alle Agenten
• Zu breite Netzwerkfreigaben zwischen Services
• Ein einziger API-Key für alle Integrationen
• Kein Logging pro Agent
• Keine Limits für Speicher/CPU
• Keine klare Ownership für Deployments

Skalierung ohne Rebuild der Architektur

Wenn das Setup sauber ist, skaliert man schrittweise:

• zuerst mehr Agenten auf gleichem Host
• dann Trennung nach Kritikalitat (z. B. Kommunikation vs. Build-Agenten)
• danach dedizierte Hosts für schwere Workloads

Das ist deutlich gunstiger als fruhes Overengineering und vermeidet gleichzeitig das spate "Alles neu bauen".

Fazit

Mehrere KI-Agenten auf einem VPS sind kein Hack, sondern ein solides Produktionsmodell - wenn Isolation, Auth und Observability von Anfang an stimmen. Genau diese drei Punkte entscheiden, ob ein Team schnell liefert oder in Sicherheits- und Betriebsproblemen stecken bleibt.