Stop Slacking your secrets. Use GitHub instead.

Three months ago a friend of mine onboarded a contractor.

He DM'd him the .env. Standard practice. Two days later the contractor pushed a debug log to a public repo with one of the keys still in it.

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.

That's the .env problem. Most teams "solve" it the same way:

• Slack DM (plaintext forever, in two chat archives)
• Notion page (whoever can read the page can read prod)
• 1Password vault item (works, but now you have a second ACL to maintain)
• .env.example with fake values (drifts in 48 hours)
• "I'll send it to you on Signal" (still plaintext on two phones)

I tried the existing tools. Doppler is great if you're 50 people with a budget — $21/user/mo and a sales call. Infisical is open-source but feels Kubernetes-shaped, built for DevOps teams. dotenvx 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.

What I actually wanted: zero new accounts, zero new ACLs. If GitHub already says you can push to the repo, you should be able to pull the env.

So I built boltenv.

The pitch in one sentence

Revoke a teammate's GitHub access. They lose env access. Done.

That's the whole thing. GitHub repo permissions are the access list. There's no parallel user system to keep in sync.

What the workflow looks like

# You: push your .env (encrypted on YOUR machine, only ciphertext leaves)
$ npm i -g @boltenv.dev/cli
$ boltenv push
  ⚡ .env → org/app:development v1 (12 vars, permanent)

# Teammate: pull it
$ boltenv pull
  ⚡ .env ← org/app:development (12 vars)

That's it. No invites. No ACL panel. No "create a project."

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:

# You
$ boltenv key export
dGhpcyBpcyBhIDMyIGJ5dGUga2V5...

# Teammate
$ boltenv key import dGhpcyBpcyBhIDMyIGJ5dGUga2V5...

After that, your teammate just runs boltenv pull from any machine. They authenticate to GitHub once via Device Flow — same UX as gh auth login.

How it actually works

Three layers, each independently breakable so the system fails closed:

1. Authorization gate

Server calls GET https://api.github.com/repos/{owner}/{repo} with the user's GitHub token. Reads permissions.push. Read-only or no access → request rejected before any data moves. The server has no idea who's "on the team." It asks GitHub.

2. Encryption gate

• AES-256-GCM (NIST standard)
• Key derivation: HKDF-SHA256, separate subkeys for encryption and HMAC
• IV: 12 bytes, random per push
• Auth tag: 16 bytes (tamper detection)
• Master key never leaves your laptop. Stored at ~/.boltenv/keys/{owner}/{repo}.key with mode 0600.
• Server stores ciphertext + a 16-char key fingerprint so mismatched keys are caught early instead of producing garbled output.

3. Branch-aware environments

main, master  → production
staging       → staging
develop       → development
anything else → development

The branch you're on determines what you push or pull. Override with -e production if you need to. No "which environment is this dropdown set to" footgun.

Why "GitHub permissions = ACL" matters

Think about what happens today when someone leaves your team:

• ✅ You remove them from GitHub.
• ❌ You remove them from your Doppler / Infisical / Vault. (manual, often forgotten)
• ❌ You rotate every secret they had access to. (rarely happens)
• ❌ Their .env files in ~/projects/* are now museum pieces of your prod stack.

With boltenv, step 1 is the whole list. You revoke GitHub access — they can't pull anymore. Their cached .env 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.

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.

How it stacks up

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.

CI/CD works without a service account

Two env vars on the box, no SDK to install:

export BOLTENV_TOKEN=$GITHUB_TOKEN     # any PAT with repo scope
export BOLTENV_KEY=<base64-from-export>
boltenv pull -y

BOLTENV_TOKEN works with secrets.GITHUB_TOKEN in GitHub Actions. BOLTENV_KEY is the master key, stored as a single repo secret. The binary is the SDK.

A typical Actions step:

- name: Pull env
  env:
    BOLTENV_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    BOLTENV_KEY:   ${{ secrets.BOLTENV_KEY }}
  run: |
    npm i -g @boltenv.dev/cli
    boltenv pull -e production -y

Multi-file projects

Most real projects have more than one env file: .env.backend, .env.frontend, .env.workers. boltenv discovers them automatically:

$ boltenv push
  ⚡ Found 3 env files:
     .env.backend         18 vars
     .env.frontend        9 vars
     .env.workers         6 vars

  3 files → org/app:development (permanent)

Pull preserves the layout. Save the file list to .boltenv.yaml and commit it — your teammates pull the same set without configuration drift.

What it doesn't do

I'd rather be honest about scope.

• No org-level RBAC. Your repo permissions are the rules.
• No automated key rotation. Rotating means everyone re-imports.
• No HSM, no compliance certifications. This is a pre-SOC2 product.
• No native Coolify / Railway / Vercel sync yet. On the roadmap. Today: boltenv pull --stdout --format dotenv and paste, or run boltenv on the VPS itself with the env-var auth above.

If any of those are deal-breakers — you're not the user, and that's fine.

Try it

npm i -g @boltenv.dev/cli
cd your-project
boltenv push

• Repo: github.com/boltenv/boltenv
• Site: boltenv.dev
• License: FSL-1.1-MIT (free for everyone, including commercial use, with non-compete)

I'd love to hear what breaks for you. Comment, file an issue, or DM me. I read every one.

If this saved you from one Slack-DM'd .env, that's the entire goal.