The Shared project
A protected, automatically-created project that holds the secrets every other project needs — so you store an organization-wide key once instead of copying it into every project.
When you turn on DevOps Secrets, PulsVault automatically creates a second project called
shared. You didn't make it, and you can't delete or rename it — that is on purpose. This page
explains what it is for and why it behaves the way it does.
The idea in one sentence#
shared is a common drawer that all of your projects can read from. You put a secret there once,
and every project can use it — instead of copying the same secret into every project by hand.
Why it exists#
Some secrets are needed by every project: a monitoring key, container-registry credentials, a shared API token. If each project kept its own copy, you would have the same secret in many places — and every time it changed, you would have to remember to update all of them. Miss one, and that project breaks.
shared gives that secret a single home.
You use Datadog for monitoring, and you have three projects — acme-web, acme-api, and
acme-jobs. All three need the same Datadog API key.
- Without
shared: you paste the key into all three projects. When the key is rotated, you must update it in three places. Forget one, and that pipeline fails. - With
shared: you store the key once inshared. All three projects read it from there. When it changes, you update one place.
The three badges you see on it#
| Badge | What it means |
|---|---|
| shared | The project's name. |
| devops | Its DevOps secrets plane is switched on, so it can hold machine secrets. |
| reserved | PulsVault created and protects this project — you can't rename, delete, or recreate it. |
Why you can't change or delete it#
shared is protected because other things depend on it existing:
- You can't delete or archive it. Every project reading a secret from
sharedwould break the moment it disappeared. The Settings tab hides the archive action for this project for exactly this reason. - You can't create your own. The names
sharedandsystemare reserved, so no one can make a second project that impersonates the common drawer.
That is all the reserved badge means: this project is a fixture, not yours to remove.
The one rule worth knowing: read, don't write#
Your projects can read from shared, but a project's automated credentials cannot write to
it.
Imagine one project's CI pipeline is compromised, or simply has a bug. If it could write to
shared, it could overwrite the Datadog key — and now every project that reads that key is
broken, not just the one with the problem. Read-only access keeps a fault in one project from
spreading to all of them.
If you genuinely need to change a secret in shared, you do it yourself as an administrator — or
from a machine identity that belongs to shared itself. Never from another project's pipeline.
The rule has exactly one shape and no exceptions:
Writes to
sharedcome only from machine identities pinned toshared. Every other identity — pinned to another project, or pinned to none at all — getsreadandlist, and nothing else.
That covers write, delete and rotate alike. Re-keying a secret is a write by another name, and
deleting one breaks every reader just as thoroughly as overwriting it.
If a pipeline genuinely needs to publish an organization-wide secret — rotating that monitoring key on a
schedule, say — create a machine identity pinned to the shared project and give it that job
alone. It is the one identity allowed to write there, which is what makes it easy to review: one
machine, one purpose, and everything else in the organization is a reader.
Only an organization administrator can create a machine identity pinned to shared — it can publish
secrets every project reads, so it is an organization decision, not a project one.
Where to go next#
- Namespaces — how secrets are organised inside a project
- Access policies — how you grant a machine read-only access to
shared - Machine identities — the machines that read secrets