Access Control
Choose how readers reach your docs: fully public, password-gated, mixed public/private, or SSO. Compare options and pick the one that fits your audience.
Jamdesk gives you four ways to control who can read your docs. Most teams pick one and stick with it; some mix and match.
Pick the right approach
| Approach | Use when | Setup |
|---|---|---|
| Fully public | External-facing product docs, open-source projects, anything you want indexed and shareable. | Default — no configuration. |
| Whole-site password | Everything is internal: engineering runbooks, partner-only docs, an unreleased product. One shared passphrase gates the whole site. | auth.password.enabled: true in docs.json + set password in dashboard. See Password Protection. |
| Mixed (some pages private) | Most docs are public; a handful are internal (a runbook, a beta feature, an internal API reference). | Add private: true to frontmatter on internal pages, or list them under auth.password.private[]. See Password Protection. |
| SSO (Enterprise) | Readers should sign in with your existing identity provider — no shared passwords, audit trail, deprovision-by-removing-the-user. | Enterprise plan. See SSO. |
You can switch between approaches at any time by editing docs.json and pushing. Switching from whole-site to mixed (or vice versa) takes one build.
Common patterns
Internal and external docs in one project
Most teams want extensive internal docs behind a login alongside a smaller public site for customers. You don't need two projects. Use mixed mode in a single Jamdesk project:
---
title: Incident Runbook
private: true
---Pages with private: true are gated; everything else stays public. One repo, one build, one dashboard. The unlock screen only appears when a reader hits a gated page.
For larger internal sections, list the paths in docs.json instead of marking each file. Note: auth.password.private[] activates specific-pages mode automatically. Don't add enabled: true alongside it (that's whole-site mode, the opposite of what you want here).
{
"auth": {
"password": {
"hint": "Ask the on-call engineer",
"private": ["/internal/**", "/admin/runbook"]
}
}
}Two separate projects
Use two projects only when the audiences need fully different branding, separate custom domains, separate analytics, or different plan tiers. Examples: a public docs site at docs.acme.com and a separate internal wiki at internal.acme.com. Maintenance cost is higher: two builds, two dashboards, two domains.
SSO for the docs site
On Enterprise plans, readers sign in with your identity provider (Okta, Google Workspace, Azure AD, etc.) instead of typing a shared password. Best fit when you need an audit trail of who read what, or when offboarding a user must immediately revoke their docs access. See SSO for the high-level overview and how to start a conversation with sales.
Editors vs readers
People sometimes confuse three different access concepts:
| Role | What they do | How access is granted |
|---|---|---|
| Editors | Write and update MDX content. | Docs are edited by committing MDX to your connected GitHub repo, so your GitHub repo permissions are the editor permissions. There's no separate Jamdesk editor role layered on top: anyone who can push to your docs branch can publish a change. |
| Readers | View the published docs site. | Everyone (public), anyone with the password (password mode), or anyone authenticated via your IdP (SSO). |
| Dashboard team members | Manage builds, analytics, and project settings in the Jamdesk dashboard. | Invited via Settings → Team in the dashboard. They don't author content directly. See Team Members. |
A teammate can be any combination of the three. They're independent axes.