Team Knowledge Base
Run a shared knowledge base for a team: one server humans and agents write together, full version history, per-person or per-role write tokens, and open internal read access.
What you’ll have
- A shared server (VPS or internal host)
- Read access for the whole team: no auth required
- Write access controlled by capability tokens
- Full version history for accountability and rollback
- Everyone uses
demarkus-tuiordemarkusCLI to read and write
Architecture
Team server (mark://docs.internal.example.com)
├── /runbooks/ # ops runbooks
├── /decisions/ # architecture decision records
├── /onboarding/ # getting started guides
└── /projects/<name>/ # per-project docs
Each team member gets a personal publish token scoped to paths they own. A team lead token covers everything.
For a reading room, add --with-library to the Linux install. For single sign-on
and many worlds, use the knowledge-system chart.
Setup
1. Install the server
On a Linux host (VPS or internal):
curl -fsSL https://raw.githubusercontent.com/latebit-io/demarkus/main/install.sh | \
sudo bash -s -- --domain docs.internal.example.com --root /srv/team-docs
Or with your own certificates:
curl -fsSL https://raw.githubusercontent.com/latebit-io/demarkus/main/install.sh | \
sudo bash -s -- --tls-cert /path/cert.pem --tls-key /path/key.pem
2. Create initial structure
sudo mkdir -p /srv/team-docs/{runbooks,decisions,onboarding}
demarkus-publish -root /srv/team-docs -path /index.md -body "# Team Docs"
demarkus-publish -root /srv/team-docs -path /runbooks/index.md -body "# Runbooks"
3. Generate tokens
Team lead token (full access):
sudo demarkus-token generate \
-paths "/**" \
-ops publish \
-tokens /etc/demarkus/tokens.toml \
-label "team-lead"
The publish op grants all writes (PUBLISH, APPEND, and ARCHIVE) for the matched paths. There is no separate archive operation.
Developer token (scoped to their project folder):
sudo demarkus-token generate \
-paths "/projects/myproject/**" \
-ops publish \
-tokens /etc/demarkus/tokens.toml \
-label "dev-alice"
Restricting reads (optional):
By default all reads are open. A token with the read op gates its paths. To make /projects/secret/ and its descendants private:
sudo demarkus-token generate \
-paths "/projects/secret/**" \
-ops read \
-tokens /etc/demarkus/tokens.toml \
-label "secret-reader"
** includes descendants; * matches one path segment. Other paths stay read-open.
After generating tokens, reload:
sudo systemctl restart demarkus
4. Team members install client
Each team member runs:
curl -fsSL https://raw.githubusercontent.com/latebit-io/demarkus/main/install.sh | \
bash -s -- --client-only
5. Team members browse and publish
Browse:
demarkus-tui mark://docs.internal.example.com/index.md
Edit a document (opens $EDITOR, publishes on save):
demarkus edit -auth "$TOKEN" mark://docs.internal.example.com/runbooks/deploy.md
Publish directly:
demarkus -X PUBLISH -auth "$TOKEN" -expected-version 0 \
-body "# ADR 001: Use Demarkus for team docs" \
mark://docs.internal.example.com/decisions/001-use-demarkus.md
Set TOKEN to your raw token. -expected-version 0 creates a new document; use
the fetched version to replace one, or use demarkus edit.
6. View version history
demarkus -X VERSIONS mark://docs.internal.example.com/runbooks/deploy.md
Fetch a specific version:
demarkus mark://docs.internal.example.com/runbooks/deploy.md/v3
Tips
- Scope tokens narrowly: per-person or per-directory
- Use
-labelwhen generating tokens for audit clarity demarkus-tuigraph view (dkey) shows document relationships- Archive keeps history; explicit retention can prune older versions
Related
- Install a knowledge system: many worlds with single sign-on
- Install on Linux
- Public hub scenario
- Organizational knowledge system: the next tier up