Tarife und Leistungsumfang

Opfield verwendet die Tarife Community, Personal, Business und Enterprise. Verfügbarkeit, Bedingungen für die kommerzielle Nutzung, die Lizenzierung von Opfield-Deployments und Kontingente separat gehosteter Dienste sind unterschiedliche Konzepte.

Wählen Sie einen Tarif anhand der betrieblichen Anforderungen, nicht anhand der Unternehmensgröße. Beginnen Sie mit den Abläufen, die unterstützt werden müssen, den Ressourcengrenzen, die sie benötigen, den Sicherheitskontrollen, die Ihre Richtlinien verlangen, und den Support- oder kommerziellen Bedingungen, die der Käufer benötigt. Der Eigentümer der Installation ist für die Überwachung des Lizenzzustands verantwortlich; Ressourcenverantwortliche sollten wissen, welche Operationen von kostenpflichtigem Leistungsumfang abhängen.

Kostenpflichtige Funktionen im Status Ready werden an der Operationsgrenze ebenso wie in der Oberfläche durchgesetzt. Endet ein kostenpflichtiger Tarif, läuft die bestehende Infrastruktur weiter: Nach der Kulanzfrist sind das Erstellen kostenpflichtiger Ressourcen und das Ändern ihrer Konfiguration gesperrt, während bestehende kostenpflichtige Ressourcen weiter funktionieren. Widerruf, Übertragung auf eine andere Installation und Deaktivierung haben keine Kulanzfrist. Kulanzfristen und die genaue Verfügbarkeit von Funktionen können sich mit Produkt-Releases ändern; prüfen Sie vor einer Veröffentlichung die aktuelle Matrix.

Community-Installationen benötigen keinen Schlüssel. Ein Personal-, Business- oder Enterprise-Schlüssel steht für eine aktive Opfield-Instanz; Ressourcenkontingente innerhalb einer Opfield-Instanz dürfen nicht mit Kontingenten separat gehosteter Dienste verwechselt werden.

Selbst hosten und verwaltete Cloud

Jeder Tarif – Community, Personal, Business und Enterprise – kann selbst gehostet werden. Ein kostenpflichtiger Schlüssel schaltet kostenpflichtige Funktionen und Grenzen auf einer Installation frei, die Sie betreiben; kein Tarif setzt voraus, dass Opfield die Control Plane hostet. Die verwaltete Cloud, bei der das Opfield-Team die Control Plane betreibt, ist eine Zusatzoption für die Tarife Personal und Business, die zusammen mit dem Lizenzschlüssel in Ihrem Opfield-Konto verkauft wird; eine verwaltete Installation überspringt den Einrichtungsassistenten, und ihr Eigentümer meldet sich zuerst mit dem Opfield-Konto an und kann später auf sein eigenes SSO oder eine andere Anmeldemethode wechseln. In einer selbst gehosteten Installation bleiben verschlüsselte Zugangsdaten und der Master-Schlüssel in Ihrer Umgebung; siehe Wo Secrets in einer selbst gehosteten Installation liegen. Häufige Fragen vor dem Kauf beantwortet Opfield evaluieren.

Tarifstufen

Tarif	Typische Grenze der Funktionen
Community	Grundlegender Ingress, Docker, Apps, Erkennung externer Compose-Projekte, Monitoring, Identität, REST API, Automatisierung über OAuth und MCP, AI-Workspace-Chat, Inference sowie bis zu 25 verwaltete Nodes, 3 Benutzer und 1 benutzerdefinierte Berechtigungsgruppe
Personal	Community plus externe Datenbankverbindungen, Speicherverbindungen, verwaltete Datenbanken und Objektspeicher, Container-Links, Backup und Wiederherstellung von Datenbanken, GitLab-Integration, AI Plan Mode, Scenarios und Sandboxes, verwalteter Compose-Lebenszyklus auf einem Node, Pages, Statusseiten, Archiv- und Migrationsoperationen sowie unbegrenzte dokumentierte Grundkontingente
Business	Personal plus Workload Availability (HA) über mehrere Nodes, Ingress-Gruppen, verwaltete Datenbanken und Objektspeicher auf mehreren Servern, Git Push-to-Deploy, isolierte Build Worker, Secure Runtime, Zulassung nach Schwachstellenprüfung, strukturiertes Logging, Audit-Export und optionaler Zugriff auf die externe Registry
Enterprise	Business plus interne PKI, Audit-Export an SIEM und dedizierte kommerzielle Vorteile

