OpenBot-KI-Mitarbeiter selbst auf einem VPS hosten

Was Sie beim Self-Hosting von OpenBot-KI-Mitarbeitern erhalten

Sie hosten OpenBot-KI-Mitarbeiter selbst, indem Sie einen Gateway-Server sowie pro Bot einen Container auf von Ihnen kontrollierter Hardware betreiben. Jeder Bot-Container enthält einen eigenen Chromium-Browser und ein eigenes Workspace-Volume. Das Browserprofil bleibt zwischen den Sitzungen erhalten. Jede Aktion, die ein Bot auf einem Computer, in einer Datei, auf einem MCP-Server (Model Context Protocol) oder in einer UI-Komponente ausführt, läuft über dieses Gateway. Das Gateway prüft die Aktion vor der Ausführung anhand einer Richtlinie und protokolliert sie anschließend. Wenn der vom Gateway umschlossene Agenten-Loop für Sie noch ungewohnt ist, führt Sie der schrittweise Pfad in KI-Agenten von Grund auf lernen zunächst durch die Erstellung eines kleinen eigenen Agenten. Erst danach geben Sie einem Bot Zugriff auf einen Browser und Ihre Anmeldedaten.

OpenBot wird von CopilotKit unter der MIT-Lizenz unter github.com/CopilotKit/openbot veröffentlicht. Die erste getaggte Version, v0.0.1, wurde am 17 August 2026 veröffentlicht. Das Projekt bezeichnet sich selbst als Alpha-Version und befindet sich in aktiver Entwicklung. Behandeln Sie es als durchdachtes Konzept mit noch unausgereiften Bereichen.

Der interessante Teil dieser Architektur ist zugleich der kostenintensive. Ein Browser pro Agent verursacht den Speicherbedarf, den viele bei der Planung übersehen. Deshalb steht hier die Dimensionierung vor der Installation.

Wie das Gateway jede Aktion entscheidet

Der API-Server auf Port 3001 ist der einzige Zugriffsweg zum Computer eines Bots. Bevor eine Browseraktion ausgeführt wird, ermittelt das Gateway das Ziel aus einem Seitensnapshot, wertet CEL-Regeln (Common Expression Language) anhand des Kontexts aus, schreibt eine Audit-Zeile mit der Entscheidung und ruft erst danach den Container auf. Wenn die Ausführung danach fehlschlägt, schreibt es eine zweite Zeile. Die Dokumentation beschreibt diese Grenze eindeutig: Der Computer entscheidet nicht über Richtlinien, sondern das Server-Gateway bildet die Aktionsgrenze. Diese Trennung hat außerhalb von OpenBot einen eigenen Namen, denn die Schleife, die Tool-Definitionen, die Berechtigungsprüfungen und der Sitzungsstatus bilden zusammen das um ein Modell gelegte Harness, und dieses Gateway ist die Berechtigungshälfte davon.

Die Richtlinie verweigert standardmäßig, und Verweigerungsregeln werden vor Genehmigungsregeln ausgewertet. Die Richtung eines Fehlers ist wichtiger als die Syntax der Regel. Eine fehlende Richtlinie erlaubt nichts, und eine fehlerhafte Regel führt immer zu einer Blockierung, unabhängig davon, ob es sich um eine Verweigerungs- oder Genehmigungsregel handelt. Ein Fehler in Ihrer Richtlinie führt daher zu einem blockierten Bot und nicht zu einem Bot, der unkontrollierten Zugriff auf Ihre Konten hat. Diese Schicht steuert, was ein Bot tut, nicht was er liest. Eine Seite mit Anweisungen für den Agenten bleibt daher ein separates Problem. Es handelt sich um dieselbe Prompt-Injection-Angriffsfläche, die entsteht, wenn Sie einem Agenten Ergebnisse Ihrer eigenen SearXNG-Instanz übergeben.

Der Audit-Trail liegt in PostgreSQL und bleibt daher nach einem Neustart erhalten. Steuerungsübergaben werden als computer.help_requested, computer.control_taken und computer.control_released aufgezeichnet. Dadurch sehen Sie, wann ein Bot einen Menschen anfordert und wann der Mensch die Kontrolle zurückgibt. Secrets werden als Zeichenanzahl und niemals als Werte aufgezeichnet. Dateioperationen erfassen den Pfad und die Größe, niemals den Inhalt. Wenn Sie dieselbe Kontrollgrenze ohne dahinterliegenden Browser benötigen, behandelt AI-Agent-Aktionen hinter Genehmigungen zu schalten diesen engeren Anwendungsfall.

