Опубликуйте статический сайт с Pages

Opfield Pages публикует статический сайт как неизменяемый артефакт с явным указателем продвижения. До начала подготовьте готовый статический результат или репозиторий Git, ноду Ingress и Domain. Если Pages для вас новы, сначала прочитайте обзор Pages. Deployment — один фиксированный набор файлов, Tag — перемещаемое имя, например production, а Route направляет публичный Domain на этот Tag. Такое разделение позволяет проверить релиз и откатиться перемещением Tag, не меняя файлы на месте.

Pages предназначен для статического результата: HTML, JavaScript, CSS, изображений, шрифтов и других файлов, которые обслуживает nginx. Он не предоставляет серверную среду выполнения приложения. Фреймворк можно использовать во время сборки, но результатом должен быть статический артефакт в настроенном каталоге.

Лендинг Opfield и портал документации Opfield — примеры сайтов, которые могут работать на Opfield Pages. Использование платформы для собственных публичных ресурсов служит полезным эксплуатационным доказательством, но эти проекты должны проходить те же проверки доступа, релиза и отката, что и сайты клиентов.

Определите контракт релиза

До создания проекта решите:

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

Проект владеет историей Deployments, Tags, конфигурацией среды выполнения, Routes и поведением хранения. Если используется репозиторий, он владеет исходным кодом, но не управляет публичным Route напрямую.

Подготовьте статический артефакт

Соберите сайт в чистой среде и убедитесь, что выходной каталог содержит входные документы и все используемые ресурсы. Проверьте клиентскую маршрутизацию и базовые пути через статический, а не через сервер разработки. Сервер разработки может скрывать отсутствующие файлы, рендеринг только на сервере или неверные URL ресурсов.

Не включайте карты исходного кода, тестовые данные, файлы среды, приватные метаданные репозитория, учётные данные, внутреннюю топологию или кэши сборки, если они не должны быть публичными. Любой файл внутри артефакта Pages следует считать доступным для скачивания, даже если UI не содержит ссылки на него.

Путь ручной загрузки

Включите Pages в настройках функций и убедитесь, что текущий тариф разрешает управление Pages.
Создайте Pages Project и выберите подходящую ноду Ingress.
До загрузки артефакта рабочей среды настройте квоты проекта, хранение и доступ.
Загрузите подготовленный артефакт через Console, возобновляемый API Deployment или аутентифицированную ссылку загрузки удалённого MCP. Размер артефакта ограничен значением File upload limit: по умолчанию 100 МБ, максимум 500 МБ; см. Обзор Pages.
Завершите загрузку. Opfield проверит данные и создаст новый неизменяемый Deployment вместо изменения прежнего.
Откройте неизменяемую предварительную версию и проверьте точный артефакт.
Только после одобрения переместите системный Tag latest или пользовательский релизный Tag на этот Deployment.
Создайте или обновите Pages Route для публичного Domain и выбранного Tag.

Прерванная загрузка не является релизом. Возобновите или повторите её через поддерживаемый сценарий и завершите один раз; не копируйте частичные файлы вручную на ноду Ingress.

Путь сборки Git

На поддерживаемых тарифах подключите к Pages Project разрешённый репозиторий GitLab, GitHub или generic Git. Выберите ветку и корень приложения, разрешите Opfield при необходимости обнаружить package.json и настройте менеджер пакетов, версию Node.js, скрипт сборки и каталог артефакта.

Сборка выполняется на изолированном Build Worker. Добавляйте Build Secrets с областью источника только для доступа во время сборки; они не должны попасть в статический результат. До публикации проверьте точный коммит, журналы, результат политики уязвимостей, если она включена, Build Worker и созданный артефакт.

Разделяйте автоматическую сборку и автоматическую публикацию. Первая может создавать предварительную версию для каждого одобренного изменения, не затрагивая пользователей. Вторая перемещает Tag и меняет содержимое Route; включайте её только тогда, когда защита ветки и приёмочные проверки соответствуют этому риску.

Pages Project с готовыми неизменяемыми Deployments и их URL предварительного просмотра

Конфигурация среды выполнения

Pages может отдавать видимую клиенту конфигурацию из /_gateway/pages/config.js как window.runtime.config. Значение публично, ограничено 64 KiB и обслуживается с no-store. Объект Default применяется по умолчанию, а полные переопределения для Tags могут заменить его у Route с Tag. Неизменяемые предварительные версии используют Default.

Используйте эту конфигурацию для несекретных значений, которые действительно различаются между средами: публичных адресов API, представления функций или идентификаторов аналитики. Не помещайте туда пароли, ключи API, приватные адреса, материал подписи, данные только для клиентов или сетевую топологию.

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

Опубликуйте Domain

Создайте или выберите Domain и сертификат, затем создайте Pages Route, указывающий на выбранные Project и Tag. Routes указывают на Tags, а не напрямую на Deployments. Поэтому продвижение и откат остаются явными записанными операциями.

Проверьте DNS, TLS, входной документ, вложенные ресурсы, клиентскую навигацию, кэширование, window.runtime.config и страницы ошибок. Выполняйте проверку в чистом сеансе браузера и из внешней сети. Неизменяемая предварительная версия доказывает качество артефакта; публичный Route дополнительно проверяет DNS, TLS, выбор Tag и материализацию Ingress.

Критерии успеха

Pages Deployment имеет статус Ready и неизменяемую предварительную версию.
Нужный Tag указывает на проверенный Deployment.
Публичный Route обслуживает этот Tag через доверенный TLS.
Статические ресурсы и клиентские Routes работают при прямом открытии URL.
Артефакт и конфигурация среды выполнения не содержат секреты или внутренние файлы.
При доставке из Git видны коммит Deployment и запись сборки.
Предыдущий заведомо исправный Deployment остаётся доступным для отката.

Откат и очистка

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

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

Симптом	Сначала проверьте	Подробная страница
Сборка не создала Deployment	Task, Build Worker и журналы сборки	Git-развёртывания Pages
Предварительная версия работает, Domain — нет	Domain, TLS, Route и целевой Tag	Диагностика Ingress
После публикации появилась ошибка	Положение Tag и последнюю Task	Верните Tag на проверенный Deployment и прочитайте обзор Pages