Superlog selbst hosten: Ressourcen und Stolperfallen

Welche Komponenten das Self-Hosting von Superlog tatsächlich installiert

Für das Self-Hosting von Superlog klonen Sie das Repository, starten Postgres, ClickHouse und einen OpenTelemetry-Collector mit Docker Compose, führen eine Datenbankmigration aus und starten anschließend vier Node-Dienste aus dem Quellcode. Ihre Anwendungen senden OTLP-Traces, -Logs und -Metriken an einen Intake-Port. Superlog erstellt daraus Fingerabdrücke, gruppiert wiederkehrende Ereignisse zu einem einzelnen Incident, und ein Agent erstellt den ersten Triage-Entwurf. Die Installation dauert einen Nachmittag. Der Ressourcenbedarf und die tatsächlichen Einschränkungen sind die Punkte, die Sie vor dem Start lesen sollten.

Superlog steht unter der Apache-2.0-Lizenz und befindet sich unter github.com/superloglabs/superlog. Im August 2026 hat das Projekt etwa 1.2k Sterne und ungefähr 460 Commits auf main, aber überhaupt keine Release-Tags. Dieser letzte Punkt bestimmt den Installationsablauf: git checkout v1.0.0 enthält nichts, das Sie auschecken können. Sie müssen daher selbst einen Commit festlegen oder verwenden den Stand, auf dem sich main am Morgen Ihres Klonvorgangs befand.

Welche Fragen Superlog beantwortet, die Uptime Kuma und Langfuse nicht beantworten

Self-hosted-Monitoringtools wirken von außen austauschbar. Das sind sie nicht. Wenn Sie das falsche Tool einsetzen, belegen Sie einen Server ohne Nutzen.

• Uptime Kuma prüft Ihre Endpunkte von außen und beantwortet eine Frage: Ist der Dienst erreichbar?
• Zabbix überwacht Hosts und Dienste unter Ubuntu 24.04 und vergleicht CPU, Arbeitsspeicher, Festplatten- und Dienststatus mit den von Ihnen festgelegten Schwellenwerten.
• Langfuse zeichnet LLM-Aufrufe nach und erfasst für jeden Aufruf den Prompt, das Modell, die Tokens, die Latenz und die Kosten.
• Superlog übernimmt die Telemetriedaten, die Ihre normalen Dienste bereits ausgeben, und wandelt wiederkehrende Fehler in Incidents um.

Superlog beantwortet eine andere Frage: Etwas ist ausgefallen. Was ist ausgefallen und warum? Das Tool ist nicht auf LLM-Aufrufe spezialisiert und prüft Ihre Systeme nicht von außen. Es nimmt OTLP aus Ihrem normalen Anwendungscode entgegen und setzt beim Triage-Schritt einen Agenten ein. Dieser Schritt entspricht der ersten Prüfung, die eine Bereitschaftsperson ohnehin durchführen würde.

Für das Budget eines VPS ist der Speicherbedarf entscheidend. Uptime Kuma läuft problemlos mit 1 GB RAM, weil es einige tausend Prüfergebnisse speichert. Superlog verwendet einen Column Store, weil Telemetriedaten einmal geschrieben und anschließend über Zeitbereiche hinweg über Millionen Zeilen abgefragt werden. Dafür ist ClickHouse ausgelegt, Postgres dagegen nicht. Postgres bleibt trotzdem Teil des Stacks und speichert die kleinen relationalen Daten: Projekte, Benutzer, Incidents und Ingest Keys.

Was startet docker compose up -d tatsächlich?

Drei Container, und keiner davon ist Superlog. Das überrascht viele, die eine Installation mit einem einzigen Befehl erwarten.

• postgres:16, veröffentlicht auf dem Host-Port 5434
• clickhouse/clickhouse-server:26.1, auf 8123 für HTTP und 9000 für das native Protokoll
• otel/opentelemetry-collector-contrib:0.150.1, auf 4317 für gRPC und 4318 für OTLP über HTTP

Die Superlog-Anwendungen laufen auf dem Host aus dem Quellcode und werden von pnpm dev gestartet. Seit August 2026 gibt es kein Compose-Produktionsfile im Repository. Für einen dauerhaft betriebenen Dienst benötigen Sie daher eigene systemd-Units für die Skripte start der einzelnen Anwendungen oder die Dockerfiles der jeweiligen Anwendungen, die im Verzeichnisbaum enthalten sind.

