Funktionsindex

Bereich	Aktuelle Dokumentation
Fragen vor dem Kauf	Opfield evaluieren
Ingress, Domains, Routen, TLS	Ingress im Überblick
Docker-Container und Deployments	Docker im Überblick
Compose-Projekte	Compose-Projekte
Git-Builds und Build Worker	Git-Quellen und Build Worker
Apps und Umgebungen	Apps
Verwaltete und externe Datenbanken	Datenbanken im Überblick
Key-Value-Stores	Key-Value-Stores
Datenbanken und Speicher auf mehreren Servern	Datenbanken und Speicher auf mehreren Servern
Backup und Wiederherstellung von Datenbanken	Datenbank-Backups
Speicherverbindungen und verwalteter Objektspeicher	Speicher
Private Datenbank-Bindings	Anwendungs-Bindings für Datenbanken
Pages	Pages im Überblick
Hosting-Anbieter: VMs aus Cloud-Konten und Proxmox als Nodes	Hosting-Anbieter
Relay-Pool und geschützte Relays	Relay und Relay-Pool, Geschützte Relays
Verbindung mit dem Cloud-Konto	Opfield Cloud
Monitoring, Logs, Benachrichtigungen und Status	Monitoring und Betriebssignale
Identität und Berechtigungen	Authentifizierung, Benutzer und Gruppen
AI Workspace	AI Workspace
Opfield Inference	Opfield Inference
Sicherheit und Betrieb	Sicherheitsmodell

Verfügbarkeit und Zielversionen

• Apps – verfügbar in 2.12, in jedem Tarif: Gruppieren Sie die Ressourcen einer Anwendung in Umgebungen mit erlaubten Nodes, gemeinsamen Variablen und Secrets, Wartung, Übernahme per Image-Digest, Herunterfahren und einem Notschalter. Ein Benutzer, der eine Ressource in einer App sehen kann, sieht auch die App, beschränkt auf die Ressourcen, die er sehen kann. Siehe Apps.
• Datenbanken und Speicher auf mehreren Servern – verfügbar in 2.12, Business/Enterprise: verwaltetes PostgreSQL, Key-Value-Stores, ClickHouse und SeaweedFS-Speicher auf 2 bis 5 Storage Nodes mit automatischem Failover über Witnesses oder ein repliziertes Paar mit manuellem Failover. Siehe Datenbanken und Speicher auf mehreren Servern.
• Valkey-Key-Value-Stores – verfügbar in 2.12, ab Personal: Neue verwaltete Key-Value-Stores laufen mit Valkey und funktionieren mit Redis-Clients; ältere Stores werden mit Move to Valkey umgezogen. Siehe Key-Value-Stores.
• Geschützte Relays und Cloud-Verbindung – verfügbar in 2.12, in jedem Tarif. Siehe Geschützte Relays und Opfield Cloud.
• Workload Availability (HA) – verfügbar, Business/Enterprise: Replikation oder Failover für Container ohne Mounts, Deployments und ganze Compose-Projekte, mit optionaler Prioritätsreihenfolge der Nodes und automatischer Rückkehr zum primären Node. Wenn alle Beteiligten 2.11 ausführen, führen die Nodes das Failover selbst ohne Opfield durch (Failover der Datenebene). Siehe den HA-Leitfaden.
• Ingress-Gruppen – verfügbar, Business/Enterprise: eine Route, Domain, Pages-Site oder die Statusseite, die von mehreren nginx-Ingress-Nodes gleichzeitig bedient wird, mit Auslieferung, Health-Zustand und Logs pro Mitglied sowie einem Health-Endpunkt für Load Balancer. Siehe Ingress-Gruppen.
• Speicher – verfügbar in 2.11, ab Personal: Verbindungen zu S3-kompatiblem, FTP-, FTPS- und SFTP-Speicher sowie verwalteter SeaweedFS-Objektspeicher mit privaten Workload-Verbindungen und Secure Links. Siehe Speicher.
• Container-Links – verfügbar in 2.11.1, ab Personal: privater Zugriff von einem Container, Deployment oder Compose-Dienst auf einen Port eines anderen Workloads, auf demselben oder einem anderen Node, ohne veröffentlichten Port. Siehe Container-Links.
• Backup und Wiederherstellung von Datenbanken – verfügbar in 2.11, ab Personal: native Backups verwalteter und externer PostgreSQL-, Key-Value- und ClickHouse-Datenbanken in Speicherverbindungen. Siehe Datenbank-Backups.
• Konfigurationsexport von Opfield zur Übertragung auf eine andere Instanz – verfügbar in 2.12, in jedem Tarif. Siehe Konfigurationsexport.

