PAS7 Studio
До всіх статей

git-env-vault для монорепозиторіїв: зашифровані .env-файли в Git

Практичний гід по git-env-vault для монорепозиторіїв: як секрети залишаються зашифрованими в Git, як розробники отримують локальні .env-файли та де в цьому процесі використовуються SOPS, age і CI.

Кому підійдеПлатформні інженериDevOps-інженериFull-stack команди, які працюють із монорепозиторіямиТехліди, які наводять лад у процесах роботи із секретами
Редакційна обкладинка із зашифрованими секретами в Git, локальними env-файлами для окремих сервісів і монорепозиторним процесом навколо git-env-vault

Головна суть не лише в тому, що секрети зашифровані. Репозиторій також отримує чистіший і зрозуміліший процес роботи навколо них.

Зашифровані файли секретів зберігаються в Git замість того, щоб передавати plaintext .env-файли вручну. [1][3]
Розробники все одно отримують локальні .env-файли саме там, де їх очікує кожен сервіс. [1][3]
Інструмент має легший шлях для онбордингу й pull та повніший адміністративний шлях для редагування й змін доступу. [1][2][4]
Локальні значення, наприклад токени ботів, можуть залишатися локальними, а не перезаписуватися чи потрапляти в спільний зашифрований стан. [1][3][4]
CI може або перевіряти стан репозиторію, або отримувати зашифрований payload, коли джобі справді потрібен dotenv-файл. [2][4][5]

git-env-vault — це CLI і TUI на Node.js для роботи із зашифрованими .env-секретами в монорепозиторіях. У самому репозиторії інструмент описано доволі прямо: зашифровані файли секретів у Git, SOPS + age під капотом і локальні та CI-сценарії роботи поверх цього. [1]

Це не hosted secret manager. Тут модель прив’язана до репозиторію. Файли секретів залишаються зашифрованими в Git, мапа сервісів визначає, куди потрапляють розшифровані локальні файли, а CLI бере на себе pull, diff, push, зміни доступу та перевірки в CI. [1][2][3][4]

Інструмент можна встановити локально, глобально або запускати через npx чи bunx, що знижує поріг входу для першого pull. [1][2]

Просте визначення

Він поєднує зашифровані секрети в репозиторії з локальними .env-файлами, які все ще потрібні кожному сервісу. [1][3]

Зручніше сприймати систему як кілька окремих файлів, у кожного з яких своя роль.

01

Зашифровані секрети лежать у secrets/

У документації з конфігурації показано структуру на кшталт secrets/<env>/<service>.sops.yaml. Ці файли залишаються зашифрованими всередині репозиторію. [3]

02

envvault.policy.json керує списком отримувачів

Цей файл визначає, хто може розшифрувати конкретне середовище або сервіс. У документації також радять тримати список recipients невеликим і розділяти CI-ключі та людські ключі. [3][5]

03

envvault.config.json мапить сервіси на локальні вихідні файли

Кожен сервіс вказує envOutput, наприклад apps/api/.env, тож локальні розшифровані файли потрапляють саме туди, де їх реально потребує монорепозиторій. [3]

04

CLI пов’язує цю модель із щоденною роботою

Команди на кшталт pull, diff, status, push, refresh і ci-verify — це практичний інтерфейс усієї схеми. [1][2][4]

Що варто пам’ятати

Зберігання, доступ, локальні вихідні файли та процес роботи — це різні задачі. Інструмент просто тримає їх узгодженими між собою. [1][2][3][4]

Це перша межа, яку варто зрозуміти: вона спрощує онбординг і не вдає, ніби кожній машині з першого дня потрібен повний адміністративний стек.

Comparison pointEasy modeFull mode
Що використовуєJS decrypt fallback, зазвичай через cryptoBackend: "auto"Локально встановлені sops + age
Найкраще підходить дляЛокального pull і read-oriented онбордингуРедагування, grant, revoke, updatekeys, rotate і push
Чого не намагається робитиНе замінює system SOPS для спільного write та задач керування ключамиЦе очікуваний шлях, коли потрібно змінити спільний зашифрований стан або список recipients

Просте правило

Використовуйте easy mode, щоб почати локальну роботу. Використовуйте full mode, коли потрібно змінити спільні зашифровані дані або доступ до них. [1][2][4]

Типовий шлях короткий, і саме тому його легше впровадити в команді.

01

Підтягнути локальні секрети

Почніть з git pull і envvault pull --env dev. У документації з workflow також є pull для конкретного сервісу й pull за патернами для більших репозиторіїв. [1][4]

02

Переглянути відмінності

Використовуйте envvault diff --env dev --service api і envvault pull --env dev --service api --confirm, коли потрібен безпечніший шлях оновлення. CLI також підтримує --plan і --json для попереднього перегляду без запису. [2][4]

03

Перевірити розходження

envvault status --env dev показує, що саме розійшлося між локальними файлами та станом vault. [1][2][4]

04

Записати назад свідомо

push підтримує --dry-run і --confirm, і залишається на повному шляху через SOPS. Це робить запис назад у shared state більш навмисним, ніж випадкове редагування локального файла. [1][2][4]

Що змінюється

Замість туманної суміші зі старих локальних файлів і ручного обміну dotenv команда отримує зрозумілий ланцюжок: pull, diff, status і push, коли це справді потрібно. [1][2][4]

Це одна з найпрактичніших частин інструмента, особливо в репозиторіях із ботами, локальними токенами або обліковими даними, прив’язаними до конкретного розробника.

Короткий приклад конфігурації з документації добре показує ідею:

JSON
{
  "placeholderPolicy": {
    "preserveExistingOnPlaceholder": true,
    "patterns": ["__MISSING__", "CHANGEME*", "*PLACEHOLDER*"]
  },
  "localProtection": {
    "global": ["BOT_TOKEN"],
    "services": {
      "api": ["TELEGRAM_BOT_TOKEN"]
    }
  },
  "services": {
    "api": { "envOutput": "apps/api/.env" },
    "worker": { "envOutput": "apps/worker/.env" }
  }
}

localProtection зберігає вибрані локальні ключі

Якщо ключ захищений, pull залишає локальне значення, а push не записує його у спільний зашифрований секрет. У документації прямо згадуються ключі на кшталт BOT_TOKEN і TELEGRAM_BOT_TOKEN. [1][3][4]

Placeholder-safe pull допомагає уникнути безглуздих поломок

Якщо валідація схеми генерує placeholder на кшталт __MISSING__, pull може зберегти наявне локальне непорожнє значення замість того, щоб замінити його. [1][3][4]

Для зворотного випадку існує promotion

Коли локальний override має стати спільним зашифрованим станом, CLI містить promote і promote-all, а не залишає цей крок на copy-paste звички. [2][3]

Чому це важливо командам

Багато проблем із dotenv починаються там, де локальні значення перезаписуються або випадково потрапляють у спільний стан. Ця частина процесу працює саме проти цього. [1][3][4]

У документації CI розділено на verification і payload delivery, тому що це справді різні задачі.

Використовуйте ci-verify

Найкраще підходить, коли CI має перевіряти policy, узгодженість .sops.yaml, структуру зашифрованих секретів, помилки з plaintext .env і dirty .env* state у Git. [2][4][5]

Використовуйте ci-seal і ci-unseal

Найкраще підходить, коли джобі справді потрібен зашифрований dotenv payload. Задокументований flow використовує окремий CI key і CI blob, який розшифровується всередині pipeline. [1][2][4]

Тримайте CI-ключі окремо

Configuration docs і security docs рекомендують окремі ключі для CI та людей. Так межі доступу залишаються простішими для розуміння. [3][5]

Коротко

ci-verify захищає стан репозиторію. ci-seal і ci-unseal відповідають за доставку секретів у runtime, коли джобі це справді потрібно. [2][4][5]

Інструментом легше користуватися правильно, коли його межі зрозумілі.

Сприймати його як hosted secret platform, а не як repo-native workflow із зашифрованими файлами. [1][3][5]

Забувати, що JS fallback насамперед потрібен для decrypt-oriented онбордингу, а не для write, rotation чи змін recipients. [1][2][4]

Давати занадто багатьом людям доступ до занадто багатьох середовищ замість того, щоб тримати список recipients вузьким. [3][5]

Ігнорувати .gitignore hygiene і CI checks, поки в репозиторії не з’являться plaintext-файли. [3][4][5]

Відкликати доступ без подальшої ротації в чутливих випадках. У документації прямо вказано на revoke plus rotate. [3][4][5]

Поводитися так, ніби шифрування прибирає endpoint risk. Приватні age keys і машини розробників усе ще мають значення. [5][6][7]

Реалістичне очікування

git-env-vault робить процес безпечнішим і зрозумілішим, але він усе одно залежить від гігієни ключів, review і дисциплінованого offboarding. [3][5][6][7]

Ці джерела підтверджують поведінку команд, модель конфігурації та рекомендації з безпеки, використані в цій статті.

Перевірено: 12 бер. 2026 р.Актуально для: середовища з Node.js 18+Актуально для: монорепозиторії з кількома сервісамиАктуально для: команди, які використовують SOPS + age для зашифрованих секретів у Git

Найскладніша частина зазвичай не в самому шифруванні. Вона в усьому навколо: local overrides, зміни доступу, перевірки в CI та гігієна репозиторію.

PAS7 Studio може допомогти оформити це у чистіший setup із чіткішими межами сервісів, безпечнішими дефолтами й меншою кількістю місць, де виростає drift секретів.

Пов'язані статті

growth

AI SEO / GEO у 2026: ваші наступні клієнти — не люди, а агенти

Пошук зміщується від кліків до відповідей. Боти та AI-агенти сканують, цитують, рекомендують і дедалі частіше купують. Дізнайтесь, що таке AI SEO / GEO, чому класичного SEO вже недостатньо, і як PAS7 Studio допомагає брендам перемагати у «агентному» вебі.

blogs

Найпотужніший чіп від Apple? M5 Pro і M5 Max б'ють рекорди

Аналітичний розбір Apple M5 Pro і M5 Max станом на березень 2026 року. Пояснюємо, чому ці чіпи можна вважати найпотужнішими професійними ноутбучними SoC від Apple, як вони виглядають на тлі M4 Pro, M4 Max, M1 Pro, M1 Max і що показують у порівнянні з актуальними Intel та AMD.

telegram-media-saver

Автоматичне тегування та пошук збережених посилань

Інтеграція з GDrive/S3/Notion для автоматичного тегування та швидкого пошуку через пошукові API

services

Розробка Telegram-ботів та автоматизація

Професійна розробка Telegram-ботів та автоматизація бізнес-процесів: чат-боти, AI-асистенти, інтеграції з CRM та автоматизація процесів.

Професійна розробка для вашого бізнесу

Створюємо сучасні веб-рішення та боти для бізнесу. Дізнайтеся, як ми можемо допомогти вам досягти цілей.