Workspaces, teams, and sharing
A workspace is where your OpenDocs content lives. It decides where a doc lives and who can see it.
Every workspace has a URL
Every workspace gets a slug, and every slug gets a URL:
opendocs.cc/acme-design
opendocs.cc/acme-engineering
opendocs.cc/my-side-project
The slug is yours — 3 to 32 characters, lowercase letters, numbers, hyphens, underscores. Pick something short and memorable. acme-docs beats acme-corp-internal-documentation-2026.
Every doc in the workspace gets a URL under it:
opendocs.cc/acme-design/brand-guidelines
opendocs.cc/acme-design/q2-roadmap
That's the link you share. Stable, readable, permanent. Readers don't need an account — they just click.
Private by default, public when you flip a switch
Every doc has a visibility level. There are three:
private— only you can see it. Draft mode.workspace(default) — everyone in your workspace can see it. Your team reads it, the public doesn't.public— anyone with the link. No login, no account.
Workspaces themselves follow the same default: private to members. Someone hitting opendocs.cc/acme-design who isn't signed in as a member gets nothing. Make the workspace public in settings and the same URL becomes a blog-style index of every public doc inside.
The showcase workspace you're reading right now (opendocs.cc/opendocs-hq) is the public version. Your engineering-runbooks workspace probably shouldn't be.
Inviting your team
From the dashboard: Settings → Team → Invite. Enter an email address.
The invitee gets an email, clicks through, sets a password, and they're in. Roles:
- Owner — the person who created the workspace. One per workspace.
- Admin — full control: invite, remove, change settings, change branding.
- Member — can publish, edit their own docs, see workspace-visibility content.
A single person can belong to many workspaces — their personal acme-consultant, the Acme team's acme-design, a community project's opendocs-hq. Switch between them from the CLI:
opendocs workspace list
opendocs workspace use acme-design…or from the dashboard dropdown.
Real-world sharing patterns
Three of the most common setups:
Internal-only team docs. Workspace default visibility. Invite the team. Every doc you publish is automatically team-readable and nothing leaks. Great for runbooks, architecture notes, internal postmortems.
Blog-style public publishing.
Workspace set to public. Docs you want in the "blog" published with --visibility public --confirm-public. Keep in-progress drafts at workspace visibility — they're invisible to the outside world but visible to your co-authors for review. When a draft is ready, flip it to public. The URL stays stable throughout.
Client deliverables.
Team plan. One workspace per client, or one workspace with per-client tagging. Keep drafts at workspace visibility while you collaborate internally, then publish the final version as a public link or export a branded PDF for readers who prefer a file.
The small stuff that matters
- Workspace bio — a short description for the workspace. It helps members and visitors understand what belongs here.
- Workspace logo — shown on the profile page, on every article card, and (Pro+) on PDF/DOCX exports.
- Brand color — applies to export accents and public article links. One hex value.
- Tags — workspace-wide. Every post can have tags; tags auto-appear in the sidebar Topics cloud and become filterable pages at
/your-workspace/tag/<tag>. Good for organizing a growing workspace.
None of this requires a redeploy, re-publish, or version bump. Change the branding, and the next PDF export picks it up. Change a tag, and the sidebar cloud recalculates on the next request.