Self-host против Vercel: анатомия standalone, env на билде и за что на самом деле платят платформе

Что на самом деле выдаёт output standalone

С output: 'standalone' в next.config.js команда next build не просто компилирует: она прогоняет file tracing по серверной сборке — статический анализ каждого require/import, достижимого из серверного кода, — и выдаёт .next/standalone/: минимальный server.js (тонкий HTTP-сервер вокруг обработчика запросов Next) плюс только тот срез node_modules, необходимость которого трейс доказал. Репозиторий с node_modules на 800 МБ обычно трейсится до 50–150 МБ, а multi-stage-образ на node:20-alpine весит порядка 150–250 МБ вместо гигабайта с лишним.

Чего трейс намеренно не включает — всего, что не является серверным кодом. .next/static/ — весь клиентский JS, CSS и ассеты с хешами сборки — билд создаёт, но в standalone не копирует: по замыслу их раздаёт CDN; server.js будет отдавать эти пути, только если папку положить рядом. То же с public/. Оптимизация изображений через next/image требует sharp в рантайм-образе: современный Next подтягивает его как optional-зависимость, но pruned-инсталляции и alpine-сборки регулярно его теряют, а без него /_next/image либо уходит в медленный фолбэк, либо падает. Последняя ловушка невидима до первого контейнерного деплоя: server.js читает PORT и HOSTNAME из окружения, и без HOSTNAME=0.0.0.0 он слушает там, куда не дотянется ни один балансировщик.

FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
RUN corepack enable && pnpm install --frozen-lockfile && pnpm build
# next.config.js: { output: 'standalone' }

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production HOSTNAME=0.0.0.0 PORT=3000
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static  # в standalone НЕТ — копируй или 404
COPY --from=builder /app/public ./public              # в standalone НЕТ — копируй или 404
EXPOSE 3000
CMD ["node", "server.js"]

Переменные окружения: вшито на билде против чтения в рантайме

NEXT_PUBLIC_*-переменные не существуют в рантайме браузера — там нечего читать. Бандлер строково заменяет каждое вхождение process.env.NEXT_PUBLIC_X на литерал, существовавший в момент next build, — ровно как define-плагин инлайнит константы. В этом весь механизм классического инцидента: ops меняет NEXT_PUBLIC_API_URL в манифесте деплоя, перезапускает все поды — и ничего не происходит: клиентский бандл по-прежнему содержит старую строку, символ в символ, потому что ребилда не было. Серверный код устроен наоборот: обычный process.env.SECRET в route handler или серверном компоненте читается из процесса вживую на каждом запросе (с одной оговоркой — значения, захваченные при пререндере статической страницы, тоже замораживаются на билде).

Это лоб в лоб сталкивается с дисциплиной build once, promote everywhere, по которой живёт большинство контейнерных команд. Если staging и production делят один образ, каждое NEXT_PUBLIC_-значение в нём принадлежит тому окружению, которое его собрало. Честные варианты: пересобирать на каждое окружение (дёшево с кешем сборки, но образы перестают быть идентичными артефактами); вообще не класть меняющиеся между окружениями значения в NEXT_PUBLIC_ и передавать их с сервера — читать process.env в серверном компоненте и спускать пропсом; или инжектить объект runtime-конфига в HTML из layout. Правило, переживающее аудиты: NEXT_PUBLIC_ — для значений, действительно постоянных на артефакт сборки, а не на окружение.

Что Vercel продаёт на самом деле — и где пересекаются линии затрат

Если снять маркетинг, платформа продаёт четыре твёрдые вещи. Глобально реплицированный кеш ISR (Incremental Static Regeneration — пошаговая статическая регенерация) /данных: ревалидация доезжает до каждого региона без вашего общего хранилища. Флот оптимизации изображений: ресайз по требованию на эдже, с кешем, без планирования мощностей под sharp. Anycast-эдж (глобальная сеть точек присутствия, PoP) перед всем этим. И zero-config preview-деплои — полное окружение на каждый pull request; вот это честно сложнее всего воспроизвести самому. Все четыре пункта — это прямой ответ на вопрос «за что я плачу?»; переезжая без этого понимания, вы возмещаете их стоимость инженерными неделями. Контейнер плюс обычный CDN дёшево закрывают остальное: CDN берёт статику и кешируемые страницы, sharp жуёт картинки на вашем CPU, балансировщик — ваш «эдж». Одна вещь молча не переезжает, и она анонсирует следующие два урока: дефолтный кеш ISR — это диск конкретного пода, так что со второй репликой кеш-с-одной-истиной, который давал Vercel, перестаёт существовать.

У экономики есть форма, которую стоит запомнить вместо точных цен — цены дрейфуют. Serverless-биллинг примерно линеен по инвокациям, ГБ-часам, трансформациям изображений и egress; VM — плоская константа с потолком утилизации. Ровный трафик любит плоский тариф; пиковый — метрический. Стабильные 50–100 req/s SSR спокойно живут на паре 4-vCPU машин — порядка 50–100 долларов в месяц плюс egress CDN, — тогда как та же постоянная нагрузка на per-request-биллинге выходит на порядок дороже. Переверните профиль — и ответ перевернётся: базовые 0,5 req/s с редкими 50-кратными пиками от прессы — ровно то, что метрический тариф поглощает без планирования мощностей, а VM пришлось бы держать под пик и простаивать остаток квартала. Точка пересечения не тонкая ни в одну сторону; тонкое — заложить в смету инженерные недели на общий кеш, картиночный конвейер и окружения на каждый PR.