Behalten Sie den Weg eines Spans im Blick. Jeder Fehler weiter unten unterbricht einen Hop dieses Wegs. Ihre Anwendung sendet OTLP an den Superlog-Intake-Proxy. Der Proxy authentifiziert die Anfrage mit Ihrem Ingest-Key, versieht sie mit der Projekt-ID und leitet sie an den Collector weiter. Der Collector entfernt alle superlog.*-Attribute, die der Client zu setzen versucht hat, ergänzt superlog.project_id aus dem Header des Proxys, bündelt die Daten und schreibt sie in ClickHouse. Die Webanwendung und die API lesen die Telemetriedaten anschließend aus ClickHouse. Alle anderen Daten lesen sie aus Postgres.

Das Entfernen dieser Attribute ist eine echte Kontrolle für Mandantentrennung und keine bloße Dekoration. Ohne diese Kontrolle könnte jeder mit einem gültigen Ingest-Key selbst superlog.project_id setzen und Daten in das Projekt eines anderen Mandanten schreiben.

Wie groß muss die VPS sein?

Planen Sie für eine einzelne Node-Installation bei geringem Ingest-Volumen mit 4 vCPU, 8 GB RAM und 40 GB SSD. Das ist eine Planungsuntergrenze, keine Messung. Betrachten Sie diese Werte daher als Ausgangspunkt und prüfen Sie sie anhand Ihres eigenen Datenverkehrs.

Der Arbeitsspeicher verteilt sich auf vier Bereiche. ClickHouse ist für Systeme mit viel RAM ausgelegt, und die Standardwerte gehen davon aus. Postgres 16 ist in diesem Szenario genügsam, da es Metadaten und keine Telemetriedaten speichert. Auch der Collector benötigt wenig Ressourcen. Das gilt nicht für die vier Node-Prozesse: Ein Vite-Entwicklungsserver und drei tsx watch-Prozesse belegen jeweils mehrere hundert Megabyte. Deshalb ist pnpm dev auf einem System mit 2 GB RAM problematisch.

Der Speicherplatz ist das weniger auffällige Problem. pnpm install in diesem Monorepo lädt das AWS SDK, einen ClickHouse-Client, das OpenTelemetry SDK und eine React-Toolchain, bevor Sie auch nur einen einzigen Span verarbeitet haben. ClickHouse wächst anschließend mit Ihrem Datenverkehr. Messen Sie beides:

df -h /
free -m
docker stats --no-stream
docker compose exec clickhouse clickhouse-client --database superlog --query "SELECT table, formatReadableSize(sum(bytes_on_disk)) AS size FROM system.parts WHERE active AND database = 'superlog' GROUP BY table ORDER BY sum(bytes_on_disk) DESC"

Bei geringem Volumen, wenn einige Dienste wenige hundert Spans pro Minute senden, bleibt das System ruhig und ClickHouse ist die meiste Zeit untätig. Belastend sind Spitzen: Ein fehlerhaftes Deployment kann beispielsweise mehrere tausend identische Fehler pro Minute erzeugen. Das Fingerprinting fasst diese Fehler für den Leser zu einem Incident zusammen. ClickHouse schreibt jedoch weiterhin jede einzelne Zeile.

Sie legen die Aufbewahrungsdauer selbst fest. Der ClickHouse-Exporter des Collectors erstellt die Tabellen otel_traces, otel_logs und jeweils eine Tabelle pro Metriktyp. Eine Aufbewahrungsdauer wird nur angewendet, wenn die Konfiguration in infra/collector/config.yaml eine solche festlegt. Nichts läuft automatisch ab. Ein stark ausgelasteter Monat kann daher die gesamte Festplatte füllen, wenn Sie dies nicht einplanen.

Installation aus einem festgelegten Commit

git clone https://github.com/superloglabs/superlog.git
cd superlog
git tag -l
git log -1 --format='%H %cs %s'

git tag -l gibt mit Stand August 2026 erwartungsgemäß nichts aus. Wählen Sie den getesteten Commit aus und bleiben Sie dabei:

git checkout 0d3a6c8bb63eda3493e6ba0003e7c2a70750bc1e

Als Nächstes die Toolchain:

node -v
corepack enable
corepack prepare pnpm@9.12.0 --activate
pnpm -v