Künftige Versionen sind Schätzungen. Die Tarifmatrix listet nur auf, was im Produkt enthalten ist; die Roadmap listet den Rest mit den vorgesehenen Tarifen.

Die allgemeine Opfield-CLI wird in 2.13 in jedem Tarif erwartet, der Bastion-/SSH-Verwaltungsdaemon in 2.14 für Business und Enterprise. Das Plugin-System ist separat als künftige Kerninfrastruktur dokumentiert: noch nicht implementiert, vorläufig nicht vor 2.20, ohne garantierten Veröffentlichungstermin.

Funktionsstatus

Status	Bedeutung
Ready	Im aktuellen Produkt verfügbar, abhängig von Tarif und Laufzeitvoraussetzungen
Ready, opt-in	Verfügbar, aber verborgen oder inaktiv, bis ein Administrator es aktiviert
Plan benefit	Kommerzieller Vorteil oder Vorteil auf Service-Level-Ebene statt einer Laufzeitfunktion

Aufnahme in den Tarif und Laufzeitbereitschaft sind getrennt. Funktionen, die noch nicht im Produkt sind, stehen nicht in der Tarifmatrix; die Roadmap nennt die Tarife, für die sie vorgesehen sind.

Verwenden Sie diesen Index, um drei Fragen der Evaluierung zu beantworten: ob Opfield für den Ablauf zuständig ist, welche Infrastrukturvoraussetzung ihn bereitstellt und welcher Tarif ihn zulässt. Eine Funktion kann dokumentiert und lizenziert, aber auf einer bestimmten Installation nicht verfügbar sein, weil die erforderliche Node-Rolle, der Connector, der Anbieter oder die Laufzeitfähigkeit nicht fehlerfrei ist.

Aktuelle Produktfamilien

