Philosophy

The principles behind varsafe: secrets go to the process, not a file; access matches the work; agents work on a grant; and every read is on the record.

The problem

Secrets should be boring. They are infrastructure: they should work and stay out of your way.

Instead, most teams live with this:

• .env files passed around in chat, and sometimes committed by mistake
• Production credentials sitting on every laptop that ever ran the app
• Nobody able to say who has access to what, or who read it last
• Rotation that means editing the same password in five places
• Offboarding that means rotating every key the departing person might have seen

Coding agents make it sharper. An agent that can run commands can read files, and a .env is a file: one cat .env and every value is in the agent’s context and its transcript.

None of this is a shortage of tools. It is what happens when the default path is a plaintext file. varsafe changes the default.

What we believe

Secrets go to the process, not to a file

A file can be committed, synced, backed up, indexed, or left behind on a laptop. So the everyday path writes no file at all:

varsafe run -- npm run dev

varsafe run hands the secrets to the process it starts, and they are gone when it exits. When a tool truly needs a file, you ask for one with varsafe export, and a .env export is encrypted by default. Plaintext is the opt-in, with --plain.

Access matches the work

Everything that touches a secret gets a credential sized for its job:

• People get a role. Production is protected from the start, so only owners and admins can change it.
• Pipelines get API tokens: limited to chosen projects and environments, read-only unless you say otherwise, and always expiring.
• Agents get a grant you approve (see below).

And when someone leaves, removing them revokes their CLI logins, their agent grants and the API tokens they created in one step, not a scramble.

Agents work on a grant, not on your keys

Agents now write code, run tests and deploy beside your team, and they need secrets to do it. They should not need to see them.

An agent connects over MCP and asks for access; you approve it on a consent screen, choosing the team, an access level, and optionally the projects and environments. Values stay out of reach unless you approve a level that includes them. A grant can never exceed your own role, and every secret operation is checked against that role as it stands at that moment. When an agent runs a command through varsafe run, the values go to the command, not to the agent.

Every read is on the record

Security you cannot observe is security you are taking on trust. So varsafe records every value read and every change: who, which client (dashboard, CLI, API token or agent), from where, and when. Sign-ins, role changes, token activity and exports are recorded too.

If someone reads production at 3 a.m., it is in the audit log. If a pipeline token reads more than its job needs, the log shows which keys. The log is append-only: the application can add events, never edit or delete them.

Safe by default, risky on request

You should not need to be a security expert to avoid the common mistakes. The safe choice is the default one:

• A secret value is never accepted as a command-line argument, where it would land in shell history and ps. You type it into a masked prompt, pipe it, or point at a file.
• API tokens and CLI logins are stored only as salted hashes, and every API token expires.
• The installer and varsafe update check the release’s publisher signature before installing anything.

And the risky one has to be asked for by name:

The terminal first, the dashboard for the overview

Developers live in their terminal, and so do agents and pipelines. The daily workflow is two commands:

varsafe login               # once per machine
varsafe run -- npm run dev  # every time

Choose a project and environment once with varsafe use; inside a repository it is saved to a small .varsafe file that holds IDs and no secrets, so everyone who clones the repository starts in the same place. Flags override it for one command.

The dashboard is for what a terminal does badly: seeing every environment side by side, inviting people, importing an existing .env, rolling back, and reading the audit log.

Honest about what we are

varsafe is a server-side secrets manager. Values are encrypted in transit and at rest, and the varsafe API decrypts them to serve each authorized request; that is what makes varsafe run work. It is not end-to-end encrypted, and we do not claim otherwise. What protects your secrets is access control you can see: roles, scoped credentials, tenant isolation in the database, and a record of every read. The security model sets out exactly what is and is not true, including what we do not have yet.

What we don’t do

We don’t build our own crypto

Cryptography and key management are hard, and the stakes are high. Secret values live in a dedicated secrets vault in the EU, encrypted at rest under a managed key service, and encrypted .env files use standard primitives: X25519, HKDF-SHA256 and AES-256-GCM. Our work goes into who can reach a secret and what is recorded, not into inventing ciphers.

We don’t deploy your code

varsafe provides secrets. It does not deploy your code, run your pipeline or manage your infrastructure. It works inside the tools you already have: any CI system, Docker, or any shell that runs a command.

Design decisions

Why not just use .env files?

They work, until they don’t. A .env file is:

• Easy to commit by accident
• Copied to every machine that needs it, and every copy has to be rotated
• Invisible: nothing tells you who has it or who read it
• Never clearly current: is this the latest version, or last month’s?

So varsafe injects by default and treats a file as the exception. When you need one, varsafe export generates it from the same source of truth, encrypted unless you ask for plaintext, and the export is in the audit log.

Why version history?

Secrets change, and sometimes they need to change back. Every save to an environment creates a new version, and varsafe keeps the last 10 of each environment, with who changed what and when. In the dashboard you can restore one secret or roll a whole environment back to before a change, after previewing what will change.

No more “what was the old API key?” or “who deleted that secret?”

What success looks like

When varsafe is working well:

• A new teammate runs the project on day one without asking where the .env is
• Rotating a password means changing it in one place
• An agent adds the key its task needs without the value ever entering its context
• Answering “who read production last week?” takes a filter, not an investigation
• Developers think about features, not credentials

Secrets become invisible infrastructure. That’s the goal.

Feedback

We’re building varsafe for developers. If something doesn’t feel right, tell us:

Contact form

We read every message.