Skip to content
varlock

Secrets management

varlock uses the term sensitive to describe any value that should not be exposed to the outside world. This includes secret api keys, passwords, and other generally sensitive information. Instead of relying on prefixes (e.g., NEXT_PUBLIC_) to know which items may be “public”, varlock relies on @decorators to mark sensitive items explicitly.

Marking @sensitive items

Section titled “Marking @sensitive items”

Whether each item is sensitive or not is controlled by the @defaultSensitive root decorator and the @sensitive item decorator. Whether you want to default to sensitive or not, or infer based on key names is up to you. For example:

.env.schema
# @defaultSensitive=false
# ---
# not sensitive by default (because of the root decorator)
NON_SECRET_FOO=
# @sensitive # explicitly marking this item as sensitive
SECRET_FOO=

Using 3rd party tools

Section titled “Using 3rd party tools”

varlock is compatible with any 3rd party tool that supports fetching secrets via a CLI. With execfunction syntax, you can use any 3rd party tool to fetch secrets.

Here’s an example using 1Password:

Terminal window
# A secret in 1Password
# @sensitive @required
MY_SECRET=exec(`op read "op://devTest/myVault/credential"`);

This way no secrets are ever left in plaintext on your system, even if they are gitignored.

Security enhancements

Section titled “Security enhancements”

Unlike other tools where you have to rely on pattern matching to detect sensitive-looking data, varlock knows exactly which values are sensitive, and can take extra precautions to protect them.

For example, some of the features supported by our libraries and integrations:

  • Redact sensitive values from logs
  • Scan client-facing bundled code at build time
  • Scan outgoing HTTP responses at runtime