Если что-то не работает
Как задать переменные окружения без файла .env
Коротко
Переменные окружения задаются без файла .env: код читает их из окружения — в Python через os.environ, в Node.js через process.env, — а заполняет окружение та площадка, где приложение работает. Файл .env нужен только на своём компьютере: библиотеки вроде python-dotenv просто читают его и раскладывают значения по тем же самым переменным. В Netrun значения спрашивают при настройке проекта и хранят зашифрованными, поэтому никакого .env на сервере нет, а поменять ключ можно, не трогая код.
Файл .env хорош ровно до того момента, пока проект живёт на вашем компьютере: одна строка на ключ, всё под рукой, ничего не забыто. В бою этот же файл начинает вредить. Он уезжает вместе с архивом или с папкой на GitHub и уносит с собой токены; его забывают обновить, и на сервере остаётся ключ, который вы поменяли месяц назад; а когда файла просто нет рядом с кодом, приложение падает с невнятной ошибкой про пустое значение. Отсюда и обычный вопрос: как передать переменные окружения на сервер без .env.
Хорошая новость в том, что коду файл не нужен. Библиотеки чтения .env не делают ничего особенного: они открывают файл и раскладывают его содержимое по обычным переменным окружения — тем самым, из которых код и читает значения. Обычно на сервере этот файл создают руками через терминал и потом боятся его тронуть. В Netrun значения спрашивают при настройке проекта, хранят зашифрованными и подставляют в окружение при запуске: файла нет, а код работает так же.
Читайте значения из окружения, а не из файла#
Код не должен знать, откуда пришло значение. В Python берите его через os.environ или os.getenv, в Node.js — через process.env, в Go — через os.Getenv; в любом языке есть такая же функция. Тогда одно и то же приложение работает и у вас на машине, где переменные подставит .env, и на сервере, где их заполнит площадка.
Уберите .env из архива и из папки на GitHub#
Добавьте строку .env в файл .gitignore, чтобы он не уезжал в репозиторий, и проверьте, что его нет в ZIP-архиве, который вы загружаете. Это самый частый путь утечки: файл лежит внутри папки с кодом и путешествует вместе с ней. Заодно перестанет существовать вторая типовая беда — забытый .env на сервере со старым ключом.
Оставьте .env.example со списком имён#
Рядом с кодом держите файл .env.example, в котором перечислены только имена переменных, без значений. Он спокойно лежит в репозитории и отвечает на вопрос, что именно нужно проекту, чтобы запуститься. Через полгода этот список пригодится вам самим, а не только тем, кому вы отдадите код.
Задайте значения при настройке проекта и меняйте их там же#
Когда вы загружаете код в Netrun, платформа смотрит, какие переменные проект ожидает, и спрашивает значения прямо в форме: токен бота, ключ к сервису, строку подключения к базе. Они хранятся в зашифрованном виде и подставляются в окружение при запуске. Поменять значение можно в любой момент в кабинете: вписали новое, сохранили — проект перезапустится уже с ним, код при этом не меняется и заново загружать архив не нужно.
Перевыпустите ключ, который уже попал в репозиторий#
Если .env или ключ прямо в коде хоть раз уехал на GitHub, считайте его скомпрометированным, даже если репозиторий приватный. Удалить файл и сделать новый коммит недостаточно: старое значение остаётся в истории, и его видно всем, у кого есть доступ к папке с кодом. Действие тут одно — отозвать ключ в сервисе, который его выдал, выпустить новый и вписать его в секреты проекта.
Не считайте секретом то, что попадает в собранный сайт#
Переменные, которые сборщик фронтенда подставляет в код при сборке — с префиксами вроде VITE_, NEXT_PUBLIC_ или REACT_APP_, — попадают в готовые файлы сайта и видны любому посетителю через инструменты разработчика в браузере. Туда можно класть адрес вашего API или заведомо публичный ключ, но не ключ платного сервиса и не пароль к базе. Всё, что должно остаться тайной, читает и использует серверная часть, а фронтенд обращается к ней.
Итог простой: .env остаётся вашим локальным удобством, а на сервере значения живут отдельно от кода: их видно и можно поменять в одном месте, они не уезжают вместе с архивом и не теряются при обновлении. Если после этого приложение всё равно не видит переменную, причина обычно не в хостинге: либо имя написано иначе, чем в коде, либо код по-прежнему читает файл, а не окружение. Это чинится в самом проекте и одинаково работает на любой площадке.
Когда возиться с переносом ключей руками не хочется, значения можно просто вписать при настройке проекта: платформа сама подставит их в окружение при запуске, без терминала и файлов на сервере. Попробовать Netrun.
Частые вопросы
Нужно ли класть файл .env в архив с кодом?
Нет, и лучше этого не делать. Значения задаются при настройке проекта и подставляются в переменные окружения при запуске, а файл в архиве только повышает шанс, что ключ утечёт вместе с папкой. Если .env всё-таки попал в архив, считайте лежащие в нём ключи скомпрометированными и выпустите новые.
Почему приложение не видит переменную окружения?
Чаще всего дело в имени: регистр важен, и API_KEY и Api_Key — это разные переменные. Вторая причина — код читает значение не из окружения, а из файла, которого рядом нет. Третья — значение добавили уже после запуска: чтобы оно применилось, нужна новая публикация или перезапуск. Что именно пошло не так, видно в логах проекта в кабинете.
Что делать, если ключ уже попал в GitHub?
Считать его скомпрометированным и выпустить новый в том сервисе, который его выдал. Удаление файла и новый коммит историю не чистят: старое значение остаётся в предыдущих версиях и доступно всем, у кого есть доступ к папке с кодом. Приватность репозитория тут не спасает — доступ мог быть у соавторов, а сам репозиторий когда-то мог быть открытым.
Как поменять значение переменной, не перезаливая код?
Откройте проект в кабинете, впишите новое значение в настройках и сохраните — проект пересоберётся и запустится уже с ним. Код и архив трогать не нужно, ссылка проекта остаётся прежней. Так же удобно переключать тестовый ключ на боевой.
Секретны ли переменные с префиксом VITE_ или NEXT_PUBLIC_?
Нет. Такие переменные сборщик подставляет прямо в файлы сайта, которые скачивает браузер, поэтому их значение видит любой посетитель. Это нормально для адреса API или публичного идентификатора, но ключ платного сервиса или доступ к базе так класть нельзя — их должна использовать серверная часть.
Можно ли хранить в переменных окружения строку подключения к базе?
Да, это обычная практика: приложение читает адрес базы, логин и пароль из окружения и подставляет их при подключении. В Netrun строку подключения спросят при настройке проекта и сохранят зашифрованной. Если база поднимается рядом в том же проекте вашим docker-compose, адрес соседнего сервиса тоже задаётся переменной, а не пишется в коде.
Где указать токены и другие секретные значения?
В проекте есть вкладка «Секреты» — там задаются значения из кода, например токен от BotFather. Мы храним их в зашифрованном виде: названия переменных вы видите, сами значения не показываем никому, включая вас.
Безопасны ли мои токены и секреты?
Да. Токены, ключи доступа и значения из кода хранятся в зашифрованном виде и не показываются в открытом виде.
Как обновить код уже опубликованного проекта?
Откройте проект и загрузите новую версию или обновите его из GitHub. Ссылка останется прежней, а данные сохранятся, если лежат в постоянном хранилище — папке /data или томе вашего compose-файла.