Deploy Without Bill Shock

Для vibed-приложения на React или Next.js стандартный маршрут — платформы с бесплатным тиром и деплоем из GitHub: Vercel (родной дом Next.js и v0), Netlify, Cloudflare Pages. Подключаете репозиторий — каждый push собирается и публикуется автоматически. Supabase бесплатного тира закрывает базу, авторизацию и хранение файлов. Отдельный сервер с постоянным процессом (например, для WebSocket) удобно поднять на Render или Railway. Lovable и Bolt умеют публиковать одной кнопкой на собственной инфраструктуре — это честный вариант для MVP, пока вам не нужен контроль.

Важно понимать экономику этих платформ, потому что именно она порождает истории про внезапные счета. Модель pay-as-you-go: бесплатный тир включает щедрый объём (сборки, гигабайты трафика, вызовы функций, минуты вычислений), а сверх него тарификация идёт за использование. Ключевые статьи расхода, о которых стоит знать: исходящий трафик (egress) — каждый мегабайт, отданный пользователям; вызовы serverless-функций и их время работы; оптимизация изображений (на Vercel тарифицируется отдельно); строки чтения/записи и объём базы.

Следствие: у serverless нет естественного потолка. Классический сервер за $5 в месяц под нагрузкой просто упадёт — неприятно, но бесплатно. Serverless не падает: он масштабируется и выставляет счёт. Это свойство — фича для бизнеса с деньгами и ловушка для прототипа без лимитов. Поэтому правило деплоя: сначала лимиты, потом публичная ссылка.

Истории «проснулся — а там счёт» регулярно всплывают на Hacker News и в X, и у них повторяющаяся анатомия. Разберём типовые сценарии.

Сценарий первый: платный API, вызываемый без ограничений. Приложение дергает OpenAI или другой LLM API. Ключ защищён, но эндпоинт, который его использует, открыт без авторизации и лимитов. Пост о приложении завирусился — или его нашёл бот — и за ночь набежали десятки тысяч запросов к платной модели. Вариант хуже: ключ лежал в клиенте (урок 4), и его просто украли для своих задач.

Сценарий второй: бесконечный цикл, оплаченный по секундам. Serverless-функция вызывает саму себя или два сервиса зовут друг друга по кругу: функция пишет в базу → триггер базы зовёт функцию → функция снова пишет. Каждая итерация тарифицируется. Классический случай 2024 года: пользователь Netlify получил счёт $104 000, значительная часть которого — трафик; после огласки компания счёт простила, но полагаться на прощение — не стратегия.

Сценарий третий: дорогая мелочь на горячем пути. Оптимизация изображений на каждый просмотр страницы, тяжёлый запрос к базе без кэша на главной, отсутствие CDN-кэширования статики. Всё работает, просто каждый просмотр стоит денег — и стоимость линейно растёт с трафиком.

Общий знаменатель всех трёх: расход не был ограничен и не был виден. Владелец узнавал о проблеме из счёта, а не из алерта. Значит, защита строится из двух половин: жёсткие потолки расходов и ранняя видимость.

Настройка защиты занимает меньше часа. Три слоя.

Слой 1 — потолок у платформы. На Vercel это Spend Management: задаёте месячную сумму, при достижении которой проект автоматически ставится на паузу (плюс уведомления на 50% и 75%). Пауза сайта неприятна, но это ваш выбор заранее: потерять прототип на ночь или получить счёт как за подержанную машину. У облаков вроде AWS жёсткого стоп-крана нет — там настраиваются AWS Budgets с алертами, и это тем более обязательно. У OpenAI и Anthropic в личном кабинете есть месячные лимиты на API-ключ — поставьте сумму, которую готовы потерять.

Слой 2 — прокси и лимиты на пользователя. Все вызовы платных API идут только через ваш серверный эндпоинт: ключ на сервере, эндпоинт требует авторизацию, и на нём стоит rate limit. Минимальная реализация — счётчик запросов на пользователя в день прямо в базе:

// Псевдокод серверного эндпоинта /api/ai
const used = await getDailyUsage(userId);
if (used >= 20) {
  return new Response('Дневной лимит исчерпан', { status: 429 });
}
await incrementUsage(userId);
const answer = await callOpenAI(prompt); // ключ живёт только здесь

Двадцать запросов в день на пользователя — и даже вирусный трафик ограничен предсказуемой суммой.

Слой 3 — кэш и здравый смысл на горячем пути. Одинаковые запросы к LLM кэшируются по хэшу промпта; статика и картинки отдаются через CDN-кэш; тяжёлые запросы к базе на главной странице кэшируются хотя бы на минуту. Промпт для агента: «найди в проекте самые частые и самые дорогие операции (LLM-вызовы, запросы к базе на главной, обработка изображений) и предложи, где добавить кэширование и лимиты».

Последний элемент взрослого деплоя — разделение окружений. Даже для прототипа держите три: локальная разработка (dev), превью для проверки изменений (preview) и боевое (production). Vercel и Netlify дают это бесплатно и автоматически: каждый pull request получает собственный preview-URL — полную копию приложения с этим изменением, которую можно прокликать до вливания в основную ветку. Привычка из этой связки: в production попадает только то, что вы посмотрели на preview-ссылке и что прошло тесты из урока 6 (GitHub Actions блокирует вливание при красном прогоне).

Переменные окружения задаются в панели платформы отдельно для каждого окружения — и это решает две проблемы сразу. Во-первых, секреты не живут в git (урок 4). Во-вторых, окружения не смешиваются: preview смотрит в тестовую базу Supabase, production — в боевую. Ошибка «превью-эксперимент удалил строки боевой базы» стоит дороже, чем второй бесплатный проект Supabase под тесты.

Перед самой публикацией — финальный чек-лист курса. Безопасность: чек-лист урока 4 пройден, секреты только в переменных окружения, RLS включён. Тесты: smoke-набор зелёный и запускается на каждый push. Деньги: spend-потолок задан, лимиты на пользователя стоят, алерты приходят на почту, лимит на ключах LLM-провайдера установлен. Наблюдаемость: вы знаете, где смотреть логи ошибок и график расходов, и заглядываете туда первую неделю ежедневно.

Этот момент — финиш курса: приложение, рождённое из промпта, доехало до продакшена с замками на данных, тестами на поведении и потолком на счёте. Дальше — пользователи.