Varlock is a great and flexible way to do this.

Additionally provides pre commit scanning, log redaction, and much more.

Using plugins that register new functions, you can fetch from many different backends (15 and growing). The main difference if I understand correctly is that the wiring of vars to where those things live does live in committed code, but is totally declarative and safe. It's also incredibly flexible since functions can be written to make things idiomatic for that backend. Keeping that within git makes sense to us, as you ideally want deployments to be immutable.

The other benefit is this gives you a way to manage both sensitive and non-sensitive config - with a single source of truth for validation, types, docs.

This is a modern successor to the popular changesets tool, used by many open source projects.

While changesets is great, and I love the file-based bump+changelog workflow, the project has hundreds of open issues, many of which have been open for multiple years. Bumpy fixes most of the important ones (over 120+ by my last count), and adds some new features as well. It also greatly simplifies things, so it should be easier to evolve as folks start pushing its limits.

Some highlights:

  - changesets is built as a monorepo with 20 subpackages, this is a much simpler monolith
  - changesets requires you install a github app, use a github action, an npm module, and another for changelog formatting (this is a single install)
  - much more flexible include/exclude logic, instead of assuming behaviour is the same for all private packages
  - allows custom publishing commands, does not assume/force npm publishing
  - more sane peer dependency bumping logic
  - built in formatters, and easier to write custom ones
  - non-interactive version of add command (useful for agents)
  - it's infested with delightful frogs
  - lots of other small quality of life improvements

  - no prerelease workflows yet (changesets users say this part of it is very confusing, so want to get it right)
  - I want to allow multiple publish targets per package
  - Add plugin system to define common publishing targets (e.g., VSCode extension marketplace)

Run `bunx @varlock/bumpy init` to get started - if you are using changesets, it will help you migrate automatically.

Comments URL: https://news.ycombinator.com/item?id=47931761

Points: 5

# Comments: 0

There are plugins for many different secret storage solutions, including infisical - as well as native local encryption (ie secure enclave on mac) that will be released very soon.

Plus it adds validation, imports, log redaction, leak prevention, and a ton more.

Keepass plugin is in an open PR, should be merged soon!

Should be easy enough to set up a keyenv plugin - varlock adds a lot of additional last mile tooling to get secrets/config integrated into projects, regardless of where they ultimately live.

The huge benefit is that if you are already using it for other stuff, there is no additional "secret zero" to set up - plus you get biometric unlock for your secrets.

Easiest way to use it for dev purposes is varlock (although I'm biased since I created it).

https://github.com/dmno-dev/varlock

It’s a whole toolkit for this - with built in validation, type safety, and extra protection for sensitive secrets.

Additionally it redacts secrets from logs (one of the other main concerns mentioned in these comments) and in JS codebases, it also stops leaks in outgoing server responses.

There are plugins to pull from a variety of backends, and you can mix and match - ie use 1Pass for local dev, use your cloud provider's native solution in prod.

Currently it still injects the secrets via env vars - which in many cases is absolutely safe - but there's nothing stopping us from injecting them in other ways.

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.

You can use it to declaratively fetch from various backends, but it’s optional. At its core it lets you create a .env.schema and you get validation, type safety, guardrails for sensitive values, and a flexible toolkit to deal with all config related headaches.

The big difference from your tool (and many others) is that instead of trying to provide tooling to keep an example and other files in sync, the schema file is part of the loading process, so it can never be out of sync. This also helps create a single source of truth, and helps create a unified system to deal with all config - both sensitive and not.

But hey some tokenized crypto dns provider is probably much more reliable! lol