Обзор Pages

Pages публикует статические сайты как проекты с неизменяемыми Deployments и перемещаемыми Tags. Deployment — фиксированный артефакт, созданный ручной загрузкой или сборкой Git. Tag — именованный указатель на один Deployment. Routes указывают на Tags, а не напрямую на Deployments, поэтому продвижение и откат становятся намеренными эксплуатационными действиями, а не изменениями уже опубликованного артефакта.

Для руководителя продукта или разработки результатом является управляемый путь релиза для документации, лендингов, Dashboard и других статических клиентских приложений без отдельного сервера приложений. Владелец проекта определяет, что собирается; владелец релиза решает, какой неизменяемый артефакт выбирает Tag; владелец Ingress управляет Domain и TLS Route. Успех означает, что релиз можно предварительно проверить, продвинуть, подтвердить и откатить без пересборки или изменения предыдущего артефакта.

Pages подходит для статического результата, который доставляется в браузер. Это не универсальная серверная среда выполнения: процессы API, фоновые обработчики, сеансы с состоянием и серверный код приложений должны работать как нагрузки за Opfield Routes.

Этот портал документации и продуктовый лендинг Opfield сами публикуются через Opfield Pages. Они используют ту же модель неизменяемых Deployments, Tags, Routes, TLS и отката, которая описана на этой странице.

Модель ресурсов и владение

Pages Project владеет историей Deployments, Tags, Routes, конфигурацией среды выполнения, отношениями доступа и политикой хранения. Opfield централизованно хранит каждый опубликованный артефакт и материализует его на назначенных нодах nginx. Nginx обслуживает применённую конфигурацию Pages, а Opfield остаётся источником истины для выбора Tag, который должен использовать Route.

Deployments неизменяемы: изменение файлов сайта, результата сборки или входных данных источника создаёт новый Deployment. Tags перемещаемы: перенос Tag меняет уже созданный Deployment, на который он указывает. Системный Tag latest отслеживает подходящий текущий Deployment; используйте пользовательские Tags для именованных сред, каналов релизов или явного барьера продвижения.

Решения до первого релиза

До подключения публичного Domain согласуйте пять пунктов:

1. Владение: кто может создавать Deployments, перемещать Tags рабочей среды, менять конфигурацию среды выполнения и удалять цели отката.
2. Источник релиза: ручная загрузка артефакта или одобренная интеграция Git и Build Worker.
3. Политика продвижения: автоматическое развёртывание для низкорискового сайта или явная проверка до перемещения Tag рабочей среды.
4. Хранение: сколько заведомо исправных Deployments нужно сохранять и как долго.
5. Контракт среды выполнения: какие публичные значения могут меняться независимо от артефакта, а какие требуют новой сборки.

Используйте отдельные Tags, если средам нужно независимое продвижение. Не используйте имена Tags как контроль доступа: границей безопасности остаются права и Routes.

Публикация из Git или вручную

Для релиза из Git поддерживаемая интеграция источника и Build Worker создают новый неизменяемый Deployment. Для ручного релиза передайте готовый артефакт статического сайта и создайте из него новый Deployment. В обоих случаях проверьте артефакт и идентичность Deployment до перемещения публичного Tag.

Ручная загрузка может быть одним HTML-файлом, который становится index.html сайта, или архивом .tar.gz с index.html в корне. Завершение загрузки возвращает ссылку предварительной версии Deployment, а если при загрузке указан Tag, то и ссылку Tag, поэтому агент, собравший отчёт, сразу отдаёт пользователю URL (см. skill publishing-html-pages в разделе AI agent skills). Загрузке можно задать срок жизни (expiresInHours или expiresAt). Когда он истекает, Opfield удаляет Deployment вместе с файлами и предварительными версиями и снимает Tags, которые всё ещё его выбирают; Deployment, который ещё обслуживает Route, сохраняет файлы, но его предварительные версии отключаются. Deploy-токены, ограниченные отдельными Tags, не могут задавать срок жизни.

Любая загрузка — из Console, через API возобновляемой загрузки или через одноразовую ссылку MCP — может быть не больше значения File upload limit в разделе Settings > General > Access and limits: по умолчанию 100 МБ, максимум 500 МБ. Более крупный артефакт отклоняется с 413 PAGES_ARTIFACT_TOO_LARGE, кроме того, действует квота хранилища проекта. Незавершённую загрузку можно сразу отменить из Console, через REST API или MCP; неудачная загрузка из Console убирает за собой, а брошенная загрузка истекает через 30 минут после последней части. Агенты публикуют сайты через одноразовые ссылки для загрузки с готовыми командами curl, а не через base64 в вызовах инструментов.

Создание Deployment не публикует его на пользовательском Domain. Публикация начинается, когда Route указывает на Tag, выбирающий этот Deployment. Так команда может проверить релиз до продвижения, а при инциденте — откатить Tag без изменения предыдущего артефакта.

Routes, предварительные версии и конфигурация среды выполнения