Die genaue Funktionsmatrix ist release-spezifisch. Produktseiten nennen Voraussetzungen, und diese Seite erklärt das Verhalten im Lebenszyklus; Preise und Vertragsbedingungen gehören in die jeweilige kommerzielle Vereinbarung. Die aktuell veröffentlichten Preise stehen auf der Opfield-Website.

Guided Onboarding and Configuration Review (Business und Enterprise) und Assisted Deployment and Migration (Enterprise) sind Tarifvorteile, die das Opfield-Team erbringt, keine Laufzeitfunktionen; ihr Umfang wird durch die kommerzielle Vereinbarung festgelegt. In jedem Tarif gibt Ihren Stack zu Opfield umziehen die Reihenfolge des Umzugs vor.

Funktionsmatrix

Funktion	Status	Community	Personal	Business	Enterprise
Verwaltung von Infrastruktur-Nodes	Ready	✅	✅	✅	✅
Verwaltung von nginx-Ingress auf mehreren Nodes	Ready	✅	✅	✅	✅
Verwaltung von Docker-Containern – Default Runtime (runc)	Ready	✅	✅	✅	✅
Erkennung, Monitoring und Logs externer Compose-Projekte	Ready	✅	✅	✅	✅
Secure Links zwischen Docker und Nginx	Ready	✅	✅	✅	✅
Private, von Opfield verwaltete interne Docker-Registry	Ready	✅	✅	✅	✅
Verwaltung von SSL/TLS-Zertifikaten	Ready	✅	✅	✅	✅
Verwaltung von Domains und DNS	Ready	✅	✅	✅	✅
Infrastruktur-Monitoring	Ready	✅	✅	✅	✅
Erkennung, Zuweisung und Monitoring physischer GPUs	Ready	✅	✅	✅	✅
Alarme und Webhook-Benachrichtigungen	Ready	✅	✅	✅	✅
Authentifizierung, OIDC und MFA	Ready	✅	✅	✅	✅
Rollenbasierte Zugriffskontrolle mit Ordner- und Ressourcen-Scopes	Ready	✅	✅	✅	✅
Apps mit Umgebungen, gemeinsamen Variablen, Übernahme, Herunterfahren und Notschalter	Ready	✅	✅	✅	✅
Verbindung mit einem Opfield-Cloud-Konto	Ready, opt-in	✅	✅	✅	✅
Geschützte Relays auf Maschinen anderer Eigentümer	Ready, opt-in	✅	✅	✅	✅
Audit-Log	Ready	✅	✅	✅	✅
Automatisierung über REST API, OAuth und MCP	Ready	✅	✅	✅	✅
AI-Workspace-Chat	Ready, opt-in	✅	✅	✅	✅
Opfield Inference	Ready, opt-in	✅	✅	✅	✅
Automatisierte Installation und signierte Updates	Ready	✅	✅	✅	✅
Konfigurationsexport von Opfield zur Übertragung auf eine andere Instanz	Ready	✅	✅	✅	✅
Verwaltete Nodes	Plan limit	25	Unbegrenzt	Unbegrenzt	Unbegrenzt
Benutzer	Plan limit	3	Unbegrenzt	Unbegrenzt	Unbegrenzt
Benutzerdefinierte Berechtigungsgruppen	Plan limit	1	Unbegrenzt	Unbegrenzt	Unbegrenzt
Support-Level	Service level	Community	Standard	Priorität	Priorität + dediziert
Externe Datenbankverbindungen und Explorer	Ready	—	✅	✅	✅
Speicherverbindungen: S3, R2, MinIO und andere S3-kompatible Dienste, FTP, FTPS und SFTP	Ready	—	✅	✅	✅
GitLab-Integration	Ready	—	✅	✅	✅
Plan Mode, Scenarios und AI Sandboxes im AI Workspace	Ready, opt-in	—	✅	✅	✅
Export und Import von Containern	Ready	—	✅	✅	✅
Docker-Volumes als Disk-Images	Ready	—	✅	✅	✅
Blue/Green-Deployments	Ready	—	✅	✅	✅
Migration von Containern und Deployments zwischen Nodes	Ready	—	✅	✅	✅
Verwaltetes Compose-Deployment und Lebenszyklus auf einem Node	Ready	—	✅	✅	✅
Verwaltete Datenbanken mit Secure Links	Ready	—	✅	✅	✅
Öffentliche Statusseiten	Ready, opt-in	—	✅	✅	✅
Pages	Ready	—	✅	✅	✅
Automatische Erkennung der GitLab Container Registry	Ready	—	✅	✅	✅
Backup und Wiederherstellung verwalteter und externer Datenbanken	Ready	—	✅	✅	✅
Verwalteter Objektspeicher (SeaweedFS, ein Node) mit privaten Bindings und Secure Links	Ready	—	✅	✅	✅
Container-Links zwischen Workloads auf demselben oder verschiedenen Nodes	Ready	—	✅	✅	✅
Docker Secure Runtime (runsc/gVisor)	Ready	—	—	✅	✅
Git Push-to-Deploy für Container, Deployments, Compose und Pages; isolierte Build Worker	Ready	—	—	✅	✅
Zugriff externer Docker-Clients auf die interne Registry	Ready, opt-in	—	—	✅	✅
Workload Availability über mehrere Nodes (Container, Deployment, Compose)	Ready	—	—	✅	✅
Ingress-Gruppen: Routen, Domains, Pages und die Statusseite, bedient von mehreren Ingress Nodes	Ready	—	—	✅	✅
Verwaltete Datenbanken und Objektspeicher auf mehreren Servern mit automatischem oder manuellem Failover	Ready	—	—	✅	✅
Schwachstellenprüfung und Zulassungsrichtlinie für Git-Builds	Ready	—	—	✅	✅
Strukturiertes Logging	Ready, opt-in	—	—	✅	✅
Export des Audit-Logs	Ready	—	—	✅	✅
Guided Onboarding and Configuration Review	Plan benefit	—	—	✅	✅
Interne PKI	Ready	—	—	—	✅
Audit-Export an SIEM	Ready, opt-in	—	—	—	✅
Dedizierter technischer Ansprechpartner	Plan benefit	—	—	—	✅
Assisted Deployment and Migration	Plan benefit	—	—	—	✅

Neu in 2.12: Apps in jedem Tarif sowie verwaltete Datenbanken und Objektspeicher auf mehreren Servern in Business und Enterprise, einschließlich replizierter Paare mit manuellem Failover. Apps prüfen nie die Lizenz: Eine App, ihre Umgebungen, die Übernahme, das Herunterfahren und der Notschalter funktionieren in jedem Tarif gleich, während jede Ressource in einer App ihre eigene Tarifanforderung behält. Speicherverbindungen, verwalteter Objektspeicher sowie Backup und Wiederherstellung von Datenbanken sind neu in 2.11; Workload Availability (HA) bleibt in Business und Enterprise verfügbar. Der Konfigurationsexport von Opfield zur Übertragung auf eine andere Instanz ist in 2.12 in jedem Tarif verfügbar. SMB ist kein unterstützter Typ von Speicherverbindungen.

Voraussetzungen und Grenzen von HA stehen unter Workload Availability, aktuelle manuelle Wiederherstellungsverfahren unter Updates und Backups.

Roadmap

Die folgenden Funktionen sind noch nicht im Produkt und fehlen daher in der Matrix oben. Zu jeder sind die vorgesehenen Tarife genannt. Eine Zielversion ist eine Schätzung; ein als Planned markierter Eintrag hat noch keine Zielversion.

Funktion	Vorgesehene Tarife	Ziel
Allgemeine Opfield-CLI für Terminals und CI/CD	Community, Personal, Business, Enterprise	2.13
Bastion-/SSH-Verwaltungsdaemon	Business, Enterprise	2.14
Umfassendere Schwachstellen- und Sicherheitsprüfung von Workloads	Business, Enterprise	Planned
Autoskalierung nach Metriken	Business, Enterprise	Planned
Mehrere Instanzen eines Workloads auf einer Maschine	Business, Enterprise	Planned
Zuordnung von OIDC-Gruppen und SCIM-Bereitstellung	Enterprise	Planned

Die Schwachstellenprüfung von Git-Builds ist bereits verfügbar und von der umfassenderen Prüfung von Workloads getrennt. Das Plugin-System ist unfertige Kerninfrastruktur von Opfield, keine Tariffunktion; sein vorläufiger Zeitpunkt liegt nicht vor 2.20, ohne zugesagten Veröffentlichungstermin.

Durchsetzung

