<p>Three months ago a friend of mine onboarded a contractor.</p> <p>He DM'd him the <code>.env</code>. Standard practice. Two days later the contractor pushed a debug log to a public repo with one of the keys still in it.</p> <p>They rotated. Customers didn't notice. But that file is still in his Slack archive. It's still in the contractor's Slack archive. It's still cached on two computers. It will still be there in five years.</p> <p>That's the <code>.env</code> problem. Most teams "solve" it the same way:</p> <ul> <li>Slack DM (plaintext forever, in two chat archives)</li> <li>Notion page (whoever can read the page can read prod)</li> <li>1Password vault item (works, but now you have a second ACL to maintain)</li> <li> <code>.env.example</code> with fake values (drifts in 48 hours)</li> <li>"I'll send it to you on Signal" (still plaintext on two phones)</li> </ul> <p>I tried the existing tools. <strong>Doppler</strong> is great if you're 50 people with a budget — $21/user/mo and a sales call. <strong>Infisical</strong> is open-source but feels Kubernetes-shaped, built for DevOps teams. <strong>dotenvx</strong> is sharp and the encryption-in-git story is clever, but you still have to share the encryption key out of band, and there's no team-revocation story.</p> <p>What I actually wanted: zero new accounts, zero new ACLs. <strong>If GitHub already says you can push to the repo, you should be able to pull the env.</strong></p> <p>So I built <code>boltenv</code>.</p> <h2> The pitch in one sentence </h2> <blockquote> <p><strong>Revoke a teammate's GitHub access. They lose env access. Done.</strong></p> </blockquote> <p>That's the whole thing. GitHub repo permissions are the access list. There's no parallel user system to keep in sync.</p> <h2> What the workflow looks like </h2> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code><span class="c"># You: push your .env (encrypted on YOUR machine, only ciphertext leaves)</span> <span class="nv">$ </span>npm i <span class="nt">-g</span> @boltenv.dev/cli <span class="nv">$ </span>boltenv push ⚡ .env → org/app:development v1 <span class="o">(</span>12 vars, permanent<span class="o">)</span> <span class="c"># Teammate: pull it</span> <span class="nv">$ </span>boltenv pull ⚡ .env ← org/app:development <span class="o">(</span>12 vars<span class="o">)</span> </code></pre> </div> <p>That's it. No invites. No ACL panel. No "create a project."</p> <p>The first push generates an AES-256 key locally. The server only ever sees ciphertext. You share the key with your teammate once via secure channel:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code><span class="c"># You</span> <span class="nv">$ </span>boltenv key <span class="nb">export </span>dGhpcyBpcyBhIDMyIGJ5dGUga2V5... <span class="c"># Teammate</span> <span class="nv">$ </span>boltenv key import dGhpcyBpcyBhIDMyIGJ5dGUga2V5... </code></pre> </div> <p>After that, your teammate just runs <code>boltenv pull</code> from any machine. They authenticate to GitHub once via Device Flow — same UX as <code>gh auth login</code>.</p> <h2> How it actually works </h2> <p>Three layers, each independently breakable so the system fails closed:</p> <h3> 1. Authorization gate </h3> <p>Server calls <code>GET https://api.github.com/repos/{owner}/{repo}</code> with the user's GitHub token. Reads <code>permissions.push</code>. Read-only or no access → request rejected before any data moves. The server has no idea who's "on the team." It asks GitHub.</p> <h3> 2. Encryption gate </h3> <ul> <li>AES-256-GCM (NIST standard)</li> <li>Key derivation: HKDF-SHA256, separate subkeys for encryption and HMAC</li> <li>IV: 12 bytes, random per push</li> <li>Auth tag: 16 bytes (tamper detection)</li> <li>Master key never leaves your laptop. Stored at <code>~/.boltenv/keys/{owner}/{repo}.key</code> with mode <code>0600</code>.</li> <li>Server stores ciphertext + a 16-char key fingerprint so mismatched keys are caught early instead of producing garbled output.</li> </ul> <h3> 3. Branch-aware environments </h3> <div class="highlight js-code-highlight"> <pre class="highlight conf"><code><span class="n">main</span>, <span class="n">master</span> → <span class="n">production</span> <span class="n">staging</span> → <span class="n">staging</span> <span class="n">develop</span> → <span class="n">development</span> <span class="n">anything</span> <span class="n">else</span> → <span class="n">development</span> </code></pre> </div> <p>The branch you're on determines what you push or pull. Override with <code>-e production</code> if you need to. No "which environment is this dropdown set to" footgun.</p> <h2> Why "GitHub permissions = ACL" matters </h2> <p>Think about what happens today when someone leaves your team:</p> <ul> <li>✅ You remove them from GitHub.</li> <li>❌ You remove them from your Doppler / Infisical / Vault. (manual, often forgotten)</li> <li>❌ You rotate every secret they had access to. (rarely happens)</li> <li>❌ Their <code>.env</code> files in <code>~/projects/*</code> are now museum pieces of your prod stack.</li> </ul> <p>With boltenv, <strong>step 1 is the whole list.</strong> You revoke GitHub access — they can't pull anymore. Their cached <code>.env</code> on disk is still there, sure (no tool can fix that), but they can't get a fresh one and they can't push poison.</p> <p>This isn't a perfect security model. It's a pragmatic one for small teams. If you're handling HIPAA data, go use Vault. If you're five people shipping a SaaS, this is the right level of control.</p> <h2> How it stacks up </h2> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Tool</th> <th>Per-user cost</th> <th>New accounts?</th> <th>Encryption</th> <th>ACL source</th> </tr> </thead> <tbody> <tr> <td><strong>Slack DMs</strong></td> <td>Free</td> <td>None</td> <td>None</td> <td>"I trust you"</td> </tr> <tr> <td><strong>dotenvx</strong></td> <td>Free</td> <td>None</td> <td>AES-256 in git</td> <td>Manual key sharing</td> </tr> <tr> <td><strong>Doppler</strong></td> <td>$21/mo</td> <td>Yes</td> <td>Server-managed</td> <td>Doppler users</td> </tr> <tr> <td><strong>Infisical</strong></td> <td>$8/mo</td> <td>Yes</td> <td>Server-managed</td> <td>Infisical users</td> </tr> <tr> <td><strong>1Password Dev</strong></td> <td>$7.99/mo bundled</td> <td>Yes</td> <td>1P-managed</td> <td>1Password users</td> </tr> <tr> <td><strong>boltenv</strong></td> <td>Free for ≤3, then $4/mo</td> <td><strong>None</strong></td> <td>Client-side AES-256-GCM</td> <td><strong>GitHub repo permissions</strong></td> </tr> </tbody> </table></div> <p>The lane I'm aiming for is narrow but real: small teams who don't want a heavyweight platform, don't want to share keys out of band forever, and do want one ACL.</p> <h2> CI/CD works without a service account </h2> <p>Two env vars on the box, no SDK to install:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code><span class="nb">export </span><span class="nv">BOLTENV_TOKEN</span><span class="o">=</span><span class="nv">$GITHUB_TOKEN</span> <span class="c"># any PAT with repo scope</span> <span class="nb">export </span><span class="nv">BOLTENV_KEY</span><span class="o">=</span>&lt;base64-from-export&gt; boltenv pull <span class="nt">-y</span> </code></pre> </div> <p><code>BOLTENV_TOKEN</code> works with <code>secrets.GITHUB_TOKEN</code> in GitHub Actions. <code>BOLTENV_KEY</code> is the master key, stored as a single repo secret. The binary is the SDK.</p> <p>A typical Actions step:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight yaml"><code><span class="pi">-</span> <span class="na">name</span><span class="pi">:</span> <span class="s">Pull env</span> <span class="na">env</span><span class="pi">:</span> <span class="na">BOLTENV_TOKEN</span><span class="pi">:</span> <span class="s">${{ secrets.GITHUB_TOKEN }}</span> <span class="na">BOLTENV_KEY</span><span class="pi">:</span> <span class="s">${{ secrets.BOLTENV_KEY }}</span> <span class="na">run</span><span class="pi">:</span> <span class="pi">|</span> <span class="s">npm i -g @boltenv.dev/cli</span> <span class="s">boltenv pull -e production -y</span> </code></pre> </div> <h2> Multi-file projects </h2> <p>Most real projects have more than one env file: <code>.env.backend</code>, <code>.env.frontend</code>, <code>.env.workers</code>. boltenv discovers them automatically:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code><span class="nv">$ </span>boltenv push ⚡ Found 3 <span class="nb">env </span>files: .env.backend 18 vars .env.frontend 9 vars .env.workers 6 vars 3 files → org/app:development <span class="o">(</span>permanent<span class="o">)</span> </code></pre> </div> <p>Pull preserves the layout. Save the file list to <code>.boltenv.yaml</code> and commit it — your teammates pull the same set without configuration drift.</p> <h2> What it doesn't do </h2> <p>I'd rather be honest about scope.</p> <ul> <li> <strong>No org-level RBAC.</strong> Your repo permissions are the rules.</li> <li> <strong>No automated key rotation.</strong> Rotating means everyone re-imports.</li> <li> <strong>No HSM, no compliance certifications.</strong> This is a pre-SOC2 product.</li> <li> <strong>No native Coolify / Railway / Vercel sync yet.</strong> On the roadmap. Today: <code>boltenv pull --stdout --format dotenv</code> and paste, or run boltenv on the VPS itself with the env-var auth above.</li> </ul> <p>If any of those are deal-breakers — you're not the user, and that's fine.</p> <h2> Try it </h2> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>npm i <span class="nt">-g</span> @boltenv.dev/cli <span class="nb">cd </span>your-project boltenv push </code></pre> </div> <ul> <li>Repo: <a href="https://github.com/boltenv/boltenv" rel="noopener noreferrer">github.com/boltenv/boltenv</a> </li> <li>Site: <a href="https://boltenv.dev" rel="noopener noreferrer">boltenv.dev</a> </li> <li>License: FSL-1.1-MIT (free for everyone, including commercial use, with non-compete)</li> </ul> <p>I'd love to hear what breaks for you. Comment, file an issue, or DM me. I read every one.</p> <p>If this saved you from one Slack-DM'd <code>.env</code>, that's the entire goal.</p>