Vue d'ensemble de Pages

Pages publie des sites statiques sous forme de projets dotés de Deployments immuables et de tags modifiables. Un Deployment est un artefact fixe produit par un téléversement manuel ou un build Git. Un tag est un pointeur nommé et déplaçable vers un Deployment. Les Routes ciblent des tags, jamais des Deployments bruts, ce qui fait de la promotion et du retour arrière des actions d’exploitation délibérées plutôt que des modifications d’un artefact déjà publié.

Pages sert de la documentation, des pages vitrines, des tableaux de bord et d’autres frontends statiques sans serveur d’application. Chaque version peut être prévisualisée, promue, vérifiée et annulée sans reconstruire ni modifier l’artefact précédent.

Pages sert du contenu statique livré au navigateur. Les processus d’API, les workers d’arrière-plan, les sessions avec état et le code applicatif côté serveur s’exécutent comme des charges de travail derrière des Routes Opfield.

Ce portail de documentation et le site vitrine du produit Opfield sont eux-mêmes publiés via Opfield Pages. Ils utilisent le même modèle de Deployments immuables, de tags, de Routes, de TLS et de retour arrière que celui décrit ici.

Modèle de ressources et propriété

Un projet Pages détient son historique de déploiements, ses tags, ses Routes, sa configuration d’exécution, ses relations d’accès et son comportement de conservation. Opfield stocke chaque artefact publié de façon centralisée et le matérialise sur les nœuds nginx attribués. nginx sert la configuration Pages appliquée, tandis qu’Opfield reste la source de vérité sur le tag qu’une Route doit utiliser.

Les Deployments sont immuables : modifier les fichiers du site, la sortie du build ou l’entrée source crée un nouveau Deployment. Les tags sont modifiables : déplacer un tag change le Deployment déjà créé qu’il sélectionne. Le tag latest, géré par le système, suit le déploiement actuel approprié ; utilisez des tags personnalisés pour les environnements nommés, les canaux de publication ou une étape de promotion explicite.

Décisions avant la première publication

Mettez-vous d’accord sur cinq points avant de connecter un domaine public :

1. Propriété : qui peut créer des Deployments, déplacer les tags de production, modifier la configuration d’exécution et supprimer des candidats au retour arrière.
2. Source des versions : téléversement manuel d’artefacts ou intégration Git et Build Worker approuvés.
3. Politique de promotion : déploiement automatique pour les sites à faible risque, ou revue explicite avant le déplacement du tag de production.
4. Conservation : combien de Deployments réputés sains doivent rester disponibles, et pendant combien de temps.
5. Contrat d’exécution : quelles valeurs publiques peuvent changer indépendamment de l’artefact et quels changements exigent un nouveau build.

Utilisez des tags distincts lorsque des environnements ont besoin d’une promotion indépendante. N’utilisez pas les noms de tags comme contrôle d’accès : les permissions et les Routes restent la frontière de sécurité.

Publier depuis Git ou manuellement

Pour une version adossée à Git, une intégration de sources prise en charge et un Build Worker produisent un nouveau Deployment immuable. Pour une version manuelle, fournissez l’artefact de site statique prêt et créez-en un nouveau Deployment. Dans les deux cas, examinez l’artefact obtenu et l’identité du déploiement avant de déplacer un tag public.

Un téléversement manuel peut être un unique fichier HTML, qui devient l’index.html du site, ou une archive .tar.gz avec index.html à sa racine. La finalisation du téléversement renvoie le lien d’aperçu du Deployment et, lorsque le téléversement nommait un tag, le lien du tag ; un agent qui a généré un rapport peut donc remettre immédiatement une URL à l’utilisateur (voir le skill publishing-html-pages dans Skills pour agents d’IA). Un téléversement peut définir une expiration (expiresInHours ou expiresAt). À l’échéance, Opfield supprime le Deployment avec ses fichiers et ses aperçus et efface les tags qui le sélectionnent encore ; un Deployment encore servi par une Route conserve ses fichiers, mais ses aperçus s’arrêtent. Les jetons de déploiement restreints à certains tags ne peuvent pas définir d’expiration.

Chaque téléversement — depuis la Console, via l’API de déploiement avec reprise ou via un lien MCP à usage unique — peut atteindre la File upload limit définie dans Settings > General > Access and limits : 100 Mo par défaut et 500 Mo au maximum. Un artefact plus volumineux est refusé avec 413 PAGES_ARTIFACT_TOO_LARGE, et le quota de stockage du projet s’applique aussi. Un téléversement inachevé peut être annulé immédiatement depuis la Console, l’API REST ou MCP ; un téléversement en échec depuis la Console fait son propre nettoyage, et un téléversement abandonné expire 30 minutes après son dernier fragment. Les agents publient via des liens de téléversement à usage unique accompagnés de commandes curl prêtes à l’emploi, au lieu de base64 dans les appels d’outils.

Créer un Deployment ne le publie pas sur un domaine personnalisé. La publication commence lorsqu’une Route cible un tag qui pointe vers ce Deployment. Cela permet à une équipe de vérifier une version avant sa promotion et permet, lors d’un incident, de revenir en arrière en déplaçant un tag sans réécrire l’artefact antérieur.

Routes, aperçus et configuration d’exécution

Les Routes personnalisées ne ciblent que des tags. Vérifiez le domaine, le certificat TLS, le placement nginx et la cible du tag avant d’annoncer une version. Les aperçus wildcard facultatifs donnent à chaque Deployment un nom d’hôte immuable, utile pour examiner un artefact particulier sans modifier un tag public, et à chaque tag un nom d’hôte stable <project hash>-<tag>.<wildcard domain> qui suit le tag lorsqu’il se déplace. L’empreinte du projet est aléatoire ; les noms d’hôte d’aperçu ne révèlent donc jamais les noms des projets. Les nouveaux noms de tags doivent être des libellés DNS en minuscules d’au plus 50 caractères.

Les aperçus sont publics pour quiconque dispose du lien. Pour les protéger, choisissez une liste d’accès dans les paramètres Preview links du projet : ses règles IP et son authentification basique s’appliquent alors à chaque aperçu du projet, et le HTTP en clair redirige vers HTTPS. Les aperçus protégés nécessitent le démon nginx 2.11 : un nœud dont le démon ne peut pas appliquer de listes d’accès aux aperçus retient les aperçus du projet au lieu de les servir sans protection. La désactivation d’un projet révoque ses aperçus. Rotate links donne au projet une nouvelle empreinte et de nouveaux noms d’hôte de Deployments, ce qui révoque chaque lien d’aperçu partagé jusque-là.

La configuration d’exécution est une donnée publique côté client, distincte de l’identité de l’artefact immuable. Elle est exposée au site sous la forme window.runtime.config, avec un objet Default et des remplacements d’objet complet par tag. Les aperçus immuables des Deployments utilisent Default ; une Route de tag et le nom d’hôte d’aperçu du tag utilisent le remplacement du tag lorsqu’il existe, ou se rabattent sur Default. Ne placez pas de secrets, d’identifiants ou de topologie privée dans la configuration d’exécution.

La configuration d’exécution est utile pour les origines d’API publiques, la présentation des fonctionnalités, les identifiants d’analytics ou les libellés d’environnement qui ont légitimement leur place dans le navigateur. Un remplacement par tag remplace l’objet entier au lieu de fusionner les clés individuelles ; examinez donc chaque champ requis lors de la création d’un remplacement. Gardez le contrat rétrocompatible avec chaque Deployment que le tag peut sélectionner lors d’un retour arrière.

Promouvoir, revenir en arrière et vérifier

1. Créez un nouveau Deployment immuable via Git ou une publication manuelle.
2. Examinez le résultat de son build ou de son téléversement et testez l’artefact via un aperçu approprié ou une route contrôlée.
3. Déplacez le tag prévu vers le Deployment vérifié.
4. Vérifiez le chemin DNS et TLS de la Route, la réponse attendue, les ressources statiques et la configuration d’exécution visible dans le navigateur.
5. Surveillez la Route, l’état de l’application nginx et les opérations du projet après la promotion.

Pour revenir en arrière, déplacez le tag de la Route vers un Deployment précédent réputé sain. L’artefact plus ancien reste inchangé, et le retour arrière est enregistré comme un changement de publication de tag. Gardez la configuration d’exécution rétrocompatible tant qu’un tag peut passer d’une version à l’autre ; modifier la configuration d’exécution ne crée pas de nouveau Deployment.

La publication n’est réussie que lorsque le domaine personnalisé renvoie le document prévu, que les ressources référencées se chargent sans erreur, que TLS est valide, que la navigation côté client fonctionne après une actualisation directe et que le navigateur reçoit la configuration d’exécution prévue. Un aperçu immuable prouve l’artefact ; il ne prouve pas le domaine de production, le certificat, le tag ni les valeurs d’exécution propres à l’environnement.

Conséquences sur le cycle de vie

Supprimer un Deployment retire cette version immuable des sélections futures et peut supprimer une cible de retour arrière. Ne le supprimez qu’après avoir examiné les exigences de conservation et les références des tags. Supprimer un tag ou une Route modifie la joignabilité, et non le contenu du Deployment sélectionné. Désactiver Pages retire la fonctionnalité de la navigation normale tout en préservant les données des projets, et Pages peut être réactivé plus tard. Les Deployments dont la conservation a déjà supprimé les fichiers sont masqués de la liste des Deployments.

Détails pour l’opérateur : placement et reprise

Opfield stocke l’artefact Pages de façon centralisée et en matérialise des réplicas sur les nœuds nginx attribués. Si une Route échoue alors que le Deployment reste prêt, examinez le placement du domaine, le nœud Ingress, la relation avec le certificat, la cible du tag et l’opération Pages avant de reconstruire. Reconstruire la même source ne remplace pas le rétablissement du chemin de service.

Si une promotion provoque un incident, déplacez d’abord le tag de production vers le Deployment vérifié précédent. Ne modifiez la configuration d’exécution que si elle fait partie de la panne et reste compatible avec la cible du retour arrière. Conservez le Deployment en échec, l’enregistrement du build et les journaux jusqu’à ce que l’incident soit compris ; leur immuabilité en fait des éléments de preuve utiles.

Étape suivante

• Construire et publier un déploiement Pages depuis Git