DEV Community: Suchismita Moharana

Managing and Securing Environment Variables (.env): A Look at evnx

Suchismita Moharana — Sun, 05 Apr 2026 11:24:54 +0000

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.

The .env / .env.example Sync Problem

Most projects maintain two files:

.env — the actual file with real credentials, never committed
.env.example — a template committed to the repository, with keys but no values

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.

What is evnx?

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.

License: MIT
Version: v0.3.8
Platforms: macOS, Linux, Windows
GitHub: github.com/urwithajit9/evnx

Installation

evnx ships as a single static binary with no runtime dependencies.

macOS / Linux (recommended — consistent behavior across environments):

curl -fsSL https://dotenv.space/install.sh | bash

This is the approach I use. It's the most straightforward and avoids environment-specific issues.

Cargo (Rust):

cargo install evnx

pipx (preferred over pip):

pipx install evnx

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.

npm:

npm install -g evnx

Full installation guide: evnx.dev/guides/getting-started/installation

evnx --version
# evnx 0.3.8

Getting Started: Core Use Cases

1. Initializing a Project with evnx init

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.

evnx init

If you're starting a specific type of project, evnx has pre-built blueprints for common stacks:

evnx init --blueprint fastapi
evnx init --blueprint nextjs
evnx init --blueprint django

These generate a .env.example pre-populated with the variables typical for that framework, a useful starting point rather than building from scratch.

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

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:

evnx sync --direction forward

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:

evnx sync --direction reverse

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.

3. Scanning for Secrets

Once your project is set up, scanning is a quick check before any commit or share:

evnx scan

evnx detects AWS keys, Stripe secrets, GitHub tokens, and high-entropy strings. For a specific path or output format:

evnx scan --path ./config --format sarif

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:

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: evnx-scan
        name: Scan for secrets
        entry: evnx scan --exit-code
        language: system
        files: '\.env'

4. Running a Health Check with evnx doctor

Before sharing a project with anyone, evnx doctor gives a full picture of the environment's state:

evnx doctor

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:

evnx doctor --fix

This is a useful habit before handing off a project, three seconds to catch what's easy to miss.

Additional Features for Production and Enterprise Workflows

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.

evnx validate --strict --exit-code

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.

evnx convert --from .env --to kubernetes

Cloud Migration (Experimental)
Push secrets directly to AWS Secrets Manager, Doppler, Infisical, or GitHub Actions.

evnx migrate --to aws-secrets-manager

Add Variables from CLI (New)
Manage .env entries without directly editing files.

evnx add DATABASE_URL "postgres://user:pass@localhost/db"

Encrypted Backups
AES-256-GCM encryption with Argon2 key derivation for local backup storage.

Template Engine
Type 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.

Comparison with Similar Tools

dotenv-vault

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.

detect-secrets (Yelp)

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.

git-secrets (AWS Labs)

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.

Infisical CLI

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.

Summary

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

curl -fsSL https://dotenv.space/install.sh | bash
evnx doctor

Python Functions & Arguments: From Basics to *args and **kwargs

Suchismita Moharana — Wed, 28 Jan 2026 09:54:09 +0000

If you are learning Python, functions feel easy at first. You define them, pass arguments, get results. Then one day you encounter *args and **kwargs, and suddenly function calls look confusing and unpredictable.

This article is designed as one complete learning source. We will start from absolute basics and slowly move toward advanced, production‑ready patterns used in real Python libraries.

By the end of this post, a beginner will understand not just what *args and **kwargs are, but why they exist and how professionals design APIs using them.

We will build everything step by step using one evolving example: create_subway() 🥪

1. What Is a Function?

A function is a reusable block of code that:

accepts input (arguments)
performs logic
optionally returns output

def greet(name):
    return f"Hello {name}"

greet("Jazz")

Here:

name → parameter (defined in function)
"Jazz" → argument (passed during call)

This distinction matters once arguments become flexible.

2. Positional Arguments (Order Matters)

def create_subway(size, bread):
    print(size, bread)

create_subway(30, "multi-grain")

Python assigns values by position:

30 → size
"multi-grain" → bread

If you swap them, Python won’t complain — but your logic will break.

3. Keyword Arguments (Name Matters)

create_subway(bread="multi-grain", size=30)

Now:

Order doesn’t matter
Names do

Critical Rule (Very Important)

Python always assigns positional arguments first, from left to right, before it processes keyword arguments.

This single rule explains most *args / **kwargs confusion.

4. Why Fixed Arguments Don’t Scale

Imagine a real sandwich order:

size
bread
quantity
veges
sauces
extras

You cannot keep adding parameters forever:

def create_subway(size, bread, veges, sauce, extras, cheese_type, toast_level):
    ...

This becomes unreadable and fragile.

Python solves this with variable arguments.

5. `*args` — Variable Positional Arguments

*args collects extra positional arguments into a tuple.

Beginner Version

def create_subway(size, bread, *args):
    print(f"Size: {size}")
    print(f"Bread: {bread}")
    print(f"Extras: {args}")

Call:

create_subway(30, "multi-grain", "cheese", "paneer", "jalapeno")

Internally:

args == ("cheese", "paneer", "jalapeno")

When to Use `*args`

Number of values is unknown
Order matters
Names don’t matter

6. `**kwargs` — Variable Keyword Arguments

**kwargs collects extra keyword arguments into a dictionary.

Example

def create_subway(size, bread, **kwargs):
    print(f"Size: {size}")
    print(f"Bread: {bread}")
    print("Options:", kwargs)

Call:

create_subway(
    30,
    "multi-grain",
    veges=["olive", "cucumber"],
    sauce=["bbq", "honey-mustard"]
)

Internally:

kwargs == {
    "veges": [...],
    "sauce": [...]
}

When to Use `**kwargs`

Optional configuration
Named values
Future‑proof APIs

7. Using `*args` and `**kwargs` Together

Correct order must be followed:

def create_subway(size, bread="multi-grain", *args, **kwargs):
    ...

Order rule:

Required parameters
Default parameters
*args
**kwargs

8. Why `bread` Became Positional (Common Confusion)

create_subway(30, 2, bread="honey-bread")

Step-by-step binding

Position	Parameter	Value
1	size	30
2	bread	2

Python assigns positional arguments first.

Now bread already has a value (2).

When Python sees:

bread="honey-bread"

It raises:

TypeError: got multiple values for argument 'bread'

Nothing is converted. Position alone decides binding.

9. Defensive `create_subway()`

Beginner‑safe version:

def create_subway(size, bread="multi-grain", *args, **kwargs):
    print(f"Size: {size}")
    print(f"Bread: {bread}")

    if args:
        print(f"Quantity: {args[0]}")

    veges = kwargs.get("veges", [])
    sauces = kwargs.get("sauce", [])

    print("Veges:", veges)
    print("Sauces:", sauces)

10. Production‑Ready Version (Recommended)

def create_subway(
    size: int,
    bread: str = "multi-grain",
    quantity: int = 1,
    *,
    veges=None,
    sauces=None
):
    veges = veges or []
    sauces = sauces or []

    print("Order Summary")
    print("-" * 20)
    print(f"Size     : {size}")
    print(f"Bread    : {bread}")
    print(f"Quantity : {quantity}")
    print(f"Veges    : {veges}")
    print(f"Sauces   : {sauces}")

Call:

create_subway(
    30,
    bread="honey-bread",
    quantity=2,
    veges=["olive", "cucumber"],
    sauces=["bbq"]
)

Why This Is Production‑Ready

Keyword‑only arguments (*)
Type hints
Explicit API
No hidden positional traps

11. Real‑World Usage from Popular Libraries

`print()`

print("Jazz", "Suchi", sep=", ", end="!")

Internally uses:

def print(*args, **kwargs):
    ...

`logging`

logger.info("User %s logged in", user_id, extra={"ip": ip})

*args → message formatting
**kwargs → metadata

`requests`

requests.get(
    url,
    headers={...},
    timeout=5,
    params={...}
)

Flexible APIs powered by **kwargs.

`pandas`

df.drop(columns=["A"], inplace=True, errors="ignore")

Keyword arguments allow backward compatibility and clean defaults.

12. Mental Model That Sticks

*args → extra values
**kwargs → extra named settings
Positional arguments lock slots first
Keywords cannot override positions

Final Takeaway

If you understand:

how Python binds arguments
why position beats name
when to use *args vs **kwargs

You are no longer a beginner.

You are designing flexible, professional Python APIs — exactly how real libraries do it.

Happy coding 🚀

DEV Community: Suchismita Moharana

Managing and Securing Environment Variables (.env): A Look at evnx

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

Python Functions & Arguments: From Basics to *args and **kwargs

1. What Is a Function?

2. Positional Arguments (Order Matters)

3. Keyword Arguments (Name Matters)

Critical Rule (Very Important)

4. Why Fixed Arguments Don’t Scale

5. *args — Variable Positional Arguments

Beginner Version

When to Use *args

6. **kwargs — Variable Keyword Arguments

Example

When to Use **kwargs

7. Using *args and **kwargs Together

8. Why bread Became Positional (Common Confusion)

Step-by-step binding

9. Defensive create_subway()

10. Production‑Ready Version (Recommended)

Why This Is Production‑Ready

11. Real‑World Usage from Popular Libraries

print()

logging

requests

pandas

12. Mental Model That Sticks

Final Takeaway

5. `*args` — Variable Positional Arguments

When to Use `*args`

6. `**kwargs` — Variable Keyword Arguments

When to Use `**kwargs`

7. Using `*args` and `**kwargs` Together

8. Why `bread` Became Positional (Common Confusion)

9. Defensive `create_subway()`

`print()`

`logging`

`requests`

`pandas`