Schema-driven validation for environment variables and .env files — one portable schema, three native implementations.

envlint documentation

envlint is schema-driven validation for environment variables and .env files. You describe what your service expects once in an envlint.toml, then validate a .env file or the live process environment against it — in CI, in a container entrypoint, or at process boot via the library.

Most production incidents that trace back to “config” are not subtle: a required variable was never set, a PORT held a hostname, a LOG_LEVEL of verbose silently fell back to a default, a timeout was 30 — seconds or milliseconds? These are caught trivially if something declares what the service expects.

When to use it

• ▸Unlike dotenv, envalid, or zod — which make a running program read its config — envlint is a gate that runs before your program (or your deploy) does, with no code in the target service.
• ▸No language lock-in: the same envlint.toml validates a Rust binary, a Node container, and a JVM service alike.
• ▸It is a CI/CD check first, a library second.