Vercel environment variables хранят API-ключи и токены отдельно от кода, но по умолчанию значение переменной может прочитать любой, у кого есть доступ к проекту в дашборде. Разница между Production, Preview и Development влияет на то, куда утечет ключ при ошибке конфигурации. Ниже разберем: какие переменные видны в браузере, что попадает в логи сборки, и почему после инцидента в апреле 2026 Vercel сама рекомендовала клиентам ротировать ключи.
TL;DR: Vercel делит переменные на Production, Preview и Development, а внутри каждой есть выбор Sensitive или обычная. Обычная переменная читается из дашборда кем угодно с доступом к проекту, Sensitive шифруется и после сохранения не показывается даже вам. Переменная с префиксом NEXT_PUBLIC_ всегда попадает в браузерный код, даже если она Sensitive. В статье: таблица различий, разбор реального инцидента и пошаговая настройка.
Что такое переменные окружения в Vercel простыми словами?
Переменная окружения — это пара ключ-значение, которую Vercel подставляет в приложение во время сборки или на сервере, вместо того чтобы хранить значение прямо в коде.
Смысл прост: секрет живет в настройках Vercel, а не в репозитории на GitHub. Ключ Stripe, токен базы данных или пароль от почтового сервиса не попадает в git-историю, значит его не увидит никто, кто получит доступ к репозиторию. Это базовая гигиена для любого проекта на Vercel, будь то Next.js, Vite или обычный статический сайт.
На практике переменную создают в разделе Settings, потом Environment Variables проекта. Указываете имя, например STRIPE_SECRET_KEY, значение и окружение, где переменная должна работать. После сохранения нужен redeploy, иначе старая сборка продолжит работать без нового значения. Это частая причина вопросов вида «добавил ключ, а он не подхватился» на форумах и в чатах вайбкодеров.
Чем отличаются Production, Preview и Development в Vercel?
Production обслуживает боевой домен, Preview разворачивает каждый pull request и ветку отдельно, Development подтягивается локально через vercel env pull. Одна и та же переменная может иметь разное значение в каждом из трех окружений.
По данным собственной документации Vercel, у платформы четыре области видимости: Production, Preview, Development и общая «All» для всех сразу (env-гайд от June 2026). Самая частая ошибка новичков в вайбкодинге — добавить ключ только в Production и удивляться, почему preview-деплой падает с ошибкой авторизации.
| Окружение | Когда применяется | Что туда класть |
|---|---|---|
| Production | Деплой с продакшн-ветки, обычно main | Боевые ключи Stripe, реальную базу данных |
| Preview | Любая другая ветка, pull request | Тестовые/sandbox-ключи, тестовую базу |
| Development | Локальный запуск через vercel dev или vercel env pull | Локальные значения, можно даже моки |
Разделение окружений решает конкретную проблему: тестовый пуш в фиче-ветку не должен списывать деньги через боевой Stripe-ключ. Один клиент Максима как-то чуть не отправил тестовые заказы в реальную CRM, потому что Preview и Production делили один и тот же ключ API.
Что видно в preview деплое и почему это отдельный риск?
Preview-деплой Vercel создает публичную ссылку для каждой ветки и pull request, доступную по URL без авторизации, если не включена защита. Если в Preview лежит боевой ключ, любой, кто нашел или угадал ссылку, получает доступ к продакшн-данным.
Здесь и кроется главный риск. Ссылка на preview выглядит как project-git-branch-name.vercel.app и по умолчанию доступна всем, у кого есть URL. Поисковые роботы иногда индексируют такие адреса, если на них нет noindex-заголовка. Плюс preview-сборки часто остаются висеть месяцами после того, как ветку смержили и забыли удалить.
Практический вывод: держите в Preview только тестовые ключи, а для самих preview-ссылок включайте Vercel Deployment Protection — она добавляет пароль или SSO перед открытием сайта. Это отдельная настройка в Settings, Deployment Protection, и по умолчанию она стоит на минимальном уровне Standard, что подходит не для всех проектов.
Что означает NEXT_PUBLIC и какие ключи видны в браузере?
Переменная без префикса NEXT_PUBLIC_ доступна только на сервере: в API routes, Server Components, getServerSideProps. Стоит добавить префикс NEXT_PUBLIC_, и значение зашивается прямо в JavaScript-бандл, который скачивает браузер каждого посетителя.
Это встроенный механизм защиты в Next.js. Он вырезает из клиентского бандла все переменные без нужного префикса, поэтому попытка вызвать process.env.SECRET_KEY в компоненте React вернет undefined. Проверить легко: открыть сайт, найти в консоли браузера свою переменную, если она печатается — значит она публична, хочет того автор или нет.
Важный нюанс, который путает даже опытных: если переменную пометили Sensitive в Vercel, но при этом добавили ей префикс NEXT_PUBLIC_, она все равно попадет в браузерный код при сборке (env.dev, апрель 2026). Флаг Sensitive защищает значение в дашборде и логах, но не отменяет логику Next.js на этапе билда. Правило простое: NEXT_PUBLIC_ ставим только на то, что и так не секрет — идентификатор аналитики, публичный ключ виджета, домен API.
Что видно в логах сборки Vercel и как это исправить?
Обычная переменная может напечататься в логах сборки открытым текстом, если код или сборщик выводит её через console.log или ошибку. Sensitive-переменная длиной от 32 символов Vercel автоматически заменяет на [REDACTED] в логах, короткие ключи под это правило не попадают.
Здесь есть подвох, о котором редко пишут в туториалах. Маскирование в логах работает только при выполнении двух условий сразу: переменная создана как Sensitive, и её значение не короче 32 символов (Vercel Knowledge Base). Короткий API-ключ на 16-20 символов спокойно проскочит в лог сборки, даже если стоит галочка Sensitive.
Отсюда практическое правило для команды: не полагайтесь только на автоматическую редакцию. Уберите из кода любые console.log(process.env...), особенно в скриптах сборки и миграциях. Второй момент: Sensitive-переменные расшифровываются только во время выполнения билда или рантайма, поэтому их нельзя выгрузить через vercel env pull — команда просто их пропустит.
Как включить Sensitive переменные в Vercel пошагово?
Sensitive помечает значение как нечитаемое после сохранения: его нельзя посмотреть заново ни в дашборде, ни через CLI, доступны только Production и Preview.
Шаг 1. Откройте настройки проекта. Перейдите в Settings, затем Environment Variables в дашборде Vercel.
Шаг 2. Добавьте или отредактируйте переменную. Введите ключ и значение, для существующей секретной переменной проще удалить старую и создать заново с нужным флагом.
Шаг 3. Включите переключатель Sensitive. Он доступен только для окружений Production и Preview, для Development такой опции нет.
Шаг 4. Выберите окружения и сохраните. После сохранения значение больше не отображается, при следующей проверке в дашборде вы увидите только метку Sensitive без самого ключа.
Шаг 5. Сделайте redeploy. Новое значение подхватится только в следующей сборке, старый деплой продолжит работать со старыми переменными.
Владелец команды в Vercel может включить политику, при которой каждая новая переменная в Production и Preview автоматически становится Sensitive — это находится в Settings, Security & Privacy. Для проектов, где над кодом работает несколько человек через AI-инструменты вроде Cursor или Windsurf, эта настройка снимает риск человеческого фактора: никто просто физически не сможет забыть поставить галочку.
Что случилось в апреле 2026 и чему это учит?
В апреле 2026 злоумышленник через скомпрометированный аккаунт стороннего AI-сервиса Context.ai получил доступ к внутренним системам Vercel и расшифровал несенситивные переменные окружения части клиентов. Sensitive-переменные и open source пакеты компании инцидент не затронул.
Цепочка атаки началась с заражения сотрудника Context.ai инфостилером, дальше через OAuth в Google Workspace злоумышленник добрался до аккаунта сотрудника Vercel, а оттуда до переменных клиентов, не помеченных как Sensitive (Trend Micro, апрель 2026). Vercel официально подтвердила инцидент в бюллетене и порекомендовала клиентам ротировать все ключи, которые не были отмечены Sensitive (бюллетень Vercel).
Максим: «Мог просто засесть до пяти ночи и просто там править одну какую-то функцию, которая не работала. Если бы не терпение — в моменте я уже испотел, и мне хотелось просто всё это закрыть. Но я понимал, что это можно решить и нужно решить, чтобы идти дальше.»
С безопасностью конфигурации та же логика. Кажется, что галочка Sensitive это мелочь, на которую жалко тратить время в моменте запуска. Но именно эта мелочь весной 2026 отделила клиентов, которым пришлось ротировать ключи, от тех, кого инцидент вообще не задел.
Как не слить ключи через git и .env файлы?
Файл .env.local никогда не должен попадать в репозиторий: добавьте его в .gitignore сразу при старте проекта, а секреты дублируйте в дашборд Vercel вручную или через CLI.
Частая ошибка при разворачивании проекта на Vercel — платформа не подхватывает .env файл из репозитория автоматически, если он не был явно добавлен в переменные окружения через дашборд. Разработчик копирует содержимое .env, вставляет построчно в форму Vercel, и часть значений случайно остается видимой в истории коммитов, потому что файл до этого лежал в git.
Три простых правила снижают риск почти до нуля:
- Добавляйте
.env*в .gitignore в первом же коммите, а не когда «дойдут руки». - Импортируйте переменные в Vercel через встроенную функцию загрузки .env файла целиком, вместо копирования по одной строке в чат или заметки.
- Проверяйте историю git перед публикацией репозитория: если ключ туда уже попал, одного удаления файла недостаточно, ключ остается в истории коммитов и требует ротации.
Для команд, которые ведут несколько проектов сразу, ручное управление десятками ключей в разных дашбордах превращается в отдельную головную боль. Здесь на сцену выходят отдельные секрет-менеджеры.
Vercel или отдельный секрет-менеджер: когда переходить?
Штатные переменные Vercel подходят для одного-двух проектов с небольшой командой. Централизованный секрет-менеджер вроде Infisical нужен, когда ключи дублируются между Vercel, CI/CD и другими сервисами, и никто не отслеживает, где какая версия актуальна.
| Критерий | Только Vercel env | Отдельный секрет-менеджер |
|---|---|---|
| Проектов в работе | 1-2 | 3 и больше |
| Аудит изменений секретов | Общий activity log | Отдельный журнал именно по секретам |
| Ротация ключей | Вручную в каждом проекте | Централизованно, с рассылкой во все сервисы |
| Синхронизация с CI/CD | Дублирование вручную | Автоматический sync |
Штатных возможностей Vercel хватает большинству вайбкодеров, которые запускают один продукт. Но по факту, если у вас растет портфель проектов, ручное копирование ключей между Vercel, GitHub Actions и локальным .env превращается в источник ошибок само по себе.
Кому это критично: вайбкодерам и разработчикам
Вайбкодер, который собирает продукт через AI-инструменты и разворачивает его за вечер, рискует больше, а не меньше опытного разработчика. Скорость запуска обычно выигрывает у внимательности к деталям конфигурации, а именно там прячется утечка.
Разработчик, который уже настраивал CI/CD раньше, скорее автоматически включит Sensitive и разделит окружения. Новичку в вайбкодинге стоит закрепить привычку: любая статья про запуск MVP на Vercel должна включать пункт про переменные окружения, а не заканчиваться на «нажмите Deploy». Если проект связан с автоматизацией деплоя или инфраструктурой, эту задачу можно делегировать через каталог агентов VibeCoderz — там собраны готовые промпты под devops-задачи.
Часто задаваемые вопросы
Нужно ли делать redeploy после изменения переменной окружения в Vercel? Да, обязательно. Новое значение переменной подхватится только в следующей сборке, уже запущенный деплой продолжит работать со старым значением до тех пор, пока вы не пересоберете проект вручную.
Можно ли посмотреть значение Sensitive-переменной после сохранения? Нет, ни в дашборде, ни через CLI. Если значение забыто, единственный вариант — удалить переменную и создать заново с новым значением.
Почему переменная с NEXT_PUBLIC_ видна в браузере, даже если она Sensitive? Флаг Sensitive защищает хранение в дашборде Vercel, но не отменяет логику Next.js: любая переменная с этим префиксом инлайнится в JavaScript-бандл на этапе сборки, и это касается всех переменных с таким префиксом без исключений.
Что делать, если ключ уже попал в git-историю репозитория? Считайте ключ скомпрометированным и ротируйте его немедленно в сервисе, который его выдал. Удаление файла из последнего коммита не убирает значение из истории git, поиск по старым коммитам все равно его найдет.
Чем Preview окружение в Vercel отличается от Production по рискам? Preview-ссылки часто остаются открытыми без авторизации и живут дольше, чем сама фиче-ветка. Держать там боевые ключи означает дать доступ к продакшн-данным всем, кто найдет ссылку.
Нужен ли отдельный секрет-менеджер для одного личного проекта на Vercel? Обычно нет. Штатных Sensitive-переменных и разделения окружений достаточно, отдельный секрет-менеджер оправдан при нескольких проектах и команде, которая дублирует ключи в разных сервисах.
Что случилось с Vercel в апреле 2026 и касается ли это моего проекта? Компания подтвердила инцидент с доступом к несенситивным переменным ограниченного круга клиентов через взлом стороннего сервиса. Если ваши ключи в Vercel не были помечены как Sensitive на момент инцидента, стоит их ротировать вне зависимости от того, получали вы уведомление или нет.
Разбор конкретного стека под ваш проект и настройку безопасного деплоя можно обсудить на консультации с Максимом: t.me/maxnagovitsyn. Больше практики по AI IDE и деплою — в каталоге инструментов VibeCoderz.
Обновлено: октябрь 2026