The vars system provides a declarative, reproducible way to manage generated files (especially secrets) in NixOS configurations. This page covers how the pieces fit together.
Declarative generation. Unlike imperative secret management, vars are declared in your NixOS configuration and generated deterministically, making deployments reproducible.
Separation of concerns. Generation logic lives in generator scripts. Storage is handled by pluggable backends (sops, password-store, etc.). Deployment runs through NixOS activation scripts. Access control is enforced through file permissions and ownership.
Composability through dependencies. Generators can depend on outputs from other generators, enabling complex workflows:
# Dependencies create a directed acyclic graph (DAG)
A → B → C
↓
D You can build systems like certificate authorities where intermediate certificates depend on root certificates.
Type safety. Secret files are only accessible via .path and deployed to /run/secrets/. Public files are accessible via .value and stored in the nix store. This separation prevents accidental exposure of secrets.
Pluggable storage backends handle encryption/decryption:
sops (default): integrates with Clan's existing sops encryptionpassword-store: for users already using passVars are generated in three phases:
clan vars generate creates vars explicitly--regenerate flagUse neededFor to control when vars are available during system activation:
files."early-secret" = {
secret = true;
neededFor = "users"; # Available early in activation
}; Setting share = true on a generator enables cross-machine secret sharing:
Use cases include shared certificate authorities, mesh VPN pre-shared keys, and cluster join tokens.
Complex systems can be built by composing simple generators:
root-ca → intermediate-ca → service-cert
↓
ocsp-responder Each generator focuses on one task, keeping the system modular and testable.
Compared to manual secret management, vars provides: