Vercel и Netlify

01Что они на самом деле делают

Представьте эти платформы как билд-сервер, CDN и serverless-рантайм, склеенные через Git. При пуше платформа клонирует репозиторий, определяет фреймворк, запускает команду сборки и разделяет результат. Статические файлы (HTML, CSS, JS, изображения) уходят в глобальный CDN с долгим кэшированием. Серверный код (API-маршруты, страницы с серверным рендерингом, server actions) упаковывается в функции, которые запускаются по требованию в одном или нескольких регионах. Middleware или edge-функции выполняются перед кэшем на облегчённом рантайме рядом с пользователем. Каждый деплой неизменяем и имеет свой URL; «production» — просто алиас, указывающий на один из них. Поэтому откат мгновенный: вы переводите алиас на более старый деплой, ничего не пересобирается. По сравнению с VPS вы больше не думаете о серверах, зато думаете о длительности функций, регионах, заголовках кэширования и счёте.

• Статика → CDN. Серверный код → функции. Middleware → edge.
• Каждый деплой неизменяем; production — это алиас.
• Превью-деплои для каждой ветки или pull request.

02Настройка проекта шаг за шагом

Создайте аккаунт, импортируйте репозиторий из GitHub, GitLab или Bitbucket и примите определённые настройки фреймворка. Первый деплой обычно работает без изменений. Затем сделайте настоящую настройку. Добавьте переменные окружения по окружениям (Production, Preview, Development) в дашборде и никогда не позволяйте превью-сборкам использовать продакшен-секреты или продакшен-базу. Добавьте свой домен: apex-домен направьте A-записью или ALIAS, а поддомен www — CNAME, как подскажет платформа; сертификаты выпускаются автоматически. Защитите превью встроенной deployment protection, если они показывают ещё не выпущенную работу. Установите регион функций тот же, что у базы данных. Наконец, подключите CLI для локальной работы: он подтягивает переменные окружения и может воспроизвести сборку платформы локально.

1# Vercel
2npm i -g vercel
3vercel link              # connect this folder to a project
4vercel env pull .env.local
5vercel                   # preview deploy
6vercel --prod            # production deploy
7 
8# Netlify
9npm i -g netlify-cli
10netlify link
11netlify dev              # local server with functions and redirects
12netlify deploy --prod

03Рендеринг и кэширование: static, ISR, SSR, edge

То, где рендерится страница, определяет скорость и стоимость. Статические страницы собираются один раз и отдаются из CDN: быстрее всего и почти бесплатно. Incremental Static Regeneration (ISR) отдаёт закэшированную страницу и перегенерирует её в фоне после периода revalidate или по требованию, когда ваша CMS вызывает эндпоинт ревалидации, — так вы получаете скорость статики со свежим контентом. Серверный рендеринг запускает функцию на каждый запрос: это нужно для персонализированных страниц, но каждый запрос стоит времени функции. Middleware выполняется перед кэшем на каждом подходящем запросе, поэтому держите его крошечным: редиректы, rewrites, проверка auth-cookie, A/B-распределение. Обе платформы учитывают стандартные заголовки Cache-Control, а Vercel также читает CDN-Cache-Control и Vercel-CDN-Cache-Control для правил только для CDN. Netlify использует Netlify-CDN-Cache-Control и поддерживает cache tags для точечной очистки. Хорошее правило: по умолчанию static, для контента ISR, SSR — только там, где ответ действительно зависит от запроса.

1// app/blog/[slug]/page.tsx (Next.js App Router)
2export const revalidate = 3600; // regenerate at most once per hour
3 
4export async function generateStaticParams() {
5  const posts = await fetch("https://cms.example.com/posts").then((r) => r.json());
6  return posts.map((p: { slug: string }) => ({ slug: p.slug }));
7}
8 
9export default async function Post({ params }: { params: Promise<{ slug: string }> }) {
10  const { slug } = await params;
11  const post = await fetch("https://cms.example.com/posts/" + slug, {
12    next: { tags: ["post-" + slug] },
13  }).then((r) => r.json());
14  return <article><h1>{post.title}</h1></article>;
15}

04Функции: лимиты и как устроен биллинг

Обе платформы запускают ваш серверный код как функции, в основном на Node.js. На Vercel функции по умолчанию используют Fluid compute: один инстанс может обслуживать много одновременных запросов, что уменьшает холодные старты и стоимость для I/O-нагрузки вроде обращений к базе или к AI API. Оплата идёт за активное время CPU, выделенную память и вызовы, так что ожидание сети стоит намного меньше, чем «сырая» длительность. Edge Functions и middleware работают на более лёгком рантайме V8; теперь Vercel рекомендует Node.js-рантайм для большинства функций. Netlify Functions под капотом работают на AWS Lambda, а Netlify Edge Functions — на Deno на edge. Netlify использует модель планов на кредитах: деплои, вычисления, трафик и запросы расходуют кредиты из ежемесячного лимита. У обеих платформ есть максимальная длительность, лимиты размера тела запроса и памяти по планам, поэтому долгим задачам место в очереди или в фоновом воркере где-то ещё.

05Планы и ценовые ловушки

План Hobby у Vercel бесплатный, но только для личного некоммерческого использования; клиентским и корпоративным проектам нужен Pro, который тарифицируется за место (seat) с ежемесячным кредитом на использование, а дальше pay-as-you-go. Новые Pro-команды получают бюджет расходов по умолчанию с алертами и возможностью ставить проекты на паузу при достижении лимита: держите это включённым. У Netlify есть планы Free, Personal и Pro с ежемесячным лимитом кредитов; когда кредиты заканчиваются, сайты могут быть приостановлены, если не докупить кредиты или не включить автопополнение. Ловушки на обеих платформах похожи: вирусная страница с серверным рендерингом на каждый запрос, большие неоптимизированные изображения или видео, отдаваемые как трафик, боты, бьющие по динамическим маршрутам, оптимизация тысяч исходных изображений и превью-сборки на каждый коммит в загруженном монорепозитории. Перед решением для клиента сверяйте цены на официальных страницах: обе компании регулярно меняют модели.

• Hobby на Vercel — некоммерческий: для клиентской работы нужен Pro.
• Включите лимиты расходов или бюджетные алерты в первый же день.
• Кэшируйте агрессивно; некэшированный SSR — то место, где растут счета.

06Путь запроса: маршрутизация, кэш и функции

Запрос попадает в ближайшую edge-локацию. Сначала выполняются правила маршрутизации платформы: редиректы, rewrites и заголовки из фреймворка или конфигов. Затем выполняется middleware, если он подходит. Дальше проверяется CDN-кэш по URL и любым ключам кэша или заголовкам Vary. Попадание в кэш возвращается сразу и стоит только CDN-запрос и трафик. Промах вызывает функцию в её настроенном регионе, который может быть далеко от edge, поэтому каждый промах платит за путь от edge до региона плюс за обращения к вашей базе. Stale-while-revalidate позволяет CDN отдавать устаревший контент, обновляя его в фоне. Cookies — скрытый враг кэширования: ответ, зависящий от сессионной cookie, нельзя делить между пользователями, поэтому разбивайте страницы на кэшируемый каркас и небольшие персонализированные части, загружаемые на клиенте или стримингом.

1// next.config.ts: long cache for a public API route, revalidated in the background
2import type { NextConfig } from "next";
3 
4const config: NextConfig = {
5  async headers() {
6    return [
7      {
8        source: "/api/public/:path*",
9        headers: [{ key: "Cache-Control", value: "public, s-maxage=300, stale-while-revalidate=86400" }],
10      },
11    ];
12  },
13};
14 
15export default config;

07Подключения к базам данных из serverless-функций

Функции масштабируются, создавая больше инстансов, и каждый инстанс, открывающий собственные TCP-соединения к Postgres, под нагрузкой может исчерпать лимит соединений базы. Проблему решают три инструмента. Первый — пулер перед базой: PgBouncer, pooled-эндпоинт managed-провайдера или Prisma Accelerate, в transaction mode. Второй — для edge и короткоживущих функций выбирайте драйверы, рассчитанные на serverless, например HTTP- или WebSocket-драйверы serverless-провайдеров Postgres. Третий — с Vercel Fluid compute один инстанс обслуживает много запросов, так что небольшой пул на уровне модуля эффективно переиспользуется; используйте хелперы waitUntil или attachDatabasePool, чтобы простаивающие соединения закрывались до заморозки инстанса. Всегда ставьте регион функции рядом с базой: один межрегиональный переход на запрос, умноженный на десять запросов на страницу, — это разница между 50 и 500 миллисекундами.

08Безопасность: секреты, превью и edge

Переменные окружения шифруются при хранении, но всё, что имеет клиентский префикс (NEXT_PUBLIC_, PUBLIC_, VITE_), встраивается в браузерный бандл: считайте такие значения публичными. Ограничьте чувствительные переменные только окружением Production и пометьте их как sensitive, чтобы их нельзя было прочитать обратно из дашборда. Превью — реальная поверхность атаки: pull request из форка может во время сборки выполнить код с вашими секретами, поэтому платформы по умолчанию не отдают секреты сборкам из форков; так и оставьте. Используйте deployment protection (пароль, SSO или Vercel Authentication) для превью невыпущенной работы и добавьте заголовок X-Robots-Tag noindex, чтобы они никогда не индексировались. Включите файрвол и защиту от ботов для логина и API-маршрутов и добавьте rate limiting для дорогих эндпоинтов, ведь каждый злонамеренный запрос — это оплачиваемое время функции.