DevOps Secrets overview
A programmatic secret store for CI/CD — hierarchical namespaces, machine service accounts, scoped API keys, path-pattern policies, envelope encryption, and continuous credential validation.
DevOps Secrets is PulsVault's programmatic secret store for CI/CD and applications. Where the personal vault is for humans unlocking secrets in a browser, DevOps Secrets is for machines — pipelines, servers, and agents that fetch credentials over a REST API using a bearer token.
It sits on the same encrypted core as the rest of PulsVault (envelope encryption, hash-chained audit, RBAC), and adds the pieces a secrets platform needs: a machine identity model, hierarchical namespaces scoped by environment, path-pattern access policies, secret versioning, a CLI, pipeline integrations — and the feature no other vault has: continuous credential validation.
What makes it different#
Every secrets manager can store a credential. PulsVault continuously tests stored credentials so you know they still work — a stored token is known-working, not just stored. See Credential validation.
| Capability | What it gives you |
|---|---|
| Projects, namespaces & environments | A path scheme {project}/{env}/{namespace}/{secret} where the environment is a first-class, controlled vocabulary — not just a naming convention |
| Machine identities | Non-human actors (CI jobs, agents) holding rotatable, scoped pv_live_… bearer tokens — every key with a mandatory lifetime, an optional IP allowlist and a rate limit |
| Access policies | Path-pattern grants (acme-web/prod/**, */prod/**) with per-action scoping (read/write/list/rotate/delete) |
| Namespace grants | Direct read/write access for a person or team on one namespace, separate from machine policies (Team plans and up) |
| Versioning | Every write creates an immutable version; rollback and history are always available |
| Envelope encryption | A three-layer key hierarchy (master → per-namespace KEK → per-version DEK); no plaintext on disk |
| Credential validation | Scheduled probes that verify a secret still authenticates, with an alert state machine |
| CLI & pipelines | A single pulsvault binary, a GitHub Action, and a GitLab CI template |
Who can use it#
DevOps Secrets is available on the Developer (Solo Professional), Team, Business, and
Enterprise plans. In an organization, admins have full access; other members are granted the
secrets:* permissions they need. On the Developer plan, you own everything in your personal space.
See Paths, plans & roles for the full permission model.
Two planes: console vs. machine#
DevOps Secrets deliberately separates human management from machine access:
- Console (this app) — humans create namespaces, machine identities, keys, and policies, and configure validation. Authenticated by your normal login session.
- Machine data-plane — pipelines read and write secret values over
Authorization: Bearer pv_live_…. The console never reads secret values; a login session is rejected on the data-plane.
Humans manage access; only machines read values. This keeps plaintext out of screen-shares, scrollback, and browser memory. To consume a secret, issue an API key and use the CLI or pipeline integrations.
Where to go next#
- New here? Start with the Quickstart — first secret in CI in five steps.
- Understand the model: Paths, plans & roles.
- Set up the headline feature: Credential validation.