Festplatten bleiben im Rahmen

Eine Steuerzentrale, die Builds, Images und Logs auf vielen Servern verwaltet, kann unbemerkt eine Festplatte füllen. In 2.12.3 hat alles, was wächst, eine Grenze.

• Die interne Registry behält zwei Builds pro Container, löscht die Builds entfernter Quellen und nimmt keine neuen Builds mehr an, wenn ihre Festplatte zu 90 % voll ist.
• Docker-Knoten entfernen Images, die seit 12 Stunden niemand verwendet hat. Jeder Container behält das Image, mit dem er läuft, und eines für ein Rollback.
• Container-Logs auf Docker-Knoten bleiben begrenzt, auch bei Containern, die vor Opfield oder an Opfield vorbei angelegt wurden. Nginx-Knoten halten Routen-Logs unter einer Größengrenze und entfernen die Logs gelöschter Routen.
• Postgres-WAL und Replikationsslots füllen keine Datenbankfestplatte mehr.
• Housekeeping hält die eigenen Daten von Opfield auch dann begrenzt, wenn es ausgeschaltet ist, und läuft sofort, sobald eine Opfield-Festplatte zu 90 % voll ist. Außerdem zeigt es, was jede Festplatte füllt: die größten Tabellen, Redis, Container-Logs und alte Images pro Knoten.

Neue eingebaute Alarme warnen rechtzeitig: Festplattenalarme bei 85 % für jede Datenfestplatte eines Knotens, volle Opfield-Festplatte, volle Datenbankfestplatten und ein Housekeeping, das nicht läuft.

Schutz für Konsolenbefehle von Agenten

Der Assistent und MCP-Clients können Befehle in der Konsole eines Knotens ausführen. Sie laufen als root, damit ein Agent einen Knoten tatsächlich reparieren kann. Docker, containerd und Podman sind in dieser Konsole ausgeblendet: Ein Befehl mit Docker wird abgelehnt, und die Antwort nennt das Opfield-Werkzeug, das stattdessen zu verwenden ist.

Das ist ein Schutz vor Versehen, keine Sicherheitsgrenze. Er verhindert, dass ein Agent einen verwalteten Container aus Versehen an Opfield vorbei ändert. Außerdem können Agenten keine Befehle mehr per SSH auf Hosts ausführen, die Opfield-Knoten sind.

Wird ein verwalteter Container trotzdem von Hand gestoppt, geändert oder entfernt, löst der neue eingebaute Alarm „Container changed outside Opfield“ aus und erklärt, was die Änderung bedeutet.

Zugriffsregeln in der richtigen Reihenfolge

Die Regeln einer Zugriffsliste werden von oben nach unten geprüft, und der erste Treffer gilt. Bisher ließ sich die Reihenfolge nicht ändern, sodass eine Allow-Regel nach einem breiten Deny nie greifen konnte. Jetzt lassen sich Regeln in der Oberfläche, über die API und per MCP umsortieren, und Regeln, die nie greifen können, werden markiert.

Failover-Reihenfolge für Datenbanken und Speicher

Für verwaltetes Postgres, Key-Value-Stores, ClickHouse und S3-Speicher mit Verfügbarkeit lässt sich jetzt die Failover-Reihenfolge festlegen: welcher Server zuerst übernimmt, wenn der primäre ausfällt.

Registry in S3

Die interne Registry kann ihre Daten in S3 statt auf der Festplatte des Opfield-Hosts speichern. Beim Wechsel des Speichers wird jedes Image geprüft, das die Registry für Workloads vorhält.

Pages und Fehlerseiten

Pages-Projekte liefern für fehlende Pfade ihre eigene 404.html mit Status 404 aus.

Jede Seite, die nginx selbst erzeugt (Fehler, abgewiesene Clients, nicht erreichbare Upstreams, der Default-Server), ist jetzt eine Opfield-Seite. Die eigenen Fehlerseiten Ihrer Anwendungen werden unverändert durchgereicht.

Git-Quellen

• Ein Container mit Git-Quelle lässt sich auf den vorherigen Build zurücksetzen: im Tab Source, über die API oder per MCP.
• Ein fehlgeschlagener Build zeigt den fehlerhaften Dockerfile-Schritt und dessen Exit-Code, und eine Quelle sagt, warum ein Build fehlschlug oder nichts ausgerollt hat.
• Umgebungsvariablen, Secrets und Volumes lassen sich vor dem ersten Build setzen, und der erste Build startet sofort.
• Die Sicherheitsrichtlinie für Builds kann nur Schwachstellen blockieren, für die es einen Fix gibt, wahlweise für Anwendungspakete oder für alle Pakete.

Außerdem in diesem Release

Routen hinter Cloudflare sehen die echte Client-IP in Zugriffslisten, Rate Limits und Logs. Verwaltetes Postgres läuft auf Opfields eigenen Images, und PostGIS und pgRouting lassen sich bei Bedarf im Tab Extensions installieren.