Kosten eines einzelnen Bots bei RAM und Festplatte

Das Projekt veröffentlicht gemessene Werte für einen einzelnen Bot auf arm64. Das sind die einzigen Größenangaben, die OpenBot bereitstellt. Sie beschreiben einen Bot auf einer Architektur und sind daher als Ausgangspunkt zu verstehen, nicht als Kapazitätsplanung.

[
  {
    "label": "Measured, one Bot",
    "memory_gb": 0.55,
    "disk_gb": 5.3,
    "vcpu": 0.06
  },
  {
    "label": "Documented minimum",
    "memory_gb": 2,
    "disk_gb": 8,
    "vcpu": 1
  },
  {
    "label": "Documented recommended",
    "memory_gb": 4,
    "disk_gb": 10,
    "vcpu": 2
  }
]

Der Spitzenwert für den Speicherbedarf eines Bots wurde mit 0.55 GB gemessen. Das dokumentierte Minimum beträgt 2 GB, die Empfehlung liegt bei 4 GB. Der Abstand zwischen Messwert und Minimum lässt Chromium unter Last wachsen. Der Speicherbedarf eines Browsers hängt von den geöffneten Seiten ab, nicht vom Prozess im Leerlauf. Die CPU-Auslastung liegt nahezu bei null und erreicht am oberen Ende des Messbereichs 0.06 eines Cores. CPU-Kapazität ist daher nicht der entscheidende Kostenfaktor. Entscheidend ist der Speicherplatz. Das Image allein belegt 5.3 GB. Empfohlen wird ein Volume mit 10 GB. Das Image ist so groß, weil es neben Chromium auch die Firefox- und WebKit-Binaries von Playwright enthält.

Diese Werte sagen nichts darüber aus, wie viel mehrere Bots zusammen benötigen. Das Projekt veröffentlicht dafür keine Angabe. Ein dokumentiertes Minimum ist ein Wert, den ein Projekt guten Gewissens angibt. Es handelt sich nicht um einen Wert, den jemand unter Last beobachtet hat. Deshalb hängt die Entscheidung zwischen PhotoPrism und Immich auch von den gemessenen RAM-Untergrenzen ab und nicht von den veröffentlichten Werten. Messen Sie selbst. Starten Sie einen Bot, geben Sie ihm eine reale Aufgabe mit geöffneter Seite und überwachen Sie den Container während der Ausführung.

docker stats --no-stream
free -m

Verwenden Sie die Spalte MEM USAGE für den Container des Bots als Wert pro Bot. Addieren Sie anschließend Gateway und PostgreSQL. Multiplizieren Sie den Wert pro Bot mit der Anzahl der Bots, die voraussichtlich gleichzeitig vorhanden sind. Ein inaktiver Bot hält weiterhin einen Browserprozess. Der Multiplikator gilt daher für vorhandene Bots und nicht nur für aktive Bots. Die Berechnung entspricht derjenigen für die Dimensionierung von RAM und CPU für eine Coding-Agent-VPS. Die Browser-Komponente wird in der Ausführung eines Headless-Browsers für Agents auf einer VPS behandelt.

Ein Detail von Chromium ist für kleine Pläne relevant. OpenBot startet Chromium mit --disable-dev-shm-usage. Der Browser schreibt dadurch nach /tmp statt nach /dev/shm. Das verhindert den Absturz, der auf Hosts mit einem kleinen /dev/shm auftritt. Gleichzeitig verlagert es die Belastung auf das Root-Dateisystem. Das ist ein weiterer Grund dafür, dass der empfohlene Speicherplatz größer ist als das Image.

Wie hosten Sie OpenBot selbst auf einem VPS?

Sie benötigen Docker, Bun 1.3 oder neuer, ein CopilotKit-Intelligence-Projekt und einen Model-API-Schlüssel. Die Entwicklungsdokumentation erwartet außerdem lsof, python3 und curl auf dem Server. Klonen Sie statt main eine getaggte Version, weil sich main bei einem Alpha-Projekt ohne Vorwarnung ändern kann.

git clone --branch v0.0.1 https://github.com/CopilotKit/openbot.git
cd openbot
cp .env.example .env

Richten Sie das Intelligence-Projekt ein. Diese drei Befehle schreiben den Laufzeitschlüssel und das Lizenz-Token in Ihre Umgebungsdatei.

npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
npx --yes copilotkit@latest license --write

Generieren Sie den Schlüssel, der gespeicherte Zugangsdaten verschlüsselt, und schreiben Sie die Ausgabe als KEY_ENCRYPTION_KEY in .env. Fügen Sie Ihren OPENAI_API_KEY in derselben Datei hinzu oder setzen Sie BOT_PROVIDER auf anthropic oder google mit dem passenden Schlüssel.

openssl rand -base64 32

Installieren und starten Sie anschließend die Anwendung.

bun install
bash scripts/start.sh

scripts/start.sh startet die Docker-Dienste, führt die Datenbankmigrationen aus, startet den Server und die Anwendung und prüft deren Status. Nach Abschluss antwortet die Anwendung auf Port 3010 und die API auf Port 3001. Das Skript meldet Portkonflikte und lässt einen bereits laufenden passenden Dienst unverändert. Sie können es daher sicher zweimal ausführen.

Prüfen Sie die Anwendung direkt auf dem Server, bevor Sie etwas öffentlich erreichbar machen.

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3010
ss -ltnp | grep -E ':(3010|3001|4100|4500|5432)'

Ein 200 aus dem ersten Befehl bedeutet, dass die Anwendung Anfragen verarbeitet. Der zweite Befehl zeigt, an welche Adressen diese Ports gebunden sind. Das ist auf einem VPS entscheidend. Eine Zeile mit 127.0.0.1:3001 ist nur innerhalb des Servers erreichbar. Eine Zeile mit 0.0.0.0:3001 bedeutet, dass jeder, der eine Route zum Server hat, den Dienst erreichen kann.

Das einzelne Container-Image

Die Bereitstellungsdokumentation enthält außerdem ein einzelnes Image, das die Anwendung, die API und Chromium enthält und auf Port 3001 bereitgestellt wird.

docker build -t openbot .
docker run -p 127.0.0.1:3001:3001 --env-file .env \
  -e EMBEDDED_POSTGRES=on -v openbot-data:/var/lib/postgresql/data openbot

EMBEDDED_POSTGRES=on führt PostgreSQL im Container aus und wendet beim Start Migrationen an. Das benannte Volume bewahrt den Audit-Verlauf bei einer erneuten Bereitstellung. Ohne dieses Volume verwirft jeder Neuaufbau den Verlauf. Wenn Sie DATABASE_URL stattdessen auf eine verwaltete Datenbank verweisen, muss dort die Erweiterung vector aktiviert sein. Verwaltete Dienste wie RDS, Cloud SQL und Azure Database unterstützen die Erweiterung. Keiner dieser Dienste aktiviert sie für Sie. Eine Migration gegen eine neue verwaltete Datenbank schlägt daher fehl, weil der Spaltentyp vector noch nicht existiert.

Führen Sie Migrationen als Release-Schritt aus, wenn die Datenbank extern betrieben wird.

docker run --rm --env-file .env openbot \
  sh -c "cd /app/server && bun x drizzle-kit migrate --config=drizzle.config.ts"

Dieses Image veröffentlicht den Browser-Port absichtlich nicht. Es enthält außerdem keinen Supervisor, weil der Supervisor den Docker-Socket benötigt und serverlose Plattformen diesen nicht bereitstellen. Ohne den Supervisor verwenden alle Bots denselben Browser und damit denselben Satz von Anmeldedaten. Dadurch entfällt die Isolation, die den Betrieb separater Container pro Bot sinnvoll macht. Wenn separate Anmeldedaten pro Bot Ihr Grund für diese Lösung sind, starten Sie den Compose-Stack mit gesetzten Variablen COMPUTER_SUPERVISOR_URL und SUPERVISOR_TOKEN auf einem Host, auf dem Sie diesen Kompromiss akzeptieren. Ein Prozess, der mit dem Docker-Socket kommunizieren kann, kann einen privilegierten Container starten. In der Praxis hat er damit root-Rechte auf dem Host. Das ist ein guter Grund, OpenBot auf einer eigenen Maschine zu betreiben, ganz im Sinne von Coding-Agenten eine temporäre VM bereitzustellen.

Warum OPENBOT_SINGLE_USER eine Einstellung für Laptops ist

.env.example wird mit OPENBOT_SINGLE_USER=true ausgeliefert. Diese Einstellung behandelt jede Anfrage als Anfrage eines einzelnen Administrators und überspringt die Anmeldung vollständig. Auf einem Laptop ist das praktisch, weil nur Sie den Port erreichen können. Auf einem VPS bedeutet es, dass die erste Person, die Port 3010 erreicht, Administrator eines Systems wird, das verschlüsselte Zugangsdaten speichert und einen Browser steuert, in dem Sie bereits bei Ihren Konten angemeldet sind.

Es gibt zwei sinnvolle Möglichkeiten, die Anwendung zu betreiben. Lassen Sie OPENBOT_SINGLE_USER=true aktiviert, binden Sie jeden Port an 127.0.0.1 und greifen Sie nur über einen SSH-Tunnel oder eine private Netzwerkschnittstelle auf die Anwendung zu.

ssh -N -L 3010:127.0.0.1:3010 -L 3001:127.0.0.1:3001 you@your-vps

Die Anwendung ist dann unter http://localhost:3010 in Ihrem eigenen Browser erreichbar. Das gilt als sicherer Kontext. Deshalb funktionieren sowohl Anmeldecookies als auch die Browserfunktionen, die die Live-Ansicht benötigt. Die andere Möglichkeit besteht darin, den Einzelbenutzermodus zu deaktivieren und einen echten Identity Provider zu konfigurieren. Google, Microsoft Entra, Okta, SAML und OIDC werden unterstützt. Jeder Provider benötigt außerdem BETTER_AUTH_SECRET mit mindestens 32 Zeichen, BETTER_AUTH_URL mit der öffentlichen API-Basis-URL für OAuth-Callbacks, INITIAL_ADMIN_EMAILS und TRUSTED_ORIGINS. Die Zugangsdaten des Providers müssen vollständig sein. Bei einer unvollständigen Konfiguration wird der Start abgebrochen, statt auf offenen Zugriff zurückzufallen. Wenn Sie Konten hinzufügen, weil jedes Teammitglied einen eigenen Agenten statt eines eigenen Browsers verwenden soll, ist OneCLI von Anfang an für dieses Modell ausgelegt. Für jede Person gibt es einen eigenen isolierten Agenten. Die Modellschlüssel werden in einem einzigen Gateway verwaltet.

Wenn die Anwendung unter einem öffentlichen Namen erreichbar ist, schalten Sie TLS (Transport Layer Security) davor. Eine Seite, die über gewöhnliches http:// und nicht über localhost bereitgestellt wird, ist kein sicherer Kontext. Daher werden mit Secure markierte Cookies nicht gespeichert. Die Anmeldung schlägt dann auf eine Weise fehl, die wie ein Fehler in OpenBot aussieht.

Sichern Sie die Ports der unteren Schicht mit der Firewall

In OpenBots eigenem Sicherheitshinweis steht, dass die Endpunkte der Dienste der unteren Schicht durch Tokens geschützt sind, dass Sie sie privat halten sollten und dass Sie sie nicht zum Umgehen des Gateways verwenden dürfen. Tokens sind die zweite Schutzmaßnahme. Die erste besteht darin, dass der Port überhaupt nicht erreichbar ist.

Der Agent-Computer lauscht auf Port 4100 und erfordert COMPUTER_TOKEN. Die Bot-Endpunkte lauschen auf 4200 und 4201. Der Supervisor lauscht auf dem Host auf 4500 und in seinem Container auf 4300. PostgreSQL lauscht auf 5432. Keiner dieser Ports gehört an eine öffentliche Schnittstelle. Bei einer Bereitstellung für einen einzelnen Benutzer gilt das auch für die Anwendung und die API.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

Hier gibt es eine Falle, in die Personen geraten, die davon ausgehen, dass die Firewall ausreicht. Wenn Sie einen Container-Port mit -p 3001:3001 veröffentlichen, installiert Docker eine DNAT-Regel. Dadurch wird der Datenverkehr im FORWARD-Pfad verarbeitet und durchläuft nie die INPUT-Kette, für die ufws standardmäßige Deny-Regel gilt. Der Port bleibt geöffnet, obwohl ufw status weiterhin Status: active ausgibt. Binden Sie den veröffentlichten Port bereits in der Zuordnung an Loopback, etwa mit -p 127.0.0.1:3001:3001, oder setzen Sie die Hostadresse in Ihrer Compose-Datei. Prüfen Sie dies mit ss -ltnp und nicht mit ufw status. Diese Falle ist nicht spezifisch für OpenBot. Führen Sie dieselbe Prüfung daher für jeden anderen Container aus, den Sie auf diesem Host veröffentlicht haben, einschließlich des Dienstes, der eine als Videothek der 90er rekonstruierte Jellyfin-Bibliothek bereitstellt.

