The pitch in one sentence

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

GitHub repo permissions are your secrets ACL. No new accounts. No new ACLs to keep in sync. No keys to Slack around.

Install

npm i -g @boltenv.dev/cli

Or via curl:

curl -fsSL https://boltenv.dev/install | sh

Requires Node.js 22+.

60-second start

# 1. From inside any GitHub repo
$ boltenv login          # opens GitHub Device Flow

# 2. Push your .env (encrypted on YOUR machine, only ciphertext leaves)
$ boltenv push
  ⚡ .env → org/app:development v1 (12 vars, permanent)
  ⚡ Encryption key stored on boltenv
    Teammates with GitHub repo access can pull without any setup.

# 3. Teammate on a different machine — no key paste, no Slack
$ boltenv pull
  ⚡ Loaded encryption key from boltenv (fp: 51a34..., by alice)
  ⚡ .env ← org/app:development (12 vars)

That's it. No accounts, no invites, no separate ACL panel.

How it works

  Your machine                    boltenv.dev                    Teammate's machine
  ┌──────────┐                   ┌──────────────┐               ┌──────────────┐
  │ .env     │── AES-256-GCM ───►│  Encrypted    │── Decrypt ──►│ .env         │
  │ (secrets)│   on YOUR         │  blob + key   │   on theirs  │ (secrets)    │
  └──────────┘   machine         └──────────────┘               └──────────────┘
                                       │
                                       ▼
                              GitHub permissions check
                              every push/pull

1. Push — CLI encrypts your .env locally with AES-256-GCM. Server stores ciphertext + a wrapped copy of the encryption key.
2. Pull — Server checks permissions.push on the GitHub repo, releases the wrapped key, CLI decrypts locally.
3. Revoke — Remove a teammate from the GitHub repo. Their next pull is rejected at the permission gate.

The server holds an encrypted copy of your master key (wrapped with a server-side KMS key) so teammates don't have to share keys manually. If you'd rather keep keys purely client-side (compliance-heavy use cases), pass --client-key-only on push and share via a secure channel.

See SECURITY.md for the full threat model.

Commands

boltenv login                  # Authenticate with GitHub
boltenv logout                 # Clear local credentials
boltenv init                   # Set up this project (.boltenv.yaml)
boltenv push                   # Encrypt & upload your .env
boltenv pull                   # Download & decrypt .env
boltenv ls                     # Version history & metadata
boltenv logs                   # Recent command activity (failures, durations, repos)
boltenv whoami                 # Show current user & repo
boltenv account                # Plan & monthly usage
boltenv upgrade                # Upgrade your plan (opens checkout in browser)
boltenv doctor                 # Diagnose connectivity, auth, key state
boltenv key export             # Export your local key (only needed for --client-key-only)
boltenv key import <base64>    # Import a teammate's key (only needed for --client-key-only)
boltenv key status             # Check key state for current repo

Push

boltenv push                          # Push .env from current directory
boltenv push .env.production          # Push a specific file
boltenv push -e production            # Push to a specific environment
boltenv push -y                       # Skip confirmation prompts
boltenv push --json                   # Structured JSON output (for CI scripting)
boltenv push --dry-run                # Show what would happen, don't upload
boltenv push --force                  # Skip the parent-version conflict check
boltenv push --client-key-only        # Don't upload key to boltenv
boltenv push --continue               # Resume a merge after resolving conflicts
boltenv push --abort                  # Cancel an in-progress merge

Pull

boltenv pull                          # Pull .env to current directory
boltenv pull -e staging               # Pull from a specific environment
boltenv pull --revision 3             # Pull a specific version (rollback)
boltenv pull --format json            # Output as JSON
boltenv pull --stdout                 # Print to stdout (pipe anywhere)
boltenv pull --json                   # Structured JSON output
boltenv pull --dry-run                # Show what would be pulled, don't write

Activity log — what happened, when, why

Every command writes a structured entry to ~/.boltenv/log.jsonl (mode 0600, rotates at 5MB). View it any time:

boltenv logs                       # Last 20 commands
boltenv logs --only-errors         # Only failures, with stable error codes (-E shorthand)
boltenv logs --cmd push --tail 5   # Last 5 pushes
boltenv logs --json                # One JSON object per line, pipe to jq
boltenv logs --path                # Print the log file path and exit
boltenv logs --clear               # Wipe local log

