Railway environment variables хранят пароли, API-ключи и webhook-секреты вне кода, но по умолчанию любой участник workspace может их прочитать в дашборде. Ниже разберем, чем Service Variables отличаются от Shared, зачем нужны Sealed Variables и как настроить доступ команды, чтобы junior-разработчик не увидел боевой ключ Stripe.
Railway хранит секреты в четырех слоях: Service, Shared, Reference и Sealed Variables. Shared экономит время при ротации ключей, Sealed прячет значение даже от владельца проекта. Роли Admin, Member и Deployer разграничивают, кто может менять переменные, а кто только триггерит деплой.
Что такое Service Variables в Railway?
Service Variables привязаны к одному сервису в одном окружении. Это стандартное место для секрета, который использует только один компонент проекта, например бэкенд.
Один и тот же ключ DATABASE_URL может иметь разное значение в проде и в стейджинге, и это нормально. По документации Railway о переменных, платформа сканирует корень репозитория на файлы вроде .env, .env.local и .env.production и предлагает найденные ключи для импорта одним кликом. Ничего перепечатывать руками не нужно.
Добавляются такие переменные через вкладку Variables у конкретного сервиса. Можно вбить пару ключ-значение вручную или открыть RAW Editor и вставить сразу весь .env файл целиком. Railway сам разложит его на отдельные строки.
Проблема в другом: если у проекта пять сервисов и всем нужен один и тот же STRIPE_SECRET_KEY, придется вставлять его пять раз. Ротация ключа превращается в квест "не забыл ли я шестой сервис". Для этого случая есть следующий слой.
Чем Shared Variables отличаются от Service Variables?
Shared Variables задаются один раз на уровне проекта и подключаются к любому числу сервисов. Обновил значение в одном месте, и все сервисы, которые на него ссылаются, подхватят новое при следующем деплое.
Shared variables центрируют все, что переиспользуется между сервисами, а Reference variables вытягивают эти значения без копипаста. На практике это выглядит так: в Project Settings открываешь Shared Variables, вбиваешь STRIPE_SECRET_KEY один раз, а дальше просто "расшариваешь" его с нужными сервисами.
Причем шаринг не копирует значение, а создает ссылку. Технически внутри сервиса появляется Reference Variable, а не дубликат секрета. Это и решает проблему "забыли обновить в одном из пяти мест".
Из транскрипта одного из разборов Railway: переменные, добавленные через Shared Variables, физически не попадают в GitHub репозиторий, даже когда .env файл проекта запушен в публичный репо. Секрет живет только на стороне платформы.
| Тип переменной | Где живет | Когда использовать |
|---|---|---|
| Service Variable | Один сервис, одно окружение | Секрет нужен только одному компоненту |
| Shared Variable | Уровень проекта, все окружения | Один ключ переиспользуют 2+ сервиса |
| Reference Variable | Ссылка на другую переменную | Нужно подтянуть значение без копипаста |
| Sealed Variable | Write-only, скрыт в UI | Продакшен-пароли и платежные ключи |
Как секреты утекают через логи и git push?
Чаще всего секрет утекает не из-за взлома Railway, а из-за случайного коммита .env файла или вывода переменной в console.log при отладке.
Railway дает четыре места для переменной: per-service, project-wide Shared, эфемерные PR-окружения и встроенные системные RAILWAY_*. Выбрал не тот слой, и ключ либо утек в публичный превью PR, либо оказался вставлен в шесть сервисов, а на седьмой забыли обновить при ротации.
Второй частый сценарий из практики: разработчик хранит пароль в .env локально, потом коммитит файл, потому что забыл добавить его в .gitignore. Дальше ключ живет в истории git навсегда, даже если файл удалить следующим коммитом.
Решение здесь простое, но его игнорируют. Создавайте .gitignore с записью .env сразу при инициализации репозитория, а рядом кладите example.env без реальных значений, только с именами переменных. Так следующий разработчик в команде поймет, какие ключи нужны, и не полезет спрашивать пароль в общем чате.
Что делать, если .env уже попал в GitHub?
Первый шаг: не паниковать и не просто удалить файл следующим коммитом, потому что старое значение останется в истории git навсегда.
Правильная последовательность такая: сначала выполнить git rm --cached путь/к/.env, чтобы git перестал отслеживать файл, но локальная копия осталась на диске. Затем добавить .env в .gitignore, закоммитить и запушить.
Но это только полдела. Само значение ключа все еще числится в истории репозитория, и любой, кто клонировал проект раньше, мог его увидеть. Поэтому вторым шагом всегда идет ротация: зайти к провайдеру (Stripe, база данных, любой API), сгенерировать новый ключ и обновить его в Railway. Старый ключ просто отзывается.
Для фронтенда на React есть нюанс: переменные, которые должны попасть в собранный бандл, обязаны начинаться с REACT_APP_, иначе сборщик их не подхватит и подставит пустую строку в рантайме.
Как работают Sealed Variables и в чем подвох?
Sealed Variables пишутся один раз и больше никогда не читаются обратно, даже владельцем проекта. Дашборд показывает точки вместо значения, а API отказывается его возвращать.
По тому же гайду Railway про секреты, платформа никогда не показывает значение sealed-переменной в интерфейсе и отказывается возвращать его через API, при этом сборки и рантайм получают настоящее значение. Практический эффект: скриншот дашборда в Slack больше не сливает боевой ключ Stripe случайно зашедшему в чат подрядчику.
Подвох в необратимости. Запечатывание постоянно: значение можно отредактировать через меню с тремя точками, но снять печать или открыть его в RAW Editor уже нельзя. Забыли значение, придется ротировать секрет у провайдера заново и вписывать его в Railway с нуля.
Второй подвох касается PR-окружений. Sealed-переменные не копируются в превью-деплои по пул-реквестам, при дублировании сервиса и при синхронизации диффов между окружениями. Если тестовый деплой ветки читает STRIPE_SECRET_KEY из sealed-переменной, деплой просто стартует без нее.
Практическое решение: держите отдельный тестовый ключ без запечатывания специально для PR-окружений, а sealed оставляйте только для боевых кредов, до которых превью-деплоям вообще не должно быть дела.
Как ссылаться на переменные между сервисами без копипаста?
Reference-синтаксис ${{ }} подтягивает значение из другой переменной или сервиса, вместо того чтобы хранить отдельную копию секрета в каждом месте.
Формат простой: ${{ shared.STRIPE_SECRET_KEY }} берет значение из Shared Variables, ${{ Postgres.DATABASE_URL }}читает переменную другого сервиса в том же проекте, а ${{ RAILWAY_PUBLIC_DOMAIN }} подставляет живой домен без хардкода в код.
Разработчики на Cursor или Windsurf часто вайбкодят бэкенд и фронтенд как отдельные сервисы в одном Railway-проекте. Reference Variables в этом случае избавляют от ручной синхронизации: обновил DATABASE_URL в одном месте, оба сервиса на следующем деплое получили актуальное значение.
Как ограничить доступ команды к продакшену?
В 2026 году у Railway три роли на уровне workspace: Admin с полным контролем, Member для повседневной разработки и Deployer только для запуска деплоев без доступа к переменным.
По описанию ролей в блоге Railway, Admin получает полное администрирование workspace и всех проектов, включая настройки сервисов, удаление проекта, биллинг и управление участниками. Member может делать все нужное для разработки и деплоя, но не может удалять сервисы, тома или проекты и не трогает членство в workspace и биллинг.
Третья роль, Deployer, создана специально для CI/CD и подрядчиков. Deployer может только просматривать проекты и триггерить деплои через коммиты в GitHub, но не может пользоваться CLI, менять переменные или настройки сервиса и не видит логи.
| Роль | Может менять переменные | Может деплоить | Видит логи |
|---|---|---|---|
| Admin | Да | Да | Да |
| Member | Да | Да | Да |
| Deployer | Нет | Да, через git push | Нет |
Для команд, которым мало этих трех ролей, есть Environment RBAC. Он позволяет закрыть конкретное окружение, например production, так что только выбранные Admin-ы видят его переменные, а остальные продолжают деплоить код через git push вслепую. Правда, эта функция доступна только на тарифе с committed spend, то есть небольшой команде на Hobby-плане она недоступна.
Стоит ли включать 2FA и audit logs для команды?
Да, если в проекте есть платежные данные или клиентские базы. Workspace-wide 2FA и журнал аудита закрывают ровно тот сценарий, где скомпрометированный пароль одного разработчика открывает доступ ко всем секретам сразу.
Workspace-wide 2FA enforcement позволяет Pro-администраторам workspace требовать двухфакторную аутентификацию для каждого участника, и без включенного 2FA человек упирается в стену при попытке доступа к ресурсам.
Второй уровень защиты, полезный именно для контроля переменных, это audit logs. Журнал аудита фиксирует каждое значимое событие в workspace: какие деплои прошли, какие настройки поменялись, кто добавил участника, к какому проекту и окружению это относится, кто именно внес изменение и когда. Без такого лога вопрос "кто вчера в 23:40 поменял STRIPE_WEBHOOK_SECRET" остается без ответа.
Максим: «Портал VibeCoderz мы гоняем на Railway через Dockerfile, там же лежит наш STRIPE_WEBHOOK_SECRET для оплат за размещение в каталоге. Собрали портал за неделю тремя скриптами голосом в Claude Code, и секреты сразу заводили через Shared Variables, а не по одному в каждый сервис. Дольше настраивать один раз, чем потом искать, в каком из сервисов забыли обновить ключ.»
Как защитить секрет Stripe webhook на Railway?
Webhook-секрет проверяет, что запрос на /api/webhook действительно пришел от Stripe, а не от постороннего, который угадал URL эндпоинта.
Логика простая: Stripe подписывает каждый вебхук заголовком Stripe-Signature, а сервер сверяет подпись с секретом STRIPE_WEBHOOK_SECRET. Если секрет утек, кто угодно может отправить поддельный запрос "оплата прошла" и получить бесплатный доступ к платному размещению в каталоге.
Практическая настройка на Railway: заводите STRIPE_WEBHOOK_SECRET как Sealed Variable сразу после первого сохранения, не после. Дашборд ни разу не должен показать значение открытым текстом, даже вам самим. Если секрет нужно посмотреть повторно, идите в Stripe Dashboard и сверяйте оттуда, а не пытайтесь прочитать его в Railway.
Отдельно проверьте, что PR-окружения не пытаются читать боевой webhook-секрет. Раз sealed-переменные туда не копируются, заведите тестовый вебхук-эндпоинт в Stripe с отдельным несекретным ключом специально для превью-деплоев.
Кому что выбрать: карта решений по безопасности
Выбор зависит не от размера команды, а от того, что именно вы защищаете: обычный API-ключ, платежный секрет или доступ подрядчика.
| Сценарий | Что использовать |
|---|---|
| Один ключ нужен одному сервису | Service Variable |
| Ключ переиспользуют несколько сервисов | Shared Variable + Reference |
| Платежный ключ, пароль от прод-базы | Sealed Variable |
| Подрядчик должен только деплоить код | Роль Deployer |
| Нужно закрыть production от части команды | Environment RBAC (committed spend) |
| Нужен единый лог "кто что поменял" | Audit logs |
Сильные и слабые стороны подхода Railway к секретам
Сильная сторона в том, что не нужен отдельный секрет-менеджер вроде Vault для типового вайбкодерского проекта. Четыре слоя, Service, Shared, Reference и Sealed, закрывают 90% реальных сценариев без дополнительной инфраструктуры и без строчки конфига.
Вторая сильная сторона это скорость. Обновил Shared Variable, и все сервисы подхватят значение на следующем деплое без ручного похода в каждый сервис по отдельности.
Честно про ограничения: автоматической ротации секретов по расписанию нет, короткоживущих динамических кредов тоже нет, это придется делать руками или писать свой скрипт через Public API. Environment RBAC заперт за committed spend планом, и небольшой команде на Hobby придется полагаться на дисциплину, а не на техническое ограничение доступа.
Что такое Railway environment variables и как их читать в коде
Railway передает переменные в приложение как обычные переменные окружения ОС, без своего SDK и без специального клиента.
В Node.js переменные читаются через process.env без дополнительной настройки, а пакет dotenv в продакшене можно пропустить, потому что Railway уже заполнил окружение сам. В Python то же самое делает модуль os: os.environ['DATABASE_URL'] для обязательной переменной или os.getenv('DEBUG', 'false') для опциональной с дефолтом.
Локально Railway CLI решает ту же задачу без единого файла на диске. Команда railway run npm run dev подтягивает переменные линкованного окружения и подставляет их только для этого процесса, ничего не сохраняя в файловую систему.
Глоссарий
- Service Variable это переменная окружения, привязанная к одному сервису в одном окружении Railway.
- Shared Variable это переменная уровня проекта, доступная нескольким сервисам через ссылку.
- Reference Variable это переменная, которая не хранит значение сама, а ссылается на другую через синтаксис
${{ }}. - Sealed Variable это переменная, значение которой невозможно прочитать обратно через UI или API после сохранения.
- Environment RBAC это ограничение доступа к конкретному окружению, например production, на уровне ролей.
- Webhook-секрет это строка, которой сервер проверяет подлинность входящего запроса от внешнего сервиса вроде Stripe.
- Deployer это роль в Railway, которая может только запускать деплой через git push, без доступа к переменным и логам.
Частые вопросы про безопасность Railway
Можно ли посмотреть значение Sealed Variable после сохранения?
Нет. Дашборд Railway показывает точки вместо значения, а API отказывается его возвращать. Если значение забыто, остается только сгенерировать новый секрет у провайдера и вписать заново.
Попадают ли Shared Variables в GitHub при пуше .env файла?
Нет, если переменная заведена через Shared Variables в Railway, а не хранится в самом .env файле репозитория. Значение живет только на стороне платформы и подставляется в рантайм отдельно от кода.
Чем Deployer отличается от Member?
Deployer может только просматривать проект и запускать деплой через коммит в GitHub. Member дополнительно может менять переменные, создавать сервисы и тома, но не может удалять проект или управлять биллингом.
Нужен ли отдельный секрет-менеджер вроде Vault при работе с Railway?
Для типового проекта на вайбкодинге нет. Sealed Variables закрывают сценарий "секрет нельзя прочитать даже владельцу", а Reference Variables убирают дублирование. Отдельный менеджер нужен только при автоматической ротации по расписанию или коротко живущих динамических кредах.
Как быстро включить 2FA для всей команды?
На Pro-тарифе workspace admin включает workspace-wide 2FA enforcement в настройках workspace. После включения участники без 2FA не теряют доступ полностью, но не могут работать с ресурсами workspace, пока не подключат двухфакторную аутентификацию.
Что использовать для переменных фронтенда на React?
Переменные, которые должны попасть в собранный бандл, называйте с префиксом REACT_APP_. Без префикса сборщик их просто не подхватит при сборке, и в рантайме окажется пустая строка вместо значения.
Стоит ли использовать Environment RBAC для маленькой команды из трех человек?
Не обязательно. Функция требует committed spend плана, а для команды из трех человек хватает роли Member для разработчиков и Admin для того, кто отвечает за прод, плюс дисциплина с Sealed Variables на платежных ключах.
Если вы собираете сервисы для вайбкодинга в Cursor, Windsurf или Claude Code и деплоите их на Railway, разница между Service и Sealed Variable решает, останется ли платежный ключ приватным. Сравнение других IDE и инструментов для деплоя смотрите в каталоге AI-инструментов VibeCoderz, а тем, кто настраивает инфраструктуру для команды, может пригодиться подборка в агентах для devops.
Если нужен разбор конкретно вашей связки Railway + Stripe + команда, запишитесь на консультацию к Максиму: t.me/maxnagovitsyn.
Обновлено: июль 2026.