[theozero]

Thanks for the kind words. It's actually decoupled and up to the user if they want to use it for pure validation as part of CI/deployment, just to inject values, or to integrate more deeply. But you can get the most benefit by integrating it fully. This lets you set values, compose values using functions, take advantage of coercion, and helps protect your secrets.

You can just use `varlock run -- ...your command` and it will load, validate, and reinject as env vars. This is what enables it to be used with any language or any tool. We have a standalone binary. You could also just use `varlock load` to do validation and rely on values all being set externally. However we do provide javascript helpers to just load everything automatically - although this just calls out to the CLI, keeping your app isolated from the code that loads and validates the vars. For JS we actually go a bit further and patch http and console to protect any sensitive data - because we know exactly which config items are sensitive.

It's really meant to just be a complete complete toolkit and then let users integrate as deep as they want to.

[xserhio]

Ah, I stand corrected! The varlock run -- approach and the standalone binary completely solve the vendor lock-in concern I mentioned.

I have to say, patching console and http in JS to auto-redact sensitive data based on the schema is genuinely brilliant. Leaking secrets in logs is a massive pain point, and handling it automatically at the tool level is a great solution.

Really impressive work on the entire toolkit. It’s definitely a much more comprehensive ecosystem than what I built. I appreciate you taking the time to explain the architecture—definitely taking some notes from this!