firebase-app-hosting-basics

Официальный skill Firebase App Hosting предназначен для развёртывания и управления full-stack web-приложениями, включая Next.js и Angular, когда приложению нужен Server-Side Rendering или Incremental Static Regeneration. Перед началом источник требует учесть тарифный барьер: Firebase App Hosting доступен на Blaze pricing plan. Это обязательное условие инфраструктуры, поэтому карточка не должна создавать впечатление, что описанные команды работают на любом бесплатном плане без изменения биллинга. Skill помогает выбрать между обычным Firebase Hosting и App Hosting. Classic Hosting подходит для статического HTML/CSS/JS, простой SPA без SSR и случаев, когда нужен полный контроль над build и deploy через CLI. App Hosting выбирают для поддерживаемого full-stack framework, например Next.js или Angular, когда нужен SSR либо ISR, а также когда подходит автоматизированный workflow git push to deploy. Такое сравнение является частью назначения skill: сначала определяется тип приложения и способ рендеринга, а уже потом выбирается backend Firebase. Рекомендуемый путь развёртывания начинается с настройки firebase.json. В нём создаётся блок apphosting с backendId, rootDir и ignore-списком. В опубликованном примере из ignore исключаются node_modules, .git, firebase-debug.log, варианты firebase-debug.*.log и functions. Затем нужно создать или изменить apphosting.yaml; источник направляет к отдельному разделу Configuration за деталями этого файла. Конкретные значения backendId и rootDir зависят от проекта, поэтому карточка не подставляет их за пользователя. Для секретов источник предлагает команды npx -y firebase-tools@latest apphosting:secrets: сначала секреты задаются, затем приложению предоставляется доступ. Это отдельная часть workflow, а не причина хранить чувствительные значения в firebase.json или исходниках. Когда конфигурация и доступ к секретам готовы, публикация выполняется командой npx -y firebase-tools@latest deploy. Наличие команды в инструкции описывает способ запуска deploy, но само по себе не доказывает, что конкретный backend собран, доступен и корректно обслуживает SSR; результат нужно проверять в инфраструктуре проекта. Для более продвинутого сценария App Hosting можно связать backend с GitHub-репозиторием и включить автоматизированные git push deployments. Источник называет такой путь альтернативой ручному deploy и отдельно отмечает, что он не обязателен для использования App Hosting. Для локальной проверки предусмотрен Firebase Local Emulator Suite; это маршрут эмуляции, а не обещание, что каждый production-провайдер или секрет будет полностью воспроизведён локально. Практическая последовательность применения такая: определить, нужен ли статический Hosting или full-stack App Hosting, проверить Blaze plan, добавить apphosting-блок в firebase.json, подготовить apphosting.yaml, безопасно настроить secrets, выбрать ручной deploy или GitHub CI/CD и использовать Emulator Suite для локальной проверки. Ограничения skill явно включают классический static hosting, Auth, Firestore, Crashlytics и Xcode: для этих задач его применять не следует. Карточка описывает конфигурацию и workflow App Hosting, но не заменяет проверку текущей документации Firebase, состояния проекта и результата конкретного развёртывания.