package.json deklariert engines.node als >=20.0.0 und packageManager als pnpm@9.12.0. Wenn Sie die Installation mit einer älteren Node-Version ausführen, bricht pnpm mit ERR_PNPM_UNSUPPORTED_ENGINE ab und nennt die erwartete Version. Das nodejs-Paket im Ubuntu-24.04-Archiv ist älter als 20. Installieren Sie daher Node 20 oder neuer über NodeSource oder nvm. Das Repository enthält eine .nvmrc. Mit nvm use wählen Sie die vorgesehene Version aus, wenn Sie nvm verwenden.

pnpm install
docker compose up -d
docker compose ps

Warten Sie auf die Healthchecks, statt up -d als Bereitschaftssignal zu interpretieren. Postgres und ClickHouse deklarieren jeweils einen Healthcheck in der Compose-Datei:

curl -sS http://127.0.0.1:8123/ping
pg_isready -h 127.0.0.1 -p 5434 -U postgres

ClickHouse antwortet auf Ok., und pg_isready antwortet auf accepting connections. Eine verweigerte Verbindung auf 8123 bedeutet, dass der Container noch gestartet wird oder beendet wurde. docker compose logs clickhouse zeigt, welcher Fall vorliegt, und docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled meldet true, wenn der Kernel den Prozess wegen Speichermangels beendet hat. Das weist auf eine zu klein dimensionierte Maschine und nicht auf Ihre Konfiguration hin.

Danach folgen die Migration und die Anwendungen:

pnpm --filter @superlog/db db:migrate
pnpm dev

Beachten Sie den Port: 5434, nicht 5432. Die Compose-Datei veröffentlicht Postgres auf 5434, damit es nicht mit einer bereits auf dem Host installierten Postgres-Instanz kollidiert. Die .env.example-Dateien der Anwendung verwenden denselben Port, zusammen mit DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog. Wenn Sie die Migration auf einem Host, auf dem bereits Postgres läuft, auf 5432 verweisen lassen, erhalten Sie entweder eine verweigerte Verbindung oder, schlimmer noch, die Migration wird auf der falschen Datenbank ausgeführt.

pnpm dev startet die vier in Procfile des Repositorys aufgeführten Prozesse: api, web, worker und proxy. Jeder Prozess leitet seine Ausgabe zusätzlich nach tmp/logs/ weiter. Daher überwachen Sie den Ingest unter tail -f tmp/logs/proxy.log. Laut README läuft die Webanwendung auf http://localhost:5173, die API auf http://localhost:4100 und die OTLP-Annahme auf http://localhost:4101.

Prüfen Sie, welcher Prozess tatsächlich an den Port gebunden ist, bevor Sie etwas darauf verweisen:

ss -lntp | grep -E '4100|4101|5173'
curl -sS http://127.0.0.1:4101/health

Das ist später wichtig. Der Proxy liest seinen Port aus der Umgebungsvariable PORT und verwendet 4000 als Fallback, wenn PORT nicht gesetzt ist. Der Entwicklungs-Stack setzt die Variable automatisch. Eine selbst erstellte systemd-Unit tut das nicht. Daher schlägt ein auf 4101 ausgerichteter Exporter mit connection refused fehl, wenn der Proxy auf 4000 lauscht, und liefert keinen weiteren Hinweis.

Ein Trace, ein Fehler, ein Incident

Erstellen Sie in der Webanwendung ein Projekt und kopieren Sie dessen Ingest-Key. Die Intake-Komponente authentifiziert jede Anfrage mit diesem Schlüssel. Telemetrie ohne Schlüssel erreicht ClickHouse daher nicht.

Richten Sie ein beliebiges OpenTelemetry SDK über die standardmäßigen Umgebungsvariablen auf die Intake-Komponente:

export OTEL_SERVICE_NAME=checkout-api
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4101
export OTEL_EXPORTER_OTLP_HEADERS='x-api-key=YOUR_INGEST_KEY'

Die Intake-Komponente liest den Schlüssel aus dem Header x-api-key. Sie akzeptiert außerdem authorization: bearer YOUR_INGEST_KEY, wenn sich Ihr Exporter darüber einfacher konfigurieren lässt. Sie stellt die drei standardmäßigen OTLP-Pfade /v1/traces, /v1/logs und /v1/metrics sowie /health bereit.

Ein häufiger Fehler verdient besondere Beachtung. OTEL_EXPORTER_OTLP_ENDPOINT ist eine Basis-URL. Das SDK hängt den Pfad des jeweiligen Signals daran an. Signalspezifische Variablen wie OTEL_EXPORTER_OTLP_TRACES_ENDPOINT werden unverändert verwendet. Es wird kein Pfad angehängt. Wenn Sie die signalspezifische Variable auf http://127.0.0.1:4101 setzen, sendet jeder Export an /. Das ist keine Route. Es kommt daher nichts an. Das SDK protokolliert einen Exportfehler, während Ihre Anwendung scheinbar fehlerfrei läuft.

Für einen Node-Dienst reicht der codefreie Pfad aus, um die Pipeline zu prüfen:

npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register server.js

Lösen Sie nun absichtlich einen Fehler aus. Jede Route, die eine Exception auslöst, ist geeignet:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/boom

Prüfen Sie die Stationen in dieser Reihenfolge. Die erste Lücke zeigt, welche Station fehlgeschlagen ist:

tail -n 50 tmp/logs/proxy.log
docker compose exec clickhouse clickhouse-client --database superlog --query 'SELECT count() FROM otel_traces'

Ein steigender Zähler in otel_traces bei gleichzeitig leerer Webanwendung weist auf eine Projektverwechslung hin. Prüfen Sie daher, zu welchem Projekt der Ingest-Key gehört. Ein unveränderter Zähler bei Aktivität im Proxy-Log deutet auf den Collector oder das Schreiben nach ClickHouse hin. Lesen Sie dann docker compose logs collector. Wenn im Proxy-Log überhaupt keine Aktivität erscheint, hat der Exporter die Intake-Komponente nicht erreicht: falscher Port, falscher Pfad oder abgewiesener Schlüssel.

In der Webanwendung erscheinen diese wiederholten Fehler als ein Incident und nicht als eine Zeile pro Anfrage. Superlog erstellt Fingerprints für eingehende Signale und gruppiert übereinstimmende Signale. Dadurch enthält der Posteingang nicht 4,000 identische Fehler, sondern eine einzige Meldung. Der Agent legt seine Untersuchung anschließend auf dieser Gruppe ab.

Für die Untersuchung wird ein Modell aufgerufen. Daher muss für den Worker ein Model-Provider konfiguriert sein. Übernehmen Sie die Namen dieser Variablen aus der Datei .env.example im jeweiligen Anwendungsverzeichnis des von Ihnen festgelegten Commits und nicht aus einer externen Anleitung. Die Variablen ändern sich zusammen mit main. Dasselbe gilt für die GitHub- und Sentry-Integrationen. Die zugehörigen Einrichtungsdokumente befinden sich unter docs/github-app-setup.md und docs/sentry-app-setup.md. Die Dokumentation der Webhook-Payloads finden Sie unter docs/webhooks.md.

Halten Sie die Eingangsroute privat und den Agenten schreibgeschützt

Docker veröffentlicht Container-Ports standardmäßig auf 0.0.0.0. Diese veröffentlichten Ports umgehen ufw, weil Docker eigene Regeln in die DOCKER-USER-Kette schreibt, die ausgewertet werden, bevor ufw das Paket sieht. Auf einem VPS mit öffentlicher IP stellt die mitgelieferte Compose-Datei ClickHouse HTTP auf Port 8123 und Postgres auf Port 5434 bereit. Beide Ports sind dadurch aus dem Internet erreichbar. Die Zugangsdaten in dieser Datei sind Entwicklungsstandards: der ClickHouse-Benutzer default mit leerem Passwort sowie Postgres mit postgres als Benutzer und Passwort.

Binden Sie die Ports an das Loopback-Interface. Jeder veröffentlichte Port in der Compose-Datei bezieht die Host-Seite aus einer Umgebungsvariablen. Daher genügt eine .env im Repository-Stammverzeichnis:

POSTGRES_HOST_PORT=127.0.0.1:5434
CLICKHOUSE_HTTP_HOST_PORT=127.0.0.1:8123
CLICKHOUSE_TCP_HOST_PORT=127.0.0.1:9000
COLLECTOR_GRPC_HOST_PORT=127.0.0.1:4317
COLLECTOR_HTTP_HOST_PORT=127.0.0.1:4318

Prüfen Sie das Ergebnis, bevor Sie ihm vertrauen, und erstellen Sie anschließend die Container neu:

docker compose config
docker compose up -d
ss -lntp | grep -E '5434|8123|9000|4317|4318'

