Share encrypted .env files
via Git

What SecretEnv Solves

SecretEnv is a CLI tool that encrypts .env files, certificates, and other secrets for management in a Git repository. It requires no external services or servers, working entirely offline.

Encrypt .env in seconds

# Initial setup (one-time only)
secretenv init --member-handle alice@example.com

# Encrypt .env and bring it under Git management
secretenv import .env

# Add or update values directly
secretenv set DATABASE_URL "postgres://..."
secretenv set API_KEY "sk-..."

Encrypted files are stored in .secretenv/secrets/ and can be committed to Git as-is. The plaintext .env is no longer needed, eliminating the risk of secret leakage.

Works with your existing workflow

# Inject encrypted .env as environment variables and run commands
secretenv run -- docker compose up
secretenv run -- npm start
secretenv run -- rails server

# Retrieve individual values
secretenv get DATABASE_URL

secretenv run injects decrypted values as environment variables into the process. No plaintext is written to disk, preventing leaks from forgotten .env files or accidental commits.

Member management flows through Git

# A new member joins
secretenv join --member-handle bob@example.com
# → Create a PR for the team to review and merge

# An existing member runs rewrap to distribute keys
secretenv rewrap
# → bob can now decrypt

Adding and removing members is represented as file operations in Git. Since changes go through PR review, unauthorized access grants are prevented.

Secure member offboarding

# Remove a member
secretenv member remove alice@example.com

# Re-encrypt files to revoke access
secretenv rewrap
# → Recorded in removed_recipients for access history tracking

SecretEnv records removed member history (removed_recipients) within encrypted files. This makes it easy to identify which secrets need rotation when a member leaves, by showing who previously had access.

Reviewable .env diffs

SecretEnv's data format encrypts each .env key-value pair individually.

• When you update a value with set, only the changed entry and signature appear in the diff
• When you add members with rewrap, the encrypted values themselves don't change (only key distribution info is updated)

Even though files are encrypted, diffs remain minimal, making it possible to review "what changed" in PRs.

No network or infrastructure required

All core features of SecretEnv work entirely locally.

• No dedicated secret management infrastructure to operate
• No dependency on KMS or external services
• Works in offline environments
• Git is just one distribution method — SecretEnv works without it too

Who It's For

• Git & PR-centric development: You want secret changes to go through the same review flow as code
• Small team secret sharing: You need a simple, secure way to share .env files and certificates within your team
• No SaaS or always-on dependency: You want the same workflow offline and in local development
• Streamlined onboarding: You want new members to access secrets simply by joining

Why It's Secure

SecretEnv uses no custom cryptographic algorithms — it's built entirely on standardized cryptographic primitives.

Only registered members can decrypt

Each member's public key is used for individual encryption, so only the private key holder can decrypt. Encryption uses HPKE (RFC 9180), the same standard adopted in web browsers and TLS.

Tamper detection

Encrypted files include Ed25519 digital signatures (RFC 8032). Any unauthorized modification to repository files is automatically detected during decryption.

Impersonation prevention

When adding members, identity is verified through attestation signatures with SSH private keys and GitHub API public key matching, preventing injection of fraudulent keys.

Ciphertext replay prevention

The encryption process cryptographically binds "which secret this ciphertext belongs to" and "which key generation was used." Reuse or substitution of ciphertext across different contexts is always detected.

Getting Started

Prerequisites

• SSH (Ed25519 key): Used for key generation and signing. If you already have one for GitHub, you can reuse it. Otherwise, generate one with ssh-keygen -t ed25519
• GitHub account (optional): Used for online public key verification. Core features work without it

Installation

# Homebrew
brew install ebisawa/secretenv/secretenv

Add to an existing project (takes 1 minute)

# 1. Initialize the workspace
secretenv init --member-handle alice@example.com

# 2. Encrypt and import your existing .env
secretenv import .env

That's it. From now on, use secretenv run or secretenv get to access your secrets.

FAQ

Do I need GPG?

No. SecretEnv works with SSH keys (Ed25519) only. No GPG or PGP key management required.

Do I need a cloud Secrets Manager?

No. Encryption, decryption, and key management all happen locally. There's no dependency on KMS or cloud services.

Do I need to manage a shared secret key?

No. SecretEnv uses public-key cryptography (HPKE), so there's no shared secret key for the entire team. Each member's public key is used for individual encryption, eliminating the burden of distributing, managing, and rotating a common password or shared key.

What is the SSH key used for?

SSH keys are used for identity attestation (signing) and private key protection. Encryption and decryption use HPKE key pairs generated by SecretEnv, not the SSH key directly.

Do I need to create a new SSH key?

If you already have an Ed25519 key (e.g., for GitHub), you can reuse it. Otherwise, generate one with ssh-keygen -t ed25519.

Does it work with ssh-agent?

Yes. SecretEnv supports signing via ssh-agent, so you don't need to specify key files directly. It also works with 1Password's SSH agent.

Can I migrate from an existing .env file?

Yes. secretenv import .env imports everything at once. Your existing workflow stays the same — just use secretenv run to execute commands as before.

Can I encrypt files other than .env?

Yes. Certificates, configuration files, and arbitrary binaries can be handled with secretenv encrypt / secretenv decrypt.

Does it work in CI/CD environments?

Yes. secretenv run and secretenv get work non-interactively, making them easy to integrate into CI pipelines.

Does it work offline?

Yes. All core operations — encryption, decryption, and signature verification — work entirely locally. No external server or network connection required. Online verification via GitHub API is an optional additional check.

Can I manage multiple environments (dev / staging / prod)?

Yes. You can create separate secret files for each environment and manage them within the same workspace.

What happens if encrypted files conflict in Git?

SecretEnv encrypts each .env key individually, so changes to different keys rarely conflict. If the same key is modified simultaneously, resolve the conflict by choosing one side, just like any other Git conflict.

Is key rotation supported?

Yes. secretenv rewrap --rotate-key regenerates encryption keys and re-encrypts everything. This supports both member changes and periodic rotation.

Is it safe to make the repository public if secrets are encrypted?

Encrypted files are protected by modern cryptography (HPKE, XChaCha20-Poly1305), making decryption without the private key extremely difficult. However, making a repository public carries operational risks beyond encryption strength (key leakage, future advances in cryptanalysis, etc.). For highly sensitive data, we recommend keeping the repository private.

Is SecretEnv free? What's the license?

Yes. SecretEnv is open-source software under the Apache License 2.0, free for both personal and commercial use.

Is there support or warranty?

SecretEnv is provided as open-source software "AS IS" without warranty of any kind, express or implied. Use is at your own risk. Bug reports and feature requests are welcome via GitHub Issues.