Pages-Übersicht

Pages veröffentlicht statische Websites als Projekte mit unveränderlichen Deployments und veränderlichen Tags. Ein Deployment ist ein festes Artefakt, das durch einen manuellen Upload oder einen Git-Build entsteht. Ein Tag ist ein verschiebbarer benannter Zeiger auf ein Deployment. Routen zielen auf Tags, nie auf rohe Deployments, was Übernahme und Rollback zu bewussten betrieblichen Aktionen macht statt zu Änderungen an einem bereits veröffentlichten Artefakt.

Pages liefert Dokumentation, Landingpages, Dashboards und andere statische Frontends ohne Anwendungsserver aus. Jedes Release kann in der Vorschau angesehen, übernommen, geprüft und zurückgesetzt werden, ohne das vorherige Artefakt neu zu bauen oder zu bearbeiten.

Pages liefert statische Ausgaben aus, die an den Browser ausgeliefert werden. API-Prozesse, Hintergrund-Worker, zustandsbehaftete Sitzungen und serverseitiger Anwendungscode laufen als Workloads hinter Opfield-Routen.

Dieses Dokumentationsportal und die Opfield-Produkt-Landingpage werden selbst über Opfield Pages veröffentlicht. Sie verwenden dasselbe hier beschriebene Modell aus unveränderlichem Deployment, Tag, Route, TLS und Rollback.

Ressourcenmodell und Zuständigkeit

Ein Pages-Projekt besitzt seinen Deployment-Verlauf, Tags, Routen, Laufzeitkonfiguration, Zugriffsbeziehungen und das Aufbewahrungsverhalten. Opfield speichert jedes veröffentlichte Artefakt zentral und stellt es auf den zugewiesenen nginx-Nodes bereit. nginx liefert die angewendete Pages-Konfiguration aus, während Opfield die maßgebliche Quelle dafür bleibt, welchen Tag eine Route verwenden soll.

Deployments sind unveränderlich: Eine Änderung von Website-Dateien, Build-Ausgaben oder Quelleingaben erstellt ein neues Deployment. Tags sind veränderlich: Das Verschieben eines Tags ändert, welches bereits erstellte Deployment er auswählt. Der systemverwaltete Tag latest folgt dem passenden aktuellen Deployment; verwenden Sie eigene Tags für benannte Umgebungen, Release-Kanäle oder ein ausdrückliches Übernahme-Gate.

Entscheidungen vor dem ersten Release

Einigen Sie sich auf fünf Punkte, bevor Sie eine öffentliche Domain verbinden:

1. Zuständigkeit: wer Deployments erstellen, Produktions-Tags verschieben, die Laufzeitkonfiguration bearbeiten und Rollback-Kandidaten löschen darf.
2. Release-Quelle: manueller Upload eines Artefakts oder eine freigegebene Git-Integration mit Build Worker.
3. Übernahmerichtlinie: automatisches Deployment für Websites mit geringem Risiko oder eine ausdrückliche Prüfung, bevor der Produktions-Tag verschoben wird.
4. Aufbewahrung: wie viele bekannt fehlerfreie Deployments wie lange verfügbar bleiben müssen.
5. Laufzeitvertrag: welche öffentlichen Werte sich unabhängig vom Artefakt ändern dürfen und welche Änderungen einen neuen Build erfordern.

Verwenden Sie getrennte Tags, wenn Umgebungen eine unabhängige Übernahme benötigen. Verwenden Sie Tag-Namen nicht als Zugriffskontrolle: Berechtigungen und Routen bleiben die Sicherheitsgrenze.

Aus Git oder manuell veröffentlichen

Bei einem Git-basierten Release erzeugen eine unterstützte Quellintegration und ein Build Worker ein neues unveränderliches Deployment. Bei einem manuellen Release stellen Sie das fertige Artefakt der statischen Website bereit und erstellen daraus ein neues Deployment. Prüfen Sie auf beiden Wegen das resultierende Artefakt und die Identität des Deployments, bevor Sie einen öffentlichen Tag verschieben.

Ein manueller Upload kann eine einzelne HTML-Datei sein, die zur index.html der Website wird, oder ein .tar.gz-Archiv mit index.html im Wurzelverzeichnis. Der Abschluss des Uploads liefert den Vorschau-Link des Deployments und, wenn der Upload einen Tag genannt hat, den Link des Tags, sodass ein Agent, der einen Bericht erzeugt hat, dem Benutzer sofort eine URL geben kann (siehe den Skill publishing-html-pages unter KI-Agenten-Skills). Ein Upload kann einen Ablauf festlegen (expiresInHours oder expiresAt). Ist er erreicht, löscht Opfield das Deployment mit seinen Dateien und Vorschauen und hebt die Tags auf, die es noch auswählen; ein Deployment, das eine Route noch ausliefert, behält seine Dateien, aber seine Vorschauen enden. Deploy-Tokens, die auf bestimmte Tags beschränkt sind, können keinen Ablauf festlegen.

Jeder Upload – aus der Konsole, über die fortsetzbare Deploy-API oder über einen einmaligen MCP-Link – darf so groß sein wie das File upload limit unter Settings > General > Access and limits: standardmäßig 100 MB und höchstens 500 MB. Ein größeres Artefakt wird mit 413 PAGES_ARTIFACT_TOO_LARGE abgelehnt, und das Speicherkontingent des Projekts gilt zusätzlich. Ein unvollständiger Upload kann sofort aus der Konsole, der REST API oder MCP abgebrochen werden; ein fehlgeschlagener Konsolen-Upload räumt selbst auf, und ein aufgegebener Upload verfällt 30 Minuten nach seinem letzten Block. Agenten veröffentlichen über einmalige Upload-Links mit fertigen curl-Befehlen statt über Base64 in Werkzeugaufrufen.

Das Erstellen eines Deployments veröffentlicht es nicht unter einer eigenen Domain. Die Veröffentlichung beginnt, wenn eine Route auf einen Tag zielt, der auf dieses Deployment zeigt. So kann ein Team ein Release vor der Übernahme prüfen, und ein Rollback bei einem Vorfall kann einen Tag verschieben, ohne das vorherige Artefakt neu zu schreiben.

Routen, Vorschauen und Laufzeitkonfiguration

Eigene Routen zielen nur auf Tags. Prüfen Sie Domain, TLS-Zertifikat, nginx-Platzierung und Tag-Ziel, bevor Sie ein Release ankündigen. Optionale Wildcard-Vorschauen geben jedem Deployment einen unveränderlichen Hostnamen, nützlich, um ein bestimmtes Artefakt zu prüfen, ohne einen öffentlichen Tag zu ändern, und jedem Tag einen stabilen Hostnamen <project hash>-<tag>.<wildcard domain>, der dem Tag folgt, wenn er verschoben wird. Der Projekt-Hash ist zufällig, sodass Vorschau-Hostnamen nie Projektnamen preisgeben. Neue Tag-Namen müssen DNS-Labels in Kleinbuchstaben mit höchstens 50 Zeichen sein.

Vorschauen sind für jeden öffentlich, der den Link hat. Um sie zu schützen, wählen Sie in den Einstellungen Preview links des Projekts eine Access List: Ihre IP-Regeln und Basic Auth gelten dann für jede Vorschau des Projekts, und einfaches HTTP leitet auf HTTPS um. Geschützte Vorschauen benötigen den nginx-Daemon von 2.11: Ein Node, dessen Daemon keine Access Lists auf Vorschauen anwenden kann, hält die Vorschauen des Projekts zurück, statt sie offen auszuliefern. Das Deaktivieren eines Projekts widerruft seine Vorschauen. Rotate links gibt dem Projekt einen neuen Hash und neue Deployment-Hostnamen, was jeden bisher geteilten Vorschau-Link widerruft.

Die Laufzeitkonfiguration ist öffentliche clientseitige Datenquelle und von der Identität des unveränderlichen Artefakts getrennt. Sie wird der Website als window.runtime.config bereitgestellt, mit einem Default-Objekt und Tag-Überschreibungen des gesamten Objekts. Unveränderliche Deployment-Vorschauen verwenden Default; eine Tag-Route und der Vorschau-Hostname des Tags verwenden die Überschreibung des Tags, sofern vorhanden, oder greifen auf Default zurück. Legen Sie keine Secrets, Zugangsdaten oder private Topologie in der Laufzeitkonfiguration ab.

Die Laufzeitkonfiguration ist nützlich für öffentliche API-Origins, die Darstellung von Funktionen, Analytics-Kennungen oder Umgebungsbezeichnungen, die berechtigterweise in den Browser gehören. Eine Tag-Überschreibung ersetzt das gesamte Objekt, statt einzelne Schlüssel zusammenzuführen; prüfen Sie daher beim Erstellen einer Überschreibung jedes benötigte Feld. Halten Sie den Vertrag abwärtskompatibel mit jedem Deployment, das der Tag bei einem Rollback auswählen kann.

Übernehmen, zurücksetzen und prüfen

1. Erstellen Sie über Git oder manuelle Veröffentlichung ein neues unveränderliches Deployment.
2. Prüfen Sie sein Build- oder Upload-Ergebnis und testen Sie das Artefakt über eine geeignete Vorschau oder eine kontrollierte Route.
3. Verschieben Sie den vorgesehenen Tag auf das geprüfte Deployment.
4. Prüfen Sie den DNS- und TLS-Pfad der Route, die erwartete Antwort, statische Assets und die im Browser sichtbare Laufzeitkonfiguration.
5. Überwachen Sie nach der Übernahme die Route, den Anwendungszustand in nginx und die Projektoperationen.

Verschieben Sie für ein Rollback den Tag der Route auf ein vorheriges bekannt fehlerfreies Deployment. Das ältere Artefakt bleibt unverändert, und das Rollback wird als Änderung der Tag-Veröffentlichung erfasst. Halten Sie die Laufzeitkonfiguration abwärtskompatibel, solange ein Tag zwischen Releases wechseln kann; eine Änderung der Laufzeitkonfiguration erstellt kein neues Deployment.

Das Release ist erst erfolgreich, wenn die eigene Domain das vorgesehene Dokument liefert, referenzierte Assets ohne Fehler laden, TLS gültig ist, die clientseitige Navigation nach einem direkten Neuladen funktioniert und der Browser die vorgesehene Laufzeitkonfiguration erhält. Eine unveränderliche Vorschau weist das Artefakt nach; sie weist weder die Produktions-Domain noch das Zertifikat, den Tag oder umgebungsspezifische Laufzeitwerte nach.

Folgen im Lebenszyklus

Das Löschen eines Deployments entfernt dieses unveränderliche Release aus der künftigen Auswahl und kann ein Rollback-Ziel beseitigen. Entfernen Sie es erst, nachdem Aufbewahrungsanforderungen und Tag-Referenzen geprüft wurden. Das Löschen eines Tags oder einer Route ändert die Erreichbarkeit, nicht den Inhalt des ausgewählten Deployments. Das Deaktivieren von Pages entfernt die Funktion aus der normalen Navigation und bewahrt die Projektdaten, und Pages kann später wieder eingeschaltet werden. Deployments, deren Dateien die Aufbewahrung bereits entfernt hat, sind in der Deployment-Liste ausgeblendet.

Details für Betreiber: Platzierung und Wiederherstellung

Opfield speichert das Pages-Artefakt zentral und stellt Replikate auf zugewiesenen nginx-Nodes bereit. Schlägt eine Route fehl, während das Deployment bereit bleibt, prüfen Sie die Platzierung der Domain, den Ingress Node, die Zertifikatsbeziehung, das Tag-Ziel und die Pages-Operation, bevor Sie neu bauen. Dieselbe Quelle neu zu bauen, ersetzt nicht die Wiederherstellung des Auslieferungspfads.

Verursacht eine Übernahme einen Vorfall, verschieben Sie zuerst den Produktions-Tag auf das vorherige geprüfte Deployment. Ändern Sie die Laufzeitkonfiguration nur, wenn sie Teil des Fehlers ist und mit dem Rollback-Ziel kompatibel bleibt. Bewahren Sie das fehlerhafte Deployment, den Build-Eintrag und die Logs auf, bis der Vorfall verstanden ist; die Unveränderlichkeit macht sie zu nützlichen Belegen.

Nächster Schritt

• Ein Pages-Deployment aus Git bauen und veröffentlichen