Восемь лет на Laravel, месяц на Rails. Там всё жило в .env: на сервере свой файл, в репозитории .env.example. Здесь вижу credentials.yml.enc и master.key и не понимаю, как это живёт на проде и в команде. И коллега уже успел закоммитить master.key в ветку, пока я разбирался. Rails 7.0.
Начну с ветки. Раз master.key попал в историю, считайте его скомпрометированным: удалить коммит мало, ветку могли уже склонировать. Пересоздайте ключ: расшифруйте старый файл, сохраните содержимое, удалите credentials.yml.enc и master.key, запустите bin/rails credentials:edit, он создаст новую пару, и вставьте содержимое обратно. Все секреты, которые были внутри, тоже поменяйте. Дальше схема такая: зашифрованный файл лежит в репозитории, ключ на сервер приходит переменной RAILS_MASTER_KEY, у разработчиков он лежит локально, в .gitignore он уже есть по умолчанию. Для окружений можно отдельные файлы:
bin/rails credentials:edit --environment production
# создаст config/credentials/production.yml.enc и production.keyВорчу каждый раз, но ключи в репозитории самая частая беда, которую я вижу.
В коде потом Rails.application.credentials.dig(:payments, :api_key). Ключи, без которых приложение не должно работать, читайте в инициалайзере через fetch: тогда оно упадёт при старте, а не на первом платеже. И .env никто не запрещает, dotenv-rails живёт отлично, если команде так привычнее.
У клиентов на старых проектах dotenv до сих пор сплошь и рядом, на 4.2 credentials ещё не было. Так что пригодится знать оба варианта