The .env / .env.example Sync Problem

What is evnx?

Installation

Getting Started: Core Use Cases

1. Initializing a Project with evnx init

2. Syncing .env and .env.example (Both Directions)

3. Scanning for Secrets

4. Running a Health Check with evnx doctor

Additional Features for Production and Enterprise Workflows

Comparison with Similar Tools

dotenv-vault

detect-secrets (Yelp)

git-secrets (AWS Labs)

Infisical CLI

Summary As an AI security researcher, my work spans Python, Rust, and React - model training pipelines, experimental tooling, and small frontend interfaces. Like most developers, I rely on .env files for managing environment variables. The problem shows up most clearly when sharing projects with lab members or pushing to an organization repository. A committed .env file, even accidentally, can expose API keys, database credentials, or model endpoint secrets. But beyond accidental commits, there's a quieter issue that comes up constantly in collaborative work: .env and .env.example falling out of sync. After evaluating several tools in this space, I started using evnx, a recently released open-source CLI. This post covers practical use cases, installation, and how it compares to similar tools. Most projects maintain two files: In practice, .env grows over time. New variables get added, some get removed, names change. The .env.example often doesn't keep up. A new collaborator clones the repo, copies .env.example to .env, and discovers that half the variables they actually need aren't listed or that some entries in .env.example no longer exist in the codebase. The reverse is equally common: you're setting up a project from scratch and want to generate a working .env from .env.example, with safe placeholder values already filled in, so you have a complete starting point without hunting through documentation. evnx addresses both directions explicitly. evnx is an open-source CLI written in Rust for initializing, syncing, validating, scanning, and converting .env files. It's a relatively new tool still in early versions, but already covers a solid range of the .env workflow. evnx ships as a single static binary with no runtime dependencies. macOS / Linux (recommended — consistent behavior across environments): This is the approach I use. It's the most straightforward and avoids environment-specific issues. pipx (preferred over pip): If you're in a Python environment, use pipx rather than pip install evnx. Installing CLI tools via pip into your active environment can create dependency conflicts and the tool may not be available globally. pipx installs it in an isolated environment and exposes on your PATH cleanly. Full installation guide: evnx.dev/guides/getting-started/installation The first thing to do in a new project is set up the .env structure properly. Running evnx init creates both .env and .env.example, and adds .env to .gitignore automatically. If you're starting a specific type of project, evnx has pre-built blueprints for common stacks: These generate a .env.example pre-populated with the variables typical for that framework, a useful starting point rather than building from scratch. This is one of the more practical features and addresses the sync problem described above. Forward sync — updating .env.example from .env: When you've added new variables to your .env and want to propagate the keys (without values) to .env.example: This keeps .env.example current with whatever is in your actual .env, replacing real values with safe placeholders. Useful before sharing a project or committing an updated template. Reverse sync — generating .env from .env.example: When a collaborator clones a repository and needs a working .env to start from: This creates a .env from .env.example with placeholder values filled in — CHANGE_ME, typed defaults, or inferred safe values — so there's a complete, valid file to edit rather than an empty starting point. No more manually copying the example file and hunting for what each variable should contain. Both directions make the .env / .env.example relationship explicit and manageable, rather than something that drifts silently over time. Once your project is set up, scanning is a quick check before any commit or share: evnx detects AWS keys, Stripe secrets, GitHub tokens, and high-entropy strings. For a specific path or output format: This can be integrated into a pre-commit hook so it runs automatically on every commit attempt, or used manually as a step before pushing or sharing a project: Before sharing a project with anyone, evnx doctor gives a full picture of the environment's state: It checks whether .env is in .gitignore, whether file permissions are appropriate, whether .env.example is in sync, and flags anything that looks misconfigured. For a quick fix pass: This is a useful habit before handing off a project, three seconds to catch what's easy to miss. Beyond the core use cases above, evnx has several features worth knowing about for more complex setups: Validation

Catches placeholder values (changeme, your-key-here), weak secrets, and localhost URLs in configs before deployment. Format Conversion (14+ targets)Exports .env to Kubernetes Secrets, Terraform variables, GitHub Actions secrets, Doppler, Infisical, Vercel, Heroku, JSON, YAML, and more. Useful when the same variables must exist across multiple deployment formats. Cloud Migration (Experimental)Push secrets directly to AWS Secrets Manager, Doppler, Infisical, or GitHub Actions. Add Variables from CLI (New)Manage .env entries without directly editing files. Encrypted BackupsAES-256-GCM encryption with Argon2 key derivation for local backup storage. Template EngineType filters (|int, |bool, |upper) for generating environment configs across multiple environments from a single template. CI/CD Integration

SARIF output compatible with the GitHub Security tab. Exits 1 on findings for use as a pipeline gate in GitHub Actions, GitLab CI, or similar. A cloud-based solution for encrypting and syncing .env files through a managed vault. Useful for team sharing, but requires an account and cloud dependency. No secret scanning, no format conversion, no CI gate functionality. evnx covers all of these and works entirely offline. A Python-based tool focused specifically on detecting credentials in source code. Single-purpose, no validation, sync, conversion, or diagnostics. A reasonable choice if scanning is all you need, but you'd still need other tooling for the rest of the .env lifecycle. Prevents secret commits via configurable pattern scanning at the git hook level. Narrow in scope, requires manual per-repository configuration and has seen slow maintenance. evnx covers the same use case with less setup and adds considerably more. A full secrets management platform with CLI support for runtime secret injection. Well-built for teams needing centralized secret storage, but requires an Infisical server or cloud account and a longer onboarding process. It's infrastructure, not a dev-time tool. evnx can migrate your .env files directly to Infisical if you decide to adopt it later. evnx is a relatively new tool and is still adding features, but it already handles more of the .env workflow than any single alternative I've looked at initialization, bidirectional sync, scanning, validation, format conversion, and health diagnostics without requiring accounts, cloud dependencies, or a complex setup. For research environments where projects move between local machines, shared lab systems, and organizational repositories, it's a practical addition to the workflow. The sync functionality alone, both directions, solves a problem that most .env tooling doesn't address at all. Worth trying: evnx.dev Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse