Why JamDocs keeps secrets next to runbooks

A runbook is a promise to whoever gets paged next: follow these steps and the system comes back. Most runbooks break that promise at the same place. Step three says “point the app at the new primary,” and the connection string lives somewhere else.

So the person on call leaves the doc. They open a password manager, or search chat for the last time someone pasted it, or wake up the one teammate who knows. The steps were correct. The path to the credential was not.

The two usual answers both fail

The first answer is to paste the secret into the page. It is fast, and it is the reason security teams dislike wikis: the value sits in plain text, visible to everyone who can read the space, copied into every export and every page history.

The second answer is to keep secrets in a separate tool and link to it. That is safer, but the link points at a vault entry that someone renamed last quarter, and the reader still has to switch tools in the middle of an incident.

What JamDocs does instead

In JamDocs the secret is a vault entry referenced inline, at the step that needs it. The reader sees the path, for example db/prod/primary-url, and a masked value.

• Encrypted at rest. Vault values are stored with AES-256.
• Revealed by role. The reveal follows the same roles as the rest of the workspace. Someone without the right role sees that a secret exists and where it is used, not its value.
• Private by default. A new space or document is visible to no one until it is shared.
• Recorded. The workspace audit log records access and changes, and admins can review and export it.

The runbook stays readable by everyone who should follow it, and the credential stays limited to the people who should use it.

Keeping the runbook itself current

A secret beside the step only helps if the step is right. Two other parts of JamDocs keep it right. GitHub smart folders sync a repository path into a space, so runbooks that live next to the code follow the latest commit on main. And the realtime sync engine lets two people edit the same runbook during an incident without overwriting each other.

Where this is going

The vault and smart folders are on the Standard and Pro plans. Single sign-on and SCIM provisioning are planned for Enterprise and are not available yet; we will say so here when they are.

If your runbooks currently say “ask someone for the password,” JamDocs is free for teams up to five members.