Пользовательские Routes указывают только на Tags. До объявления релиза проверьте Domain, TLS-сертификат, размещение nginx и цель Tag. Необязательные предварительные версии с подстановочными доменами дают каждому Deployment неизменяемое имя хоста, чтобы проверить конкретный артефакт без изменения публичного Tag, а каждому Tag — постоянное имя хоста <хеш проекта>-<tag>.<подстановочный домен>, которое следует за Tag при его перемещении. Хеш проекта случайный, поэтому имена хостов не раскрывают названия проектов. Новые имена Tags должны быть DNS-метками в нижнем регистре длиной не более 50 символов.

Предварительные версии доступны всем, у кого есть ссылка. Чтобы защитить их, выберите список доступа в настройках проекта Preview links: его IP-правила и basic auth применяются ко всем предварительным версиям проекта, а обычный HTTP перенаправляется на HTTPS. Защищённым предварительным версиям нужен nginx-демон 2.11: нода, демон которой не умеет применять списки доступа к предварительным версиям, не публикует их вовсе, а не отдаёт открытыми. Отключение проекта отзывает его предварительные версии. Rotate links выдаёт проекту новый хеш и новые имена хостов Deployments, что отзывает все ссылки на предварительные версии, которыми уже поделились.

Конфигурация среды выполнения — публичные клиентские данные, отделённые от идентичности неизменяемого артефакта. Сайт получает её как window.runtime.config с объектом Default и полными переопределениями объекта для Tags. Неизменяемые предварительные версии развёртываний используют Default; Route с Tag и адрес предварительного просмотра Tag используют переопределение Tag, если оно есть, или возвращаются к Default. Не помещайте в конфигурацию секреты, учётные данные или приватную топологию.

Конфигурация подходит для публичных адресов API, представления функций, идентификаторов аналитики или меток среды, которые действительно должны быть видны браузеру. Переопределение Tag заменяет объект целиком, а не объединяет отдельные ключи, поэтому проверяйте все обязательные поля. Сохраняйте совместимость со всеми Deployments, на которые Tag может вернуться при откате.

Продвиньте, откатите и проверьте

1. Создайте новый неизменяемый Deployment через Git или ручную публикацию.
2. Проверьте результат сборки или загрузки и протестируйте артефакт через подходящую предварительную версию или контролируемый Route.
3. Переместите нужный Tag на проверенный Deployment.
4. Проверьте путь DNS и TLS Route, ожидаемый ответ, статические ресурсы и видимую браузеру конфигурацию среды выполнения.
5. После продвижения наблюдайте за Route, состоянием приложения nginx и операциями проекта.

Для отката переместите Tag Route на предыдущий заведомо исправный Deployment. Старый артефакт остаётся неизменным, а откат записывается как изменение публикации Tag. Сохраняйте обратную совместимость конфигурации среды выполнения, пока Tag может перемещаться между релизами; изменение конфигурации не создаёт новый Deployment.

Релиз успешен, только если пользовательский Domain возвращает нужный документ, все ресурсы загружаются без ошибок, TLS действителен, клиентская навигация работает после прямого обновления страницы, а браузер получает нужную конфигурацию среды выполнения. Неизменяемая предварительная версия подтверждает артефакт, но не проверяет Domain рабочей среды, сертификат, Tag или значения конкретной среды.

Последствия жизненного цикла

Удаление Deployment исключает этот неизменяемый релиз из будущего выбора и может убрать цель отката. Удаляйте его только после проверки требований хранения и ссылок Tags. Удаление Tag или Route меняет доступность, а не содержимое выбранного Deployment. Отключение Pages убирает функцию из обычной навигации, сохраняя данные проекта, и позже Pages можно снова включить. Deployments, файлы которых уже удалены по правилам хранения, скрыты из списка Deployments.

Для операторов: размещение и восстановление

Opfield хранит артефакт Pages централизованно и материализует копии на назначенных нодах nginx. Если Route не работает, а Deployment готов, проверьте размещение Domain, ноду Ingress, связь сертификата, цель Tag и Task Pages до пересборки. Повторная сборка того же источника не заменяет восстановление пути обслуживания.

Если продвижение вызвало инцидент, сначала переместите Tag рабочей среды на предыдущий проверенный Deployment. Меняйте конфигурацию среды выполнения только тогда, когда она является частью сбоя и совместима с целью отката. Сохраняйте неисправный Deployment, запись сборки и журналы до выяснения причины: неизменяемость делает их полезными доказательствами.

Симптом	Первая проверка	Безопасное следующее действие
Deployment готов, но сайт не открывается	Domain, TLS, Route, Tag и нода Ingress	Пройдите диагностику Ingress, не пересобирая сайт
Не открывается только новая версия	Положение Tag, предварительную версию и конфигурацию сайта	Верните Tag на проверенный Deployment и сохраните Task и журналы
Сборка или загрузка не завершилась	Task, журналы сборки и Build Worker	Исправьте конкретную ошибку и повторите сценарий; не удаляйте предыдущую версию

Следующий шаг

• Соберите и опубликуйте Deployment Pages из Git