Privacy: only metadata is logged — command name, repo, env, duration, error code/message. Never values, file contents, tokens, or keys. See docs/error-codes.md for the full list of stable codes.

Three-way merge for concurrent edits

If your teammate pushes while you were editing, boltenv detects it and runs a three-way merge:

$ boltenv push
  ⚠ Merge conflict with bob's v3 (15 min ago)
    Auto-merged 2 keys without conflict
    1 conflict(s) written to .env

  Open .env in your editor, resolve <<<<<<< === >>>>>>> blocks, then:
    boltenv push --continue   # finalise the merge
    boltenv push --abort      # cancel and keep your local file

The conflict markers are git-style — every editor recognizes them natively. No new UI to learn.

Environments

boltenv auto-detects the environment from your git branch:

| Branch | Environment | |---|---| | main, master | production | | staging | staging | | develop, development | development | | anything else | development |

Override with -e:

boltenv push -e production
boltenv pull -e staging

Or set a custom mapping in .boltenv.yaml:

version: 2
defaultEnvironment: development
branchEnvironments:
  release/*: staging
  hotfix/*: production

CI/CD

# Set these in your CI environment:
export BOLTENV_TOKEN=$GITHUB_TOKEN              # any GitHub PAT with repo scope
export BOLTENV_REPO=myorg/myapp                 # skip git auto-detect

# Pull in CI
boltenv pull -y

secrets.GITHUB_TOKEN works in GitHub Actions. The server checks repo permissions on the token, releases the wrapped key, CLI decrypts locally. Same flow as your laptop.

For pure client-key-only mode (no server key escrow), also set:

export BOLTENV_KEY=<base64-from-boltenv-key-export>

In monorepo CI where one job pushes to multiple repos, use repo-scoped env vars to avoid one key silently applying to every repo:

export BOLTENV_KEY_MYORG_APP1=<base64-key-1>
export BOLTENV_KEY_MYORG_APP2=<base64-key-2>

To suppress the auto-update check in CI (it's already gated on TTY/CI detection):

export BOLTENV_NO_UPDATE_CHECK=1

Security

| | | |---|---| | Encryption | AES-256-GCM (NIST standard, authenticated) | | Key derivation | HKDF-SHA256 (separate subkeys for encryption + HMAC) | | IV | 12 bytes, random per push | | Auth tag | 16 bytes (tamper detection) | | Server sees | Ciphertext + wrapped key + GitHub-verified user identity | | Key at rest | AES-256-GCM wrapped with a server-side KMS key (BOLTENV_KEY_WRAPPER) | | Key in transit | TLS only; Cache-Control: no-store on key fetch | | Local cache | ~/.boltenv/keys/{owner}/{repo}.key (mode 0600) |

Full threat model: SECURITY.md. System internals: ARCHITECTURE.md.

Comparison

| Tool | Per-user cost | New accounts? | Encryption | ACL source | |---|---|---|---|---| | Slack DMs | Free | None | None | "I trust you" | | .env.example | Free | None | None | Drifts in 48h | | 1Password | $7.99/mo bundled | Yes | 1P-managed | 1Password users | | Doppler | $21/mo | Yes | Server-managed | Doppler users | | Infisical | $8/mo | Yes | Server-managed | Infisical users | | dotenvx | Free | None | AES-256 in git | Manual key sharing | | boltenv | Free for ≤3, $4/mo above | None | Client-side AES-256-GCM | GitHub repo permissions |

Requirements

• Node.js 20+
• A git repo with a GitHub remote
• A GitHub account with repo write access (collaborators or org members) — read-only access is rejected

What boltenv is NOT

We'd rather be honest about scope than overpromise.

• Not for compliance-heavy workloads. No SOC 2, no HSM, no formal audit logs yet.
• Not for 50+ person companies. No org-level RBAC. Repo permissions are the rules.
• Not a replacement for Vault. Different audience, different scale.
• Not self-hostable today. Cloud-only, with a free tier that fits a real team.

If any of those is a deal-breaker, you're not the user — and that's fine. Use Vault, Doppler, or Infisical. boltenv is for the team that doesn't need them.