Envro
Env vars for Rust: validate with a composable rule set, load .env into std::env, and optionally derive a typed Config.
Features
- Validate env vars against a
Schemaof composable rules — works on anyHashMap, a.envfile, or the live process environment - Load a
.envinto the process with an explicit override policy, or parse it to a map with no side effects - Derive a typed
Configwith#[derive(Envro)]— field types are coerce targets;#[envro(...)]attrs are the rules; values still load at runtime - Defaults for optional vars —
Field::default_value("…")/#[envro(default = "…")](required forOption<T>) - Compose derived values with
${VAR}substitution, then validate each part - Small
.envdialect — comments, quotes, multiline, duplicate keys rejected - Encryption — optional
encryptionfeature;Encrypted[AGE:b64:…]in.envviaENVRO_AGE_IDENTITY_FILE+#[envro(secret)]; CI can inject plaintext (docs/encryption.md)
Getting started
# with encrypted secrets in .env (age):
Typed app config
Typical service setup: optional .env for local dev, then validate and coerce the process environment into a struct.
use env;
use ;
On failure, EnvroError::Validation lists every failing rule:
// example/src/bin/getting_started_error.rs — cargo run --bin getting_started_error
match from_dotenv
Real-world: CD / process env
In CI/CD, inject process env vars as plaintext. #[envro(secret)] still applies — process plaintext is allowed; only a .env file requires Encrypted[…]. Compose with ${VAR} via Config::from_env():
use ;
Runnable version: cd example && cargo run --bin example.
See docs/dotenv-format.md for ${VAR} rules.
Without derive
Same rules as a hand-written Schema when you only need validation (maps, tests, no struct):
use *;
let schema = new
.field
.field;
validate_env?;
// or: load_dotenv_validated(&path, &schema)?; validate(&vars, &schema)?;
Documentation
| Doc | Contents |
|---|---|
| docs/api.md | Public APIs and types (functions, Schema / Field, derive) |
| docs/validation.md | Rule reference (secret, …), semantics, error inspection |
| docs/dotenv-format.md | .env dialect, ${VAR}, encrypted values |
| docs/encryption.md | Age secrets, identity file, PQ keys, Compose / CI |
| docs/comparison.md | Comparison with dotenvy, dotenv-ng, and related crates |
| docs.rs/envro | Generated rustdoc |
Out of scope
- No multi-file layering — one path per call (CUE on inheritance, Angular LIFT Flat)
- No macros that bake env values into the binary —
#[derive(Envro)]encodes types and rules only; values always load at runtime
Best practices
- Never commit
.env— add.envto.gitignore; commit.env-sample/ docs with placeholder values only - Validate at the boundary — load optional local
.env, thenConfig::from_env()/validate_envso missing or bad vars fail fast - Mark secrets —
#[envro(secret)]/Field::secret()so plaintext secrets in a.envare rejected (docs/encryption.md) - CD injects plaintext — CI/containers set process env; do not ship
.envinto prod images - One identity per project — keep age private keys outside the repo (
ENVRO_AGE_IDENTITY_FILE); never reuse one key across all apps - Prefer compose over duplication — build URLs with
${VAR}and validate parts + the composed value - Fail closed in prod — required fields, tight
one_of/ length / format rules; defaults only where a safe fallback exists
License
MIT © 2024-2026 Simone Sanfratello