Kostenpflichtige Funktionen im Status Ready werden an den Operationsgrenzen des Backends ebenso wie in der Konsole durchgesetzt. REST, OAuth, MCP, AI Workspace, Hintergrund-Worker und öffentliche Token-Endpunkte umgehen die Prüfungen des Leistungsumfangs nicht.

Fehlender Leistungsumfang führt zu einem Fehler, ohne bestehende Ressourcen zu löschen. Prüfungen im öffentlichen Opfield-Kern liefern LICENSE_ENTITLEMENT_REQUIRED (HTTP 403). Bereiche, die der kommerzielle Kern implementiert – zum Beispiel Datenbanken, Speicher, Backups, GitLab, Pages und die benutzerseitige PKI –, sind in einem Tarif ohne sie in der Konsole ausgeblendet – das Öffnen über ihre Adresse zeigt den Seitenkopf mit einem Tarifhinweis – und über die API nicht verfügbar, bis der erforderliche Tarif und Kern aktiv sind. Eine Ablehnung aufgrund des Tarifs erscheint nie als Fehlermeldung: Das Laden einer Seite bleibt still, und eine Aktion öffnet den Tarifdialog. Erreichte Tarifkontingente liefern LICENSE_QUOTA_EXCEEDED (HTTP 409), wobei die aktuellen Datensätze erhalten bleiben. Eine Inkonsistenz einer geschützten Richtlinie führt zur Ablehnung, statt einen großzügigeren Tarif anzunehmen.

Community-Kontingente für verwaltete Nodes, Benutzer und benutzerdefinierte Berechtigungsgruppen werden nur geprüft, wenn Sie eines davon erstellen, wenn ein Benutzer bei der ersten Anmeldung über OIDC bereitgestellt wird oder wenn ein gelöschter Benutzer wiederhergestellt wird. Die Zahl der Nodes umfasst ausstehende und Offline-Nodes. Nodes, Benutzer und Gruppen, die ein Kontingent bereits überschreiten – zum Beispiel nach einem Downgrade oder einem Upgrade von 2.10 –, funktionieren weiter und werden nie gelöscht oder deaktiviert. Prüfungen des Leistungsumfangs lesen den in der Installation zwischengespeicherten Lizenzzustand, sodass eine einzelne Operation nie auf den Lizenzdienst wartet.

Kommerzieller Kern

Community und kostenpflichtige Tarife verwenden dieselben Opfield-Images. Kostenpflichtige Funktionen werden als separat signierter kommerzieller Kern ausgeliefert, den Opfield für eine Installation, die eine kostenpflichtige Aktivierung hat oder hatte, vom Lizenzdienst herunterlädt und vor der Verwendung prüft: Signatur, genaue Opfield-Version, Dateigrößen und Hashes müssen übereinstimmen. Opfield lädt den Kern nur beim Start.

Das Aktivieren eines kostenpflichtigen Schlüssels unter Settings > General > License bereitet den passenden Kern über den signierten Update-Mechanismus vor, während Opfield weiter Anfragen bedient, und startet Opfield dann neu, um ihn zu laden. Schlägt die Vorbereitung fehl, bleibt der Schlüssel aktiviert, und Enable paid features versucht es erneut. Ein im Einrichtungsassistenten aktivierter Schlüssel bereitet den Kern nicht vor; öffnen Sie danach die Lizenzeinstellungen und wählen Sie Enable paid features. Ist ein gültiger Schlüssel vorhanden, fehlt der Kern aber oder wird er abgelehnt, meldet die Konsole, dass kostenpflichtige Funktionen nicht bereit sind – etwas anderes als ein unzureichender Tarif –, und die bestehende Infrastruktur läuft weiter.

Upgrade einer Community-Installation von 2.10

2.11 wendet die neuen Community-Grenzen und die neue Funktionsliste unmittelbar nach dem Upgrade an:

• Nodes, Benutzer und Gruppen über 25, 3 bzw. 1 funktionieren weiter, aber Sie können keine weiteren hinzufügen.
• Bestehende externe Datenbankverbindungen, GitLab-Connectors und Daten des AI Plan Mode bleiben in der Datenbank erhalten, können in Community aber nicht geöffnet werden. Datenbank-Monitoring und GitLab-Synchronisierung stoppen.
• Andere Community-Funktionen, darunter Docker, Ingress, TLS, Monitoring, Identität, Automatisierung über API und MCP, AI-Workspace-Chat und Opfield Inference, laufen unverändert weiter.

Das Anwenden eines Schlüssels für Personal oder höher stellt den Zugriff auf die erhaltenen Datensätze wieder her.

Vor 2.11 ausgestellte kostenpflichtige Schlüssel behalten ihren Tarif. Personal-, Business- und Enterprise-Schlüssel mit einem älteren Format des Leistungsumfangs umfassen die neuen Funktionen Speicherverbindung, externe Datenbankverbindung, verwalteter Speicher, Container-Link, Disk-Image-Volume sowie AI Plan Mode, Scenarios und Sandboxes.

Kommunikation mit dem Lizenzdienst

Opfield führt eine signierte Liste der Adressen des Lizenzdienstes und verwendet die, die antwortet. Erlauben Sie https://license.opfield.dev in einer Egress-Allowlist, zusammen mit dem Update-Host https://get.opfield.dev. Um Lizenzanfragen über eine eigene Adresse zu senden, etwa einen Egress-Proxy, setzen Sie LICENSE_SERVICE_URL in der .env von Opfield (mehrere Adressen durch Kommas getrennt) und starten Opfield neu; diese Adresse wird zuerst versucht. Opfield kontaktiert den Lizenzdienst nur zu folgenden Zwecken:

Anfrage	Wann	Gesendete Daten
Die Installation registrieren	Beim ersten Start oder wenn das gespeicherte Installationstoken nicht mehr gültig ist	Installations-ID, eine lokal erzeugte Registrierungs-Nonce, Installationsname, Opfield-Version und Schemaversion des Leistungsumfangs
Heartbeat	Kurz nach dem Start, dann alle 15 Minuten mit einem kostenpflichtigen Schlüssel oder alle 30 Minuten in Community, und wenn ein Administrator eine manuelle Prüfung auswählt	Installationstoken, Installationsname, Opfield-Version und Schemaversion des Leistungsumfangs
Einen Schlüssel aktivieren oder deaktivieren	Wenn ein Administrator einen kostenpflichtigen Schlüssel anwendet oder entfernt	Installationstoken und Schemaversion des Leistungsumfangs, bei der Aktivierung zusätzlich der kostenpflichtige Schlüssel
Ein Release autorisieren	Vor einem Opfield-Update und wenn kostenpflichtige Funktionen aktiviert werden	Installationstoken, Ziel-Version von Opfield und Schemaversion des Leistungsumfangs
Den kommerziellen Kern herunterladen	Während eines Updates oder der Aktivierung kostenpflichtiger Funktionen einer Installation, die eine kostenpflichtige Aktivierung hat oder hatte	Installationstoken, Ziel-Version von Opfield, Release-ID, Dateipfad und Schemaversion des Leistungsumfangs

Jede Anfrage enthält außerdem eine zufällige Anfrage-Nonce und die IDs der Signaturschlüssel, die das Opfield-Release fest hinterlegt. Die Installations-ID ist eine zufällige Kennung, die die Installation erzeugt. Der Installationsname ist der Hostname der konfigurierten öffentlichen URL von Opfield oder der Hostname des Servers, wenn keine öffentliche URL gespeichert ist. Opfield sendet keine Infrastrukturkonfiguration, Ressourceninhalte, Secrets, Logs, Benutzer- oder Ressourcenzahlen, Prompts oder Modellantworten. Lizenzschlüssel, Installationstoken und Registrierungs-Nonce werden verschlüsselt in der Installation gespeichert. Community-Installationen bleiben nutzbar, während die Registrierung aussteht oder der Dienst nicht erreichbar ist. Das Aktivieren eines kostenpflichtigen Schlüssels und das Aktualisieren einer Installation, die einen kostenpflichtigen Tarif hat oder hatte, erfordern einen erreichbaren Dienst; ein abgelehntes oder fehlgeschlagenes Update lässt die aktuelle Version weiterlaufen. Eine Community-Installation ohne Schlüssel, kostenpflichtigen Tarif oder kommerziellen Kern wird auch aktualisiert, wenn der Dienst nicht erreichbar ist, weil sie nichts Privates herunterlädt. Siehe Updates, Backups und Wiederherstellung.

Signierte Lizenzzustände

Der Lizenzdienst signiert jeden Lizenzzustand, den er zurückgibt – für Registrierung, Heartbeats, Aktivierung, Deaktivierung und Autorisierung von Releases –, mit Ed25519. Die Signatur umfasst Installations-ID, Zweck der Anfrage, Anfrage-Nonce, Ausstellungszeit und den vollständigen Zustand einschließlich Tarif, Leistungsumfang, Ablauf und Ende der Kulanzfrist. Opfield-Releases hinterlegen die öffentlichen Schlüssel des Dienstes fest und wenden einen Zustand nur an, wenn:

• die Signatur für einen hinterlegten Schlüssel gültig ist;
• der Zustand für diese Installation und für Zweck und Nonce dieser Anfrage signiert wurde, sodass eine abgefangene Antwort weder wiederholt noch von einer anderen Installation verwendet werden kann;
• die Ausstellungszeit höchstens 15 Minuten von der lokalen Uhr abweicht.

Eine unsignierte, gefälschte, wiederholte, fremde oder veraltete Antwort wird wie ein nicht erreichbarer Dienst behandelt: Der letzte gültige signierte Zustand bleibt in Kraft, und die Offline-Kulanzfrist läuft ab seiner Ausstellungszeit weiter. Registrierung und Aktivierung schlagen fehl, statt Zugangsdaten aus einer unsignierten Antwort zu speichern, und das Herunterladen des kommerziellen Kerns wird nur durch einen signierten Zustand für diese Anfrage autorisiert. Opfield speichert die signierten Zustände und prüft sie bei jedem Lesen der Lizenz erneut, sodass das Bearbeiten der zwischengespeicherten Lizenz in der Datenbank den Tarif nicht anheben kann. Halten Sie die Uhr des Opfield-Hosts synchron; eine Uhr, die mehr als 15 Minuten abweicht, lässt jede Antwort veraltet erscheinen.

Downgrade und Ablauf

Ein kostenpflichtiger Tarif kann durch Ablauf, ein Downgrade auf einen niedrigeren Tarif, einen nicht erreichbaren Lizenzdienst, Widerruf, Übertragung des Schlüssels auf eine andere Installation oder ausdrückliche Deaktivierung enden. Bis die zugehörige Kulanzfrist endet, funktioniert alles wie zuvor, einschließlich der Weiterleitung an SIEM und des Zugriffs externer Docker-Clients auf die interne Registry.

Ursache	Kulanzfrist	Gerechnet ab
Ablauf	24 Stunden bei Personal, 3 Tage bei Business, 7 Tage bei Enterprise	Dem Ablaufdatum
Lizenzdienst nicht erreichbar	100 Tage, nie über die Kulanzfrist für den Ablauf hinaus	Der Ausstellungszeit des letzten gültigen signierten Lizenzzustands
Downgrade auf einen niedrigeren kostenpflichtigen Tarif	Die Kulanzfrist des höheren Tarifs: 24 Stunden, 3 Tage oder 7 Tage	Dem letzten signierten Zustand, der noch den höheren Tarif meldete
Widerruf, Übertragung auf eine andere Installation, Deaktivierung, ungültiger Schlüssel	Keine	—

Während der Kulanzfrist nach Ablauf lautet der Lizenzstatus Expired — grace period, und das Dashboard zeigt eine Warnung; während der Dienst nicht erreichbar ist, lautet er Licensed with warning. Opfield wertet die Fristen lokal aus und wartet nicht auf einen weiteren Heartbeat.

Nach der Kulanzfrist – oder unmittelbar nach Widerruf, Übertragung oder Deaktivierung – verwenden neue Aktionen den Leistungsumfang von Community, während bestehende kostenpflichtige Ressourcen einen Fortführungsumfang für den höchsten kostenpflichtigen Tarif behalten, den die Installation nachweislich durch einen gespeicherten signierten Lizenzzustand hatte:

• Funktioniert weiter: alle bestehenden Workloads und die Datenebene – Container, Deployments, Compose-Projekte, Routen, Secure Links, Bindings verwalteter Datenbanken und Speicher, Relays, veröffentlichte Pages-Deployments, Zertifikatssperrlisten der internen PKI und die Aufnahme strukturierter Logs. Bestehende geplante Backups, ihre Aufbewahrung, Run now, Abbruch und Wiederherstellungen in bestehende Datenbanken laufen weiter. Workload Availability heilt weiter und kann bestehende Workloads starten, stoppen und neu starten. Datenbanken und Speicher auf mehreren Servern führen weiter Failover durch, und Sie können weiterhin den Primärserver wechseln, eine Kopie neu aufbauen, einen Server entfernen und die Verfügbarkeit ausschalten. Bestehende GitLab-Connectors synchronisieren weiter. Bestehende kostenpflichtige Ressourcen können Sie weiterhin ansehen, ihre Logs und ihr Monitoring lesen, Verbindungen testen, Zugangsdaten anzeigen und rotieren, Zertifikate widerrufen und exportieren und sie löschen.
• Pausiert: die Weiterleitung an SIEM und die Ausgabe von Tokens für den Zugriff externer Docker-Clients auf die interne Registry. Ihre Einstellungen, der externe Einstiegspunkt der Registry und der Zustellverlauf von SIEM bleiben erhalten, und bereits für SIEM eingereihte Datensätze werden nach der Verlängerung zugestellt; Audit-Ereignisse, die auftreten, während die Weiterleitung pausiert ist, werden nicht eingereiht. Beides wird nach der Verlängerung ohne Neukonfiguration fortgesetzt.
• Gesperrt: das Erstellen kostenpflichtiger Ressourcen, das Ändern der Konfiguration bestehender kostenpflichtiger Ressourcen, das Schreiben von Daten über die Explorer für Datenbanken und Objektspeicher (das Löschen von Zeilen, Schlüsseln, Objekten und Buckets bleibt möglich), das Wiederherstellen eines Backups in eine neue verwaltete Datenbank sowie Operationen nur für kostenpflichtige Tarife wie Export und Import von Archiven, Migration, Audit-Export und Builds aus Git-Quellen. Erstellungen über die Community-Grenzen für Nodes, Benutzer und Gruppen hinaus werden abgelehnt. Diese liefern LICENSE_ENTITLEMENT_REQUIRED oder LICENSE_QUOTA_EXCEEDED.

Opfield ändert nie gespeicherte Konfiguration, deaktiviert keine Module und löscht keine verwalteten Ressourcen, weil ein Tarif geendet hat. Das Verlängern oder erneute Aktivieren eines Schlüssels stellt den vollen kostenpflichtigen Betrieb wieder her, ohne bestehende Infrastruktur neu aufzubauen. Die Paid Key Terms regeln, ob Sie kostenpflichtige Ressourcen nach einem Widerruf weiter betreiben dürfen; Opfield selbst stoppt sie nicht.

Eine Installation erhält auch nach dem Ende ihres kostenpflichtigen Tarifs weiter Updates. Eine Installation, die eine kostenpflichtige Aktivierung hat oder hatte – auch eine abgelaufene, widerrufene, übertragene oder deaktivierte –, erhält mit jedem Update den passenden kommerziellen Kern, sodass ihre bestehenden kostenpflichtigen Ressourcen nach diesen Regeln weiterlaufen. Eine Installation, die nie einen kostenpflichtigen Tarif hatte, wird als Community aktualisiert.

Betriebliche Prüfungen

• Prüfen Sie die Installations-ID und die vorgesehene aktive Instanz, bevor Sie einen Schlüssel anwenden.
• Überwachen Sie den Ablauf und das lokale Ende der Kulanzfrist.
• Testen Sie benötigte Premium-Operationen vor einem Produktionsstart.
• Halten Sie fest, welche Operationen nach der Kulanzfrist gesperrt werden und dass die Weiterleitung an SIEM und externe Registry-Tokens pausieren.
• Stellen Sie den Leistungsumfang wieder her, bevor Sie erhaltene Ressourcen manuell ersetzen.

Verwenden Sie nicht die alte Bezeichnung homelab und leiten Sie die Verfügbarkeit von Funktionen nicht aus Preistexten, Screenshots oder einem anderen Opfield-Release ab.

Einen Tarif wählen und wechseln

Erstellen Sie ein kurzes Entscheidungsprotokoll mit den benötigten Funktionen, der erwarteten Ressourcenzahl, Umgebungen, Compliance-Kontrollen und der Folge, wenn der Leistungsumfang vorübergehend nicht verfügbar ist. Testen Sie die tatsächlichen Operationen auf dem Ziel-Release vor der Freigabe der Beschaffung. Ein Funktionsname in einem Vertrag oder einer Matrix beweist nicht, dass die Installation die erforderliche Node-Fähigkeit oder den externen Anbieter hat.

Vor einem Downgrade, einem Ablauf oder einer Übertragung auf eine andere Installation:

1. ermitteln Sie Premium-Ressourcen und Automatisierung, die keine neue Arbeit mehr annehmen werden;
2. bewahren Sie Quelleinstellungen, Build-Artefakte, PKI-, Logging- und SIEM-Konfiguration;
3. bestätigen Sie, welche laufenden Ressourcen betriebsbereit bleiben und welche Kulanzfrist gilt;
4. teilen Sie die betriebliche Frist und den Verantwortlichen mit;
5. stellen Sie den Leistungsumfang wieder her und bestätigen Sie, dass die pausierte Weiterleitung an SIEM und der externe Registry-Zugriff wieder laufen;
6. prüfen Sie die Kundenpfade, statt anzunehmen, dass die vorherige Konfiguration wieder läuft.

Löschen Sie erhaltene Ressourcen nicht, um eine Warnung zum Leistungsumfang „aufzuräumen“. Ihr erhaltener Zustand ist der Wiederherstellungsweg, nachdem der richtige Tarif zurückgekehrt ist.

Grenzen der Lizenzierung

Die Opfield-Lizenz deckt die aktive Opfield-Installation gemäß ihrem Schlüssel und ihrer Vereinbarung ab. Zugangsdaten, Kontingente oder Abonnements externer Anbieter – Cloud-DNS, Quellcodeverwaltung, Registries, E-Mail, KI oder andere gehostete Dienste – bleiben davon getrennt. Ebenso ist die von Opfield Inference angezeigte Nutzung eine betriebliche Abrechnung und sollte für kommerzielle Entscheidungen mit dem Anbieter abgeglichen werden.

Der aktuelle Quellcode, unter dem Namen Opfield von seinem Lizenzgeber Alexandr Slavinschii ([email protected]) veröffentlicht, steht unter der PolyForm Perimeter 1.0.1 zur Verfügung. PolyForm Perimeter erlaubt Nutzung, Änderung und Weitergabe für nicht konkurrierende Zwecke, einschließlich gewöhnlicher interner Geschäftsnutzung. Ausgeschlossen ist der Zweck, anderen ein Produkt bereitzustellen, das als Ersatz für Opfield vermarktet wird, sei es als Software, gehosteter Dienst, Portierung oder kostenloses Angebot.

Ein Personal-, Business- oder Enterprise-Schlüssel schaltet Funktionen und Grenzen kostenpflichtiger Tarife frei; er ist nicht schon deshalb erforderlich, weil ein Unternehmen Community intern nutzt. Ein gewöhnlicher Schlüssel gewährt keine Rechte für OEM, White Label, Weiterverkauf, konkurrierende gehostete Dienste oder andere Ersatzprodukte. Diese Nutzungen erfordern eine separate schriftliche Vereinbarung mit dem aktuellen Lizenzgeber. Nach dem Ablauf eines gewöhnlichen Schlüssels erhalten die Fortführungsbedingungen des Schlüssels die vor dem Ablauf konfigurierten Ressourcen kostenpflichtiger Tarife, während neue Erstellungen und Erweiterungen, die nur kostenpflichtigen Tarifen vorbehalten sind, gesperrt werden.

Jedes offizielle Release enthält außerdem den Product Continuity Grant. Er tritt in Kraft, wenn 12 Monate in Folge kein neues Release veröffentlicht wird, während der Lizenzdienst nicht verfügbar ist, wenn der Lizenzgeber das Ende von Opfield bekannt gibt oder wenn der Lizenzgeber stirbt oder nicht mehr handeln kann. Der Lizenzdienst ist der Lizenzierungsdienst, den der Lizenzgeber für Opfield unter einer beliebigen von ihm veröffentlichten Adresse betreibt; er gilt als verfügbar, solange eine dieser Adressen antwortet. Ab diesem Zeitpunkt steht der Quellcode des letzten Releases, einschließlich des kommerziellen Kerns, allen unter der MIT-Lizenz zur Verfügung, und der Inhaber eines zu diesem Zeitpunkt gültigen Schlüssels behält zusätzlich eine unbefristete Lizenz, dieses Release für seinen Tarif zu nutzen und selbst zu hosten, und darf es ohne den Lizenzdienst betreiben. Maßgeblich für Umfang, Bedingungen und Ausschlüsse ist der Grant selbst. Kostenpflichtige Tarife unterliegen den Opfield Paid Key Terms.