Сборка и деплой: от .output до прода

nuxt build собирает приложение в папку .output, а Nitro адаптирует её под нужную платформу — от Node-сервера до Vercel и Netlify почти без конфигурации.

Суть: команда nuxt build создаёт серверную сборку в .output с Nitro-сервером. nuxt generate делает статику. Nitro-пресеты подгоняют вывод под платформу деплоя (Node, Vercel, Netlify, Cloudflare) часто без ручной конфигурации.

Финал пути — выкатить приложение в продакшен. Хорошая новость: благодаря Nitro деплой Nuxt близок к «zero-config». Вы выбираете цель, а движок сам готовит подходящую сборку.

Две основные команды. nuxt build собирает приложение для серверного режима: результат — папка .output с Nitro-сервером, который умеет SSR. Запускается она как обычное Node-приложение:

# собрать серверную сборку
npx nuxt build

# запустить на сервере
node .output/server/index.mjs

Если же сайт чисто статический, nuxt generate заранее отрендерит все страницы в HTML, и результат (в .output/public) можно положить на любой статический хостинг или CDN — без живого сервера:

# статическая генерация (SSG)
npx nuxt generate

Самое мощное — пресеты Nitro. Один и тот же код можно собрать под Node-сервер, Vercel, Netlify, Cloudflare Workers и десятки других платформ: Nitro меняет формат вывода под целевую среду. Часто платформа определяется автоматически, иногда задаётся через NITRO_PRESET.

   Пути деплоя Nuxt

   nuxt build  -> .output (Nitro-сервер) -> Node / Vercel / Netlify ...
   nuxt generate -> .output/public (HTML) -> CDN / статик-хостинг

                 Nitro-пресет подгоняет вывод под платформу

Отдельного внимания заслуживает дисциплина работы с секретами в команде. В репозиторий коммитят только .env.example — список нужных переменных с пустыми или фиктивными значениями, чтобы новый разработчик знал, что заполнить. Реальные значения живут в локальном .env (он в .gitignore) и в защищённом хранилище секретов на проде. Утёкший в историю git ключ придётся не просто удалить, а отозвать и перевыпустить, потому что историю видят все, у кого есть клон. Поэтому правило простое и жёсткое: секрет в коде или в коммите — это уже инцидент, а не неудобство.

Как работает под капотом

При сборке Nitro компилирует серверные обработчики и SSR-логику в самодостаточный бандл в .output/server, а клиентские ассеты — в .output/public. Пресет определяет «обёртку» сервера: для Node это HTTP-сервер, для Vercel/Netlify — функции платформы, для Cloudflare — воркер. Поэтому переезд между платформами обычно не требует менять код приложения — меняется лишь цель сборки. Перед продом стоит проверить сборку локально через nuxt preview.

Смоделируем выбор формата вывода по пресету — суть адаптации Nitro:

// Один билд -> разный вывод под платформу (Nitro-пресет).
function buildOutput(preset) {
  const base = { client: ".output/public", server: ".output/server" };
  switch (preset) {
    case "node":      return { ...base, entry: "node .output/server/index.mjs" };
    case "vercel":    return { ...base, entry: ".vercel/output/functions" };
    case "netlify":   return { ...base, entry: "netlify/functions/server" };
    case "static":    return { client: ".output/public", entry: "CDN: статика без сервера" };
    default:          return { ...base, entry: "node .output/server/index.mjs" };
  }
}

for (const p of ["node", "vercel", "netlify", "static"]) {
  console.log(p.padEnd(9), "->", buildOutput(p).entry);
}
console.log("Код приложения один — меняется только формат вывода.");

Попробуй сам ▶ — один и тот же проект «упаковывается» по-разному под каждую платформу. В этом сила Nitro-пресетов.

Деплой — не финальная точка, а начало эксплуатации. После выката полезно сразу настроить наблюдаемость: логирование серверных ошибок, мониторинг времени ответа, отслеживание исключений на клиенте. SSR-приложение имеет две стороны — сервер и браузер, и проблемы могут жить на любой из них. Так же стоит продумать стратегию выката новых версий, чтобы пользователи на старой странице не упирались в исчезнувшие чанки.

Частые ошибки

• Путать build и generate. build — для динамики с сервером, generate — для статики. Сайту с SSR нужен живой сервер.
• Не задать переменные окружения на проде. Локальный .env туда не едет — настройте окружение хостинга.
• Не проверить сборку. Перед выкатом прогоните nuxt preview — dev и prod ведут себя по-разному.

Best practices

• Для динамических сайтов — nuxt build и подходящий Nitro-пресет; для статики — nuxt generate.
• Все секреты и URL — через переменные окружения платформы, не в коде.
• Обязательный шаг перед продом — локальная проверка через nuxt preview.

Итог: nuxt build и Nitro-пресеты делают деплой Nuxt простым и переносимым — от Node-сервера до бессерверных платформ. Вы прошли весь путь: от понимания SSR до выката фулстек-приложения в продакшен. Теперь у вас есть карта Nuxt целиком.