varlock

Schemas instead of dotenv files

Varlock takes a different approach to environment configuration than the usual .env file. Instead of a flat list of keys and values, you keep a .env.schema that declares each variable with a type, validation rules, and a description. The schema becomes the single source of truth for a project's configuration, and the README argues it will never drift out of sync the way a .env.example tends to. Each entry is annotated with JSDoc style comments that Varlock reads: you can mark a value as sensitive, required, or typed as a port, a URL, or an enum. The example in the README shows an APP_ENV enum that controls automatic loading of .env files, an API_PORT that holds a plain number, and an OPENAI_API_KEY marked sensitive with a rule that it must start with sk-. Because the schema is declarative, editors can offer type safety and autocomplete through the bundled language server extension. The pitch is that this one file serves both humans and tooling, where the .env holds the real secrets and the schema holds everything else needed to understand the config. The source lives in the dmno-dev-varlock repository on GitHub and is implemented in TypeScript, with the license recorded as MIT in the project metadata.

Keeping secrets away from agents

The part of Varlock aimed at the current wave of coding agents is its AI safe config story. An agent working in your repo can read the .env.schema to learn variable names, types, and validation rules without ever seeing the secret values. That separation means a model can reason about how to use a configuration without being handed the credentials themselves. On top of that, the varlock scan command looks for leaked secrets in generated code, and git hooks can run the scan automatically so a mistake is caught before it is committed. The runtime side adds log redaction and leak prevention, so secrets are less likely to surface in logs or error output. The README frames the whole tool as purpose built for the AI era, where agents routinely read project files. Rather than hoping a model ignores a .env, Varlock makes the secrets structurally unavailable to it while still giving the agent enough context to write correct code. The docs link to a dedicated AI tools guide for teams wiring this into their workflow, and the scan plus hook path is the practical day to day protection. The source lives in the dmno-dev-varlock repository on GitHub and is implemented in TypeScript, with the license recorded as MIT in the project metadata.

Plugins and integrations

Varlock does not expect you to keep every secret in a local file. Its plugin system adds decorators and functions that pull values from external backends, and the README lists a long set of ready made plugins. These cover 1Password, Infisical, AWS, Azure, Google Secret Manager, HashiCorp Vault, Bitwarden, Dashlane, Doppler, KeePass, Kubernetes, Passbolt, Proton Pass, and more. A plugin example shows fetching a 1Password service account token and then referencing Vault items with an op() syntax inside the schema. That keeps the credential itself in the secret manager while the schema records where to find it. Framework integrations exist for Astro, Cloudflare, Expo, Next.js, Nuxt, and Vite, and the README calls them drop in integrations that add security guardrails such as log redaction. There are also MCP servers, both over HTTP and SSE, so agent tooling can query Varlock docs directly. The published packages page in the README maps each plugin and integration to its npm listing, which makes it easy to see what is available before you install. The underlying @env-spec package is the DSL that attaches schema data to dotenv files using the comment syntax. The source lives in the dmno-dev-varlock repository on GitHub and is implemented in TypeScript, with the license recorded as MIT in the project metadata.

Getting started

Installing Varlock starts with a CLI. The README shows npx varlock init as an install wizard that adds the tool as a dependency in a JavaScript project, and it also offers a standalone binary through Homebrew or a cURL install script, plus an official Docker image. Once installed, the common commands are varlock load to validate the schema and pretty print the resolved variables, and varlock run to pass those variables into another process, shown as varlock run -- python script.py. For many stacks the drop in integrations remove the need to call the CLI by hand, since they wire Varlock into the framework's normal start path. The schema itself is built on the @env-spec DSL, which the README documents as a way to attach a schema and extra behavior to dotenv files using JSDoc style comments. The project also points to a separate examples repository for integrating Varlock across frameworks and situations. Contribution guidance lives in CONTRIBUTING.md. Between the npm package, the VS Code and Open VSX extension, and the container image, the entry points cover local development, editor support, and containerized deployment without much ceremony. The source lives in the dmno-dev-varlock repository on GitHub and is implemented in TypeScript, with the license recorded as MIT in the project metadata.

Editorial conclusion

The project is written in TypeScript, published under the MIT license, and installable from npm or as a Homebrew and Docker package.