docker compose config gibt die aufgelöste Datei aus. Dadurch können Sie 127.0.0.1:5434:5432 ablesen, statt zu raten. ss sollte anschließend 127.0.0.1:5434 anzeigen und niemals 0.0.0.0:5434. Versuchen Sie nicht, dies mit einer Compose-Override-Datei zu beheben, die ports erneut definiert. Compose fügt Portlisten aus mehreren Dateien zusammen, statt sie zu ersetzen. Dadurch erhalten Sie beide Bindings, und der öffentliche Port bleibt weiterhin offen.

Auch die Eingangsroute erfordert entsprechende Absicherung. Ihr Ingest-Schlüssel wird in einem Header übertragen. Daher benötigt er TLS (Transport Layer Security) davor: Terminieren Sie TLS in nginx oder Caddy vor dem Proxy, oder halten Sie den Ingest-Dienst in einem privaten Netzwerk oder einem WireGuard-Tunnel. Die Webanwendung auf Port 5173 ist ein Vite-Entwicklungsserver und darf keinesfalls aus dem Internet erreichbar sein.

Kommen wir zum Agenten selbst. Superlog wirbt damit, dass der Agent Untersuchungen durchführt und eine Lösung vorschlägt. Das entscheidende Wort ist „vorschlägt“. Lassen Sie ihn in Produktionsumgebungen schreibgeschützt arbeiten, bis Sie sein Verhalten an einigen echten Vorfällen beobachtet haben. Geben Sie der GitHub App Lesezugriffsbereiche und erlauben Sie ihr, Pull Requests zu öffnen, die Sie anschließend prüfen. Ein Agent, der Telemetriedaten liest und einen Patch schreibt, ist nützlich. Ein Agent, der Ihre Dienste neu starten kann, stellt ein anderes Risikoniveau dar. Das sollte eine bewusste Entscheidung sein und keine Standardeinstellung, die Sie ungeprüft übernehmen. Auch die Kosten verdienen Aufmerksamkeit, da jede Untersuchung einen Modellaufruf auslöst: planen Sie ein Budget für Agentenkosten auf einem VPS bevor Sie ihn auf ein lautes Produktionssystem ansetzen, und führen Sie ein Protokoll der tatsächlichen Aktionen des Agenten, damit hinter einem unerwarteten Pull Request ein Prüfpfad vorhanden ist.

Fehler, auf die Sie stoßen werden, und die Zeichenfolgen, die sie benennen

• ERR_PNPM_UNSUPPORTED_ENGINE während pnpm install bedeutet, dass Node älter als 20 ist. node -v bestätigt dies in einer Zeile.
• ECONNREFUSED 127.0.0.1:5434 während der Migration bedeutet, dass der Compose-Stack nicht läuft oder DATABASE_URL den falschen Port angibt.
• Wenn ClickHouse in einer Schleife neu startet, liegt das meistens am Speicher. Lesen Sie docker compose logs clickhouse und prüfen Sie anschließend im Container, ob OOMKilled auf true gesetzt ist.
• Wenn ein Exporter Erfolg meldet, während die Webanwendung leer bleibt, wurden die Daten wahrscheinlich direkt an den Collector auf Port 4318 gesendet. Dabei wird das vom Proxy gesetzte Projektstamping umgangen.
• Connection refused auf Port 4101 in einer Produktivinstallation bedeutet, dass der Proxy auf PORT=4000 zurückgefallen ist. Setzen Sie PORT explizit in der Unit-Datei.
• Wenn docker compose ps 0.0.0.0:8123 anzeigt, sind Ihre Loopback-Bindings nicht aktiv. Führen Sie docker compose config aus und lesen Sie die aufgelösten Ports ab.

Flawless, HyperProbe und die Position von Superlog

Diese Kategorie ist noch jung, und die Tools unterscheiden sich darin, worauf der Agent zugreifen darf. Flawless ist ein Open-Source-KI-SRE-Tool (Site Reliability Engineering) für Kubernetes. Es liest Daten aus einem vorhandenen Prometheus-, Loki- und Grafana-Stack, statt die Pipeline selbst zu betreiben. HyperProbe verfolgt den umgekehrten Ansatz: Das Produkt wird als gehosteter Dienst bereitgestellt und ist seit August 2026 Closed Source. Es platziert schreibgeschützte Probes in einem laufenden Prozess, um den Variablenzustand zu erfassen, und stellt diesen Zustand einem Assistenten über MCP (Model Context Protocol) bereit.

Superlog liegt zwischen diesen beiden Ansätzen. Es übernimmt die Pipeline vollständig, von der OTLP-Annahme bis zur Speicherung in ClickHouse. Den Agenten setzt es bei der Triage ein, nicht bei der Behebung. Genau deshalb ist das Self-Hosting eine Infrastrukturentscheidung und kein Container, den Sie einfach vergessen können. Wenn Sie Superlog betreiben, betreiben Sie einen Column Store. Dafür ist dieselbe Sorgfalt erforderlich wie für jede andere Datenbank, die Sie selbst verwalten.

FAQ

Wie viel RAM benötigt ein selbst gehostetes Superlog?

Planen Sie für einen einzelnen Knoten bei geringem Ingest-Volumen 8 GB RAM, 4 vCPU und 40 GB Speicherplatz ein. Der Stack besteht aus Postgres, ClickHouse, einem OpenTelemetry-Collector und vier Node-Prozessen. ClickHouse benötigt außerdem ausreichend Reserven. Ein VPS mit 1 GB oder 2 GB RAM reicht nicht aus: Allein pnpm install ist ressourcenintensiv, und unter Last beendet der Out-of-Memory-Killer des Kernels ClickHouse. Ermitteln Sie Ihre eigenen Werte mit docker stats --no-stream und free -m, statt einer veröffentlichten Angabe zu vertrauen, auch dieser hier.

Auf welchen Port muss der OTLP-Exporter zeigen?

Auf den Intake-Proxy von Superlog, den die README unter http://localhost:4101 angibt. Er stellt /v1/traces, /v1/logs und /v1/metrics bereit und authentifiziert sich mit dem Ingest-Key Ihres Projekts, der aus dem Header x-api-key oder einem Header authorization: bearer stammt. Port 4318 gehört zum darunterliegenden OpenTelemetry-Collector. Wenn Sie Daten direkt dorthin exportieren, umgehen Sie den Proxy. Der Proxy versieht die Daten mit Ihrer Projekt-ID. Wenn PORT nicht gesetzt ist, verwendet der Proxy Port 4000 als Fallback. Führen Sie daher ss -lntp aus und prüfen Sie, an welchen Port der Dienst gebunden ist, bevor Sie 4101 voraussetzen.

Ersetzt Superlog Uptime Kuma oder Zabbix?

Nein. Uptime Kuma prüft von außerhalb Ihres Netzwerks, ob ein Endpunkt antwortet. Zabbix überwacht Host- und Servicemetriken anhand von Schwellenwerten, die Sie festlegen. Superlog verarbeitet die von Ihren Anwendungen ausgegebenen Traces, Logs und Metriken und fasst wiederholte Fehler zu Incidents zusammen. Betreiben Sie zusätzlich eine externe Uptime-Prüfung. Eine Prüfung an einem anderen Standort meldet weiterhin, wenn der Host Ihrer Telemetrie-Pipeline ausgefallen ist.

Kann der Superlog-Agent meine Produktivsysteme ändern?

Nur durch Berechtigungen, die Sie ihm erteilen. Seine Ausgabe besteht aus einer Untersuchung und einem vorgeschlagenen Änderungsschritt, den ein Mensch prüft. Belassen Sie die GitHub App zunächst bei Leseberechtigungen und Pull Requests. Beschränken Sie auch die Berechtigungen aller Zugangsdaten, die der Worker verwendet, zunächst auf Lesezugriff. Behandeln Sie Schreibzugriff auf die Produktion als separate, bewusst getroffene Entscheidung. Ein Agent, der Dienste neu starten kann, ist eine deutlich größere Verpflichtung als ein Agent, der Telemetrie liest und einen Patch zur Prüfung erstellt.

Sollte ich einen Commit festschreiben oder main verfolgen?

Schreiben Sie einen Commit fest. Im Repository gibt es mit Stand August 2026 keine Release-Tags. Damit ist main das einzige verfügbare bewegliche Ziel, und dort werden mehrere Commits pro Woche veröffentlicht. Notieren Sie die getestete SHA, stellen Sie genau diese Version bereit und lesen Sie den Diff, bevor Sie aktualisieren. git log --oneline <old-sha>..main ist die Prüfgrundlage. Die .env.example-Dateien der einzelnen Anwendungen sind die erste Anlaufstelle für neu erforderliche Variablen nach einer Aktualisierung.