• Ingress: Domains, Routen, TLS, Zugriffslisten, Wartung, Health Checks, verwaltete Upstreams und nginx-Platzierung.
• Apps (jeder Tarif): Umgebungen, erlaubte Nodes, gemeinsame Variablen und Secrets, Wartung mit Zugangscodes, Übernahme, Herunterfahren und Starten sowie der Notschalter.
• Docker: eigenständige Container, Blue/Green-Deployments, Compose-Inventar und -Lebenszyklus, Images, Volumes, Netzwerke, Registries, Builds, Migrationen, Archive, Tasks, Monitoring und Container-Links. Verwalteter Compose-Lebenszyklus, Blue/Green-Deployments, Migrationen, Archive, Disk-Image-Volumes und Container-Links erfordern Personal oder höher; Git-Builds und Secure Runtime erfordern Business oder höher.
• Datenbanken (ab Personal): externe Verbindungen, verwaltetes PostgreSQL, Key-Value-Stores (Valkey, kompatibel mit Redis-Clients) und ClickHouse, Explorer, Monitoring, direktes TLS, private Anwendungs-Bindings, geplantes Backup und Wiederherstellung sowie in Business und Enterprise mehrere Server mit Failover.
• Speicher (ab Personal): S3-kompatible, FTP-, FTPS- und SFTP-Verbindungen mit einem Objektbrowser, verwalteter SeaweedFS-Objektspeicher mit Zugriffsschlüsseln, privaten Workload-Verbindungen und optionalen öffentlichen Listenern, serverseitige Kopieraufträge zwischen S3-Speichern und eine vom Assistenten gesteuerte Migration älterer MinIO-Cluster.
• Pages (ab Personal): unveränderliche statische Deployments, Tags, Routen, Vorschauen und optionale Git-Builds (ab Business).
• Nodes und Relay: rollenbasierte Registrierung, Meldung von Fähigkeiten, signierte Updates, Monitoring, Relay-Betrieb mit mehreren Mitgliedern und geschützte Relays.
• Identität: Benutzer, Gruppen, MFA, OIDC, Tokens, OAuth, Ressourcen-Scopes und Identitätswechsel (Impersonation).
• Betriebliche Transparenz: Health-Zustand, Metriken, Logs, Tasks, Alarme, Benachrichtigungen, Statusseiten (ab Personal), strukturiertes Logging (ab Business), Audit mit Export ab Business und SIEM (Enterprise). Jedes Signal wird an der Ressource angezeigt, zu der es gehört.
• Automatisierung und KI: REST, OAuth, MCP, AI-Workspace-Chat und Opfield Inference in jedem Tarif; AI Plan Mode, Scenarios und Sandboxes ab Personal.
• Sicherheit: System-PKI, benutzerseitige interne PKI (Enterprise), verschlüsselte Secrets, Audit, Zulassungsgrenzen und Lebenszyklusprüfungen, die im Zweifel ablehnen (fail closed).

Laufzeitvoraussetzungen

Ein Leistungsumfang aus dem Tarif ersetzt keine Fähigkeit des Hosts. Secure Runtime benötigt eine fehlerfreie gVisor-Fähigkeit, Git-Builds benötigen einen dedizierten Build Worker, verwaltete Datenbanken benötigen einen vorbereiteten Storage Node, öffentlicher Ingress benötigt einen erreichbaren Ingress Node, und private Verbindungen benötigen einen fehlerfreien Relay-Pfad.

Prüfen Sie auf der jeweiligen Funktionsseite Voraussetzungen, Folgen für den Lebenszyklus und Wiederherstellungsverhalten, bevor Sie eine Funktion in der Produktion aktivieren. Zum Verhalten der Tarife siehe Tarife und Leistungsumfang.

Weg der Evaluierung

Um Opfield zu evaluieren, betreiben Sie eine echte Anwendung von Anfang bis Ende: eine öffentliche Anwendung, ihre private Datenbank, die Nodes, auf denen sie läuft, und die Personen, die sie betreiben. Prüfen Sie auf diesem Weg Deployment, Zugriffskontrolle, Kundenverkehr, Monitoring, Wiederherstellung nach Fehlern und Audit, und fügen Sie dann die Funktionen hinzu, die Ihr Betriebsmodell benötigt, etwa Git-Builds, Pages, verwaltete Datenbanken, KI oder SIEM.

Halten Sie jedes Ergebnis fest als:

• unterstützt und geprüft auf der getesteten Installation;
• unterstützt mit nicht erfüllter Voraussetzung;
• durch den Tarif eingeschränkt;
• in Entwicklung; oder
• außerhalb der Produktgrenze von Opfield.

So vermeiden Sie, eine Positionierung auf der Roadmap, ein deaktiviertes Bedienelement und eine fehlgeschlagene Laufzeitfähigkeit als dasselbe zu behandeln.

Produktgrenze

Opfield betreibt Ingress, Workloads, Datenbanken, Objektspeicher, Backups, Monitoring, Logging, Alarme, Statusseiten und Zugriff für alles auf seinen Nodes; welche Werkzeuge es ersetzt, steht unter Warum Opfield. Außerhalb liegen das Betriebssystem des Hosts selbst (OS-Updates und Host-Sicherheit bleiben bei Ihnen) sowie Workload-Formate außer Containern und Compose-Projekten: Opfield führt keine Kubernetes-Manifeste oder Helm-Charts aus.