Can use
The value reaches a process, and no human reads it.
What you grant your API server, your CI job, your test suite, an agent. It is the ordinary case, and it is the one that lets a credential do its job without becoming common knowledge.
Your application gets the credential. Nobody else has to.
Warder separates using a secret from seeing one. Developers run the app, CI deploys it, agents test it: none of them are handed the value, and none of them need to be.
$ ward run -- npm run devWhat you can see
What the process receives
The model
Two permissions, and no role grants either one
Most tools have a single “access” permission, so anyone who can deploy can also read. Warder splits it, and neither half comes with a job title.
Can see
A named person displays the plaintext, and it is recorded.
Sometimes genuinely necessary: pasting a key into a third-party console that has no other way in. It is a separate, deliberate grant, and every use of it has a name and a timestamp attached.
Owner, Admin, Developer, Viewer, those govern administration: creating projects, managing members, reading the audit log. None of them confers the ability to use or see a single secret value. That is always an explicit grant on a specific environment, which is what makes the answer to “who can read our production database password?” a short list instead of a guess.
In practice
What that actually changes
The same situations, with a different amount of work in them.
A contractor finishes and leaves.
Revoke their membership. Nothing rotates: they could use the database, they never held it.
An agent gets prompt-injected by a dependency README.
It holds USE_SECRET on development. It cannot print a value, reach production, rotate anything, or grant itself more.
Someone pushed a .env to a public repository.
There wasn’t one. The file holds two publishable keys and a project name.
You need to rotate a database password.
Rotate it in the dashboard and restart. No CI config, no manifests, no messages to the team.
Security asks who has read this credential.
One query against an append-only log. Usually the answer is nobody.
You revoke a token during an incident.
The next request is denied, including short-lived sessions already derived from it, rather than waiting for them to expire.
Integration
Three commands, and your code stays the same
Warder delivers values into the environment your process already reads. There is nothing to import and nothing to rewrite.
- 1
Point the repository at an environment
ward init --project payments-api --env development - 2
Sign in once per machine
ward login - 3
Run anything with the secrets injected
ward run -- npm run dev
In production the same command runs, with the credential coming from your platform’s secret store instead of a login. Full walkthrough, including frontends and CI.
Limits
What Warder does not do
Stated here rather than buried, because a security tool that only advertises its wins is hard to evaluate.
It does not get you to zero credentials.
Your application still holds one token that proves which application it is. Warder makes that one credential scoped, expiring and instantly revocable; it does not make it disappear. Nobody has solved that.
It does not stop an authorized process from reading its own environment.
A process given DATABASE_URL can print it. The protection is that the grant was narrow and deliberate, not that the value is unreadable once delivered.
It does not protect values you ship to a browser.
Anything in a client bundle is public no matter what produced it. Warder manages the server half and says so.