OpenBot ist kein Offline-Stack

Klären Sie das, bevor Sie die Bereitstellung planen. OpenBot hängt von einem CopilotKit-Intelligence-Projekt ab. Dieses speichert dauerhafte Threads und den Gesprächskontext außerhalb Ihres Servers. Der Server prüft INTELLIGENCE_API_URL, INTELLIGENCE_GATEWAY_WS_URL, INTELLIGENCE_API_KEY und COPILOTKIT_LICENSE_TOKEN beim Start. Alle vier müssen gemeinsam vorhanden sein. Andernfalls schlägt der Start fehl. Seit August 2026 ist ein kostenloser Tarif verfügbar. Intelligence kann außerdem selbst gehostet werden. Eine vollständig lokale Bereitstellung ist daher möglich, erfordert aber mehr Arbeit, als der Quickstart zeigt.

Das Modell ist die zweite externe Abhängigkeit. Im Lieferumfang ist kein Modell enthalten. BOT_PROVIDER akzeptiert openai, anthropic oder google. OPENAI_BASE_URL richtet den OpenAI-Pfad auf einen kompatiblen Endpunkt. Hier passt Ollama auf einem VPS ausführen, um ein LLM selbst zu hosten, wenn die Tokens auf Ihrer eigenen Hardware bleiben sollen. Die Browsersteuerung stellt hohe Anforderungen an ein Modell. Testen Sie daher ein lokales Modell zunächst mit einer realen Aufgabe, bevor Sie sich dafür entscheiden.

Eine Replica ausführen, vorerst

Das Gateway legt Seitensnapshots im Speicher des Serverprozesses ab. Bei zwei Replicas ist ein von einem Prozess erstellter Snapshot für den anderen unsichtbar. Dadurch schlagen Aktionen sporadisch mit element-not-found-Fehlern fehl, die zufällig wirken. Die Bereitstellungsdokumentation ist eindeutig: Führen Sie eine einzelne Replica aus und setzen Sie die maximale Instanzanzahl Ihrer Plattform auf 1. Diese Einschränkung entfällt, sobald das Caching von Snapshots in die Datenbank verschoben wird. Bis dahin skalieren Sie OpenBot, indem Sie die vorhandene Maschine leistungsfähiger machen, nicht indem Sie weitere Maschinen hinzufügen. Die Isolation zwischen Bots erfolgt weiterhin durch die einzelnen Container. Das funktioniert genauso wie selbst gehostete Agent-Sandboxes, die die Fehler eines Agents von den anderen fernhalten.

Fehlerfälle und ihre sichtbaren Auswirkungen

Der Startvorgang wird unmittelbar nach dem Ausfüllen von .env beendet. Der Server prüft die Konfiguration, bevor er Anfragen verarbeitet. Ein unvollständiger Intelligence-Block, ein fehlendes KEY_ENCRYPTION_KEY oder ein OAuth-Provider mit Client-ID, aber ohne Secret beendet den Startvorgang, anstatt unbemerkt mit eingeschränkter Funktion weiterzulaufen. Lesen Sie den ersten Fehler, korrigieren Sie dieses eine Feld und starten Sie den Dienst erneut.

Migrationen schlagen bei einer verwalteten Datenbank fehl. Die Erweiterung vector ist standardmäßig nicht aktiviert. Deshalb trifft die Migration auf einen Spaltentyp, den PostgreSQL nicht kennt. Verbinden Sie sich als Superuser, führen Sie CREATE EXTENSION vector; aus und wiederholen Sie anschließend den Migrationsschritt.

Die Anwendung wird geladen, aber die Anmeldung bleibt nicht bestehen. Sie stellen die Anwendung über unverschlüsseltes http:// unter einer öffentlichen Adresse bereit. Das ist kein sicherer Kontext, daher verwirft der Browser das Secure-Cookie. Schalten Sie TLS vor die Anwendung oder verwenden Sie den SSH-Tunnel, damit der Browser localhost erkennt.

Bots verwenden dieselben Anmeldedaten, obwohl sie getrennt sein sollten. Der Supervisor läuft nicht. Daher gibt es keinen eigenen Computer pro Bot, und alle Bots verwenden denselben Browser. Prüfen Sie, ob COMPUTER_SUPERVISOR_URL gesetzt ist und der Supervisor den Docker-Socket erreichen kann.

Ein Bot hält an und fordert Hilfe an. Das entspricht dem vorgesehenen Verhalten. Der Audit-Trail protokolliert computer.help_requested. Sie übernehmen die Kontrolle auf dem Live-Bildschirm, und die Übergabe wird auf beiden Seiten protokolliert.

FAQ

Ist es sicher, OPENBOT_SINGLE_USER bei einer VPS-Bereitstellung aktiviert zu lassen?

Nur wenn das Gateway nicht aus dem Internet erreichbar ist. OPENBOT_SINGLE_USER=true akzeptiert jede Anfrage ohne Anmeldung als ein Administrator, sodass jeder, der den Port öffnen kann, die Bereitstellung, die gespeicherten Zugangsdaten und den angemeldeten Browser kontrolliert. Das ist akzeptabel, wenn jeder Port an 127.0.0.1 gebunden ist und Sie die Anwendung über einen SSH-Tunnel oder eine private Netzwerkschnittstelle erreichen. Deaktivieren Sie die Funktion an einer öffentlichen Schnittstelle und konfigurieren Sie Google, Microsoft Entra, Okta oder OIDC zusammen mit BETTER_AUTH_SECRET, BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS und TRUSTED_ORIGINS.

Wie viel RAM benötigt ein OpenBot-Bot?

Die veröffentlichten Angaben des Projekts für einen einzelnen Bot auf arm64 nennen einen Spitzenverbrauch von 0.55 GB. Als dokumentiertes Minimum gelten 2 GB, empfohlen werden 4 GB. Für mehrere Bots gleichzeitig gibt es keine veröffentlichten Angaben, weil jeder Bot eine eigene Chromium-Instanz verwendet. Führen Sie mit einem Bot eine reale Aufgabe aus, lesen Sie den Speicherverbrauch dieses Containers in docker stats ab, addieren Sie Gateway und Datenbank und multiplizieren Sie den Wert mit der erwarteten Anzahl gleichzeitig aktiver Bots.

Benötige ich ein CopilotKit-Konto, um OpenBot selbst zu hosten?

Ja. OpenBot benötigt ein CopilotKit-Intelligence-Projekt für dauerhafte Threads und den Speicher. Der Server startet nicht, wenn die Intelligence API-URL, die Gateway-WebSocket-URL, der API-Schlüssel oder das Lizenz-Token nicht gesetzt ist. Seit August 2026 ist ein kostenloser Tarif verfügbar. Intelligence kann außerdem selbst gehostet werden, sodass sich die gehostete Abhängigkeit mit zusätzlichem Aufwand entfernen lässt. Sie müssen außerdem Ihren eigenen Model-API-Schlüssel bereitstellen, da OpenBot kein Modell mitliefert.

Warum erhält jeder Bot einen eigenen Browser, statt einen gemeinsamen zu verwenden?

Weil ein Browserprofil eine Identität darstellt. Ein gemeinsamer Browser bedeutet gemeinsame Cookies und gemeinsame Sitzungen. Wenn ein Bot bei einem Konto angemeldet ist, sind dadurch alle Bots bei diesem Konto angemeldet. Container pro Bot geben jedem Benutzer ein eigenes Profil und eigene Anmeldungen. Der Nachteil ist der Speicherverbrauch, weil eine Chromium-Instanz pro Bot den größten einzelnen Anteil an der Dimensionierung ausmacht.

Welche OpenBot-Ports sollten in der Firewall geöffnet sein?

Keine der Ports der unteren Ebenen. Der Agent-Computer auf 4100, die Bot-Endpunkte auf 4200 und 4201, der Supervisor auf 4500 und PostgreSQL auf 5432 bleiben privat. Das Projekt schützt sie mit Tokens und verlangt außerdem, dass sie trotzdem nicht erreichbar sind. Veröffentlichen Sie nur die Ports, die eine Person zum Öffnen benötigt. Beachten Sie, dass ein mit -p 3001:3001 veröffentlichter Container-Port unabhängig von einer ufw-Regel mit standardmäßigem deny erreichbar ist, weil die DNAT-Regel von Docker diesen Datenverkehr in den FORWARD-Pfad statt in INPUT einordnet.