Wichtig vor dem Update: Container-Archive verwenden jetzt das Opfield-Format (.ofca). Archive, die mit früheren Versionen exportiert wurden, lassen sich nicht importieren.

Selbst gehostete Installationen aktualisieren Sie wie gewohnt. Verwaltete Cloud-Installationen werden in ihrem Wartungsfenster aktualisiert.

Was Sie bekommen

Eine verwaltete Installation ist ein vollständiges Opfield in derselben Version wie selbst gehostet, unter <name>.opfield.cloud. Sie kaufen und verwalten sie im Kundenportal, zusammen mit einem bezahlten Lizenzschlüssel (Personal, Business oder Enterprise). Mit Community ist sie nicht verfügbar.

• Region: Finnland. Deutschland ist geplant.
• Anmeldung mit Ihrem Opfield-Konto. Der Inhaber meldet sich mit demselben Konto an wie im Portal.
• Tägliche Backups. Jeden Tag läuft ein Backup. Sie können auch jederzeit selbst sichern und aus dem Portal wiederherstellen. Nach dem Löschen bleibt das neueste Backup noch einige Tage erhalten, sodass sich die Installation zurückholen lässt.
• Updates in Ihrem Wartungsfenster. Sie wählen Tag und Stunde (UTC). Opfield erstellt ein Backup, aktualisiert sich und ist danach mit der neuen Version wieder da. Sie können auch sofort aktualisieren.
• Ihre Knoten bleiben Ihre. Eigene Server binden Sie mit Einmal-Tokens aus dem Portal an. Workloads, Datenbanken und Speicher laufen auf ihnen, nicht auf der verwalteten VM.

Pläne

Die Preise gelten pro Monat zusätzlich zum Lizenzschlüssel und verlängern sich mit ihm.

Zwölf Monate kosten so viel wie elf. Von Standard auf Extended wechseln Sie jederzeit und zahlen die Differenz für den Rest des Zeitraums; Opfield startet dabei einmal neu. Ein Wechsel nach unten gilt ab dem Ende des bezahlten Zeitraums.

E-Mail inklusive

Opfield verschickt System-E-Mails: Anmeldecodes, Links zum Setzen und Zurücksetzen von Passwörtern, Einladungen. Eine selbst gehostete Installation braucht dafür einen SMTP-Anbieter. Eine verwaltete Installation verschickt sie sofort, von <name>@mail.opfield.cloud, in beiden Plänen ohne Aufpreis.

Die Limits reichen für System-E-Mails gut aus und halten den Ruf des gemeinsamen Absenders sauber:

• Standard: 500 pro Monat, 50 pro Tag, 25 pro Stunde.
• Extended: 2.000 pro Monat, 200 pro Tag, 50 pro Stunde.

Eigene Domain

Die Installation kann unter Ihrer eigenen Domain erreichbar sein, zum Beispiel ops.example.com. Fügen Sie die Domain auf der Seite der Installation hinzu, legen Sie den angezeigten CNAME-Eintrag an, und Opfield holt ein Zertifikat dafür. Die Adresse unter opfield.cloud funktioniert weiter. Passkeys sind an die Adresse gebunden und müssen nach einem Wechsel neu hinzugefügt werden; die Seite weist vorher darauf hin.

KI inklusive

Opfield hat einen eingebauten KI-Assistenten und einen MCP-Server für Ihre eigenen Agenten. Beide brauchen ein Modell. Auf einer verwalteten Installation ist Opfield Cloud AI bereits angebunden:

• Free, mit jeder verwalteten Installation: Modellnutzung inklusive.
• S, 9 $/Monat.
• M, 29 $/Monat, mit doppelt so viel Nutzung wie S.

Es gibt zwei Modelle: Opfield Swift für schnelle Alltagsaufgaben und Opfield Heavy für längere und schwierigere. Die Nutzung wird als Prozentsatz jedes Zeitfensters angezeigt, zusammen mit dem Zeitpunkt, an dem es zurückgesetzt wird. Ist ein Fenster aufgebraucht, sagt der Assistent das und arbeitet nach dem Zurücksetzen weiter. Alles andere in Opfield läuft normal weiter.

Erste Schritte

Aktivieren Sie im Kundenportal beim Kauf eines Schlüssels „Host it in our cloud“, oder wählen Sie „Add managed cloud“ auf der Seite eines vorhandenen Schlüssels. Nach der Zahlung wird die Installation automatisch eingerichtet, und Sie erhalten eine E-Mail, sobald sie bereit ist. Pläne und Preise finden Sie auch auf der Preisseite.

Dieselben Regeln wie für Menschen

Für Agenten gibt es kein eigenes Rechtemodell. Ein MCP-Client verbindet sich mit https://<your-opfield>/api/mcp und meldet sich per OAuth im Namen eines Nutzers an. Auf dem Zustimmungsbildschirm wählt der Nutzer die Scopes, die der Client erhält, und diese gehen nie über die Rechte des Nutzers hinaus. Zugriff, der auf Ordner, Knoten oder einzelne Ressourcen beschränkt ist, funktioniert genauso: Ein Agent mit Zugriff auf den Ordner einer App sieht diesen Ordner und sonst nichts. Mit get_my_access kann der Agent abfragen, was ihm gewährt wurde und wo er Ressourcen anlegen darf.

Agenten können mit Ressourcen fast alles tun, was ein Mensch kann. Einiges bleibt bewusst dem Browser vorbehalten: Impersonation, die OAuth-Zustimmung, das Erstellen von API-Tokens oder Autorisierungen sowie die eigene Anmeldung und Sitzungen des Nutzers. Ein Agent kann sich keine zusätzlichen Rechte geben.

Der MCP-Endpunkt akzeptiert nur OAuth-Tokens, die für ihn ausgestellt wurden; REST-API-Tokens funktionieren dort nicht. Der Nutzer braucht außerdem die MCP-Berechtigung, sodass ein Admin entscheidet, wer überhaupt Agenten anbinden darf.

Alles landet im Audit-Log

Jede Aktion eines Agenten durchläuft dieselben Prüfungen wie ein Klick in der Oberfläche und wird im selben Audit-Log festgehalten, mit dem Nutzer und dem Token, von dem sie kam. Was ein Agent über Nacht geändert hat, sehen Sie im Audit-Log.

Schutz vor Versehen

Rechte legen fest, was ein Agent darf. Manche Fehler passieren aber innerhalb dieser Rechte, deshalb hat Opfield zusätzliche Schutzmechanismen:

• Konsolenschutz. Agenten können Befehle in der Konsole eines Knotens als root ausführen und ihn so reparieren. Docker, containerd und Podman sind dort ausgeblendet, und ein Docker-Befehl wird mit dem Hinweis auf das passende Opfield-Werkzeug abgelehnt. Das ist ein Schutz vor Versehen, keine Sicherheitsgrenze: Er verhindert, dass ein Agent einen verwalteten Container an Opfield vorbei ändert.
• Kein SSH auf Knoten. Agenten können keine Befehle per SSH auf Hosts ausführen, die Opfield-Knoten sind. Dafür gibt es die Knotenkonsole mit ihrem Schutz.
• Änderungen an Opfield vorbei werden sichtbar. Wird ein verwalteter Container trotzdem von Hand gestoppt, geändert oder entfernt, löst der eingebaute Alarm „Container changed outside Opfield“ aus.
• Sichere Wiederholungen. Anlege-Operationen akzeptieren einen Idempotenzschlüssel, sodass ein Agent, der nach einem Timeout erneut anfragt, kein Duplikat erzeugt.

Docker-Werkzeuge statt Shell

Der Großteil der Arbeit eines Agenten an Workloads läuft über eigene Werkzeuge statt über Shell-Befehle: Container auf allen Docker-Knoten auflisten, Logs und Metriken lesen, neu starten, ein Image aktualisieren, die Konfiguration ändern, Deployments mit Slots und Rollback, Compose-Projekte, Volumes, Netzwerke sowie Git-Quellen mit ihren Builds. Weil das Opfield-Operationen sind, bleiben Routen, Secure Links und Verfügbarkeit nach einer Änderung stimmig, und jeder Schritt wird protokolliert.

Agenten können außerdem die Dokumentation und Skills von Opfield über MCP lesen, bevor sie etwas ändern.

Beispiel: ein ausgefallener Dienst

Ein Nutzer schreibt einem Agenten: „Die Billing-API liefert seit heute Morgen 502. Finde die Ursache und behebe sie.“ Eine typische Sitzung:

1. find_resource findet die Route und den Container dahinter; get_route zeigt den Upstream.
2. get_docker_container zeigt, dass der Container ständig neu startet und seine Git-Quelle um 07:40 einen neuen Build ausgerollt hat.
3. get_docker_container_logs zeigt, dass der Prozess beim Start beendet wird, weil eine neue Pflicht-Umgebungsvariable fehlt.
4. Der Agent meldet das und bietet zwei Wege an: zurück zum vorherigen Build oder die Variable ergänzen.
5. Der Nutzer entscheidet sich für das Rollback. Der Agent ruft manage_docker_source mit rollback auf und prüft danach Logs und Route erneut: Der Container läuft, die Route antwortet mit 200. Das Rollback steht im Audit-Log unter dem Namen des Nutzers.

Niemand brauchte Shell-Zugriff auf den Server, und der Agent hat nichts außerhalb der Rechte des Nutzers getan.

Erste Schritte

Fügen Sie den MCP-Server mit der Adresse Ihres Opfield in Ihrem Client hinzu, melden Sie sich an und wählen Sie die Scopes. Beginnen Sie mit reinen Lese-Scopes, beobachten Sie im Audit-Log, was der Agent tut, und erweitern Sie den Zugriff, wenn Sie Vertrauen gewonnen haben. Wenn Sie keinen Client einrichten möchten: Der in Opfield eingebaute Assistent nutzt dieselben Werkzeuge und dieselben Regeln.