Skip to content
CoralDoc alpha Join waitlist

---
scope: entire organization
format: plain markdown · yours
status: multi-tenant · alpha
---

One knowledge base for the entire organization

CoralDoc unifies engineering docs, handbooks, specs, and runbooks — wherever they're stored — into one searchable, AI-native knowledge base. Every page stays a plain Markdown file your organization owns.

Join the early waitlist See how it works →

Self-hosted and cloud · no per-seat pricing · no proprietary format

org knowledge — connected sources 6 live

acme-corp/

  • ●Platform/→ git · services/*
  • ●Payments/→ github · payments-org
  • ●Engineering handbook/→ vault · .obsidian
  • ●Product specs/→ s3 · specs-bucket
  • ●Runbooks & oncall/→ git · sre-docs
  • ●Compliance archive/→ azure blob

## one shell · many origins · one graph

search · backlinks · RBAC · AI over all of it

Six storage locations. One search box, one permission model, one corpus your assistants can read.

section: the format

Every source. One format. Real Markdown.

Unification only works if everything shares a format — and it has to be a format your people, your editors, and your models already speak. Not a rich-text JSON blob. Not a watered-down dialect. A .md file.

runbooks/deploy-rollback.md — Monaco
--- title: Deploy rollback runbook tags: [runbook, sre, cloud-run] ---   # Deploy rollback runbook   If a release degrades p99 latency, roll back to the previous revision. See [[oncall-guide]].   ## Escalation flow   ```mermaid flowchart LR Alert --> Triage --> Rollback ```   ```bash gcloud run services update-traffic api \ --to-revisions=api-00041=100 ```
live preview · from git 2 comments · ⭐ starred

Deploy rollback runbook

#runbook#sre#cloud-run

If a release degrades p99 latency, roll back to the previous revision. See oncall-guide.

Escalation flow

Alert Triage Rollback 
gcloud run services update-traffic api \
  --to-revisions=api-00041=100

Related across sources

  • git ADR-014 Event pipeline
  • vault Oncall escalation handbook
  • s3 Incident postmortem template

The file on the left is a real .md — open it in VS Code, Obsidian, vim, or your CI pipeline. The backlinks on the right cross three different storage providers.

pillars: unify · own · accelerate

Built as a unified knowledge base — not a wiki bolted on later

unify: every source

One home for org knowledge

Engineering docs in Git, product specs in object storage, team notes in Obsidian, handbooks, ADRs, runbooks — connected under hierarchical projects with org-wide search, backlinks, and permissions. Stop hunting across five tools for the same answer.

own: everything

Content you still own

Plain .md and .canvas files with YAML frontmatter, in storage you control. No proprietary database. No export tax. Back up, grep, and migrate with tools you already have.

ai: native

AI-native by design

Markdown is what LLMs read and write best. Your whole knowledge graph is usable by RAG pipelines, coding assistants, and agents — plus an integrated AI Writer and REST API for org-scale workflows.

section: sources

Many sources. One knowledge base.

Organizations don't keep knowledge in one place — and they shouldn't have to move it all into a vendor database to collaborate on it. CoralDoc connects to the storage your content already lives in and puts one shell around it.

git / github

Engineering repos

ADRs, READMEs, and service docs colocated with code — auto-commit, attribution, and history that matches the systems they describe.

obsidian vault

Team vaults

Point at a folder containing .obsidian/ — wikilinks, callouts, and canvas boards carry over. Local thinking, org-wide sharing.

s3 / azure blob

Object storage

Compliance archives, product specs, and long-lived document sets — in the buckets your security team already reviewed and approved.

local disk

Working drafts

Fast iteration on disk for in-progress work, without pushing half-finished thinking into a repo everyone watches.

mixed per project

Compose freely

Git for services, S3 for compliance, a vault for product — simultaneously, under one tenant, with a hierarchy that matches your org.

on the roadmap

Confluence import

A Confluence-to-Markdown converter, so leaving a proprietary database is a file copy rather than a migration project.

// to be precise

CoralDoc connects to storage backends — Git, GitHub, S3, Azure Blob, local disk, Obsidian vaults — not to other SaaS products' APIs. Your files stay in your storage and CoralDoc reads and writes them in place. It isn't a connector layer that indexes Notion and SharePoint and leaves your content where it is; it's the system of record for content you keep in formats and locations you control.

section: agent workflows

Your AI workflows already write Markdown

Spec-driven development produces artefacts, and those artefacts are plain files in your repo — proposals, PRDs, architecture, stories, task lists. They're the highest-value documents your team writes and the least visible: buried three folders deep, readable only by whoever clones the repo.

CoralDoc reads those folders in place. Nothing to integrate, no plugin, no export step. The files stay exactly where your agent expects them.

OpenSpec spec-driven development
openspec/ ├── specs/ ← the spec library │ ├── auth/spec.md │ └── billing/spec.md └── changes/ ├── add-sso-login/ │ ├── proposal.md │ ├── design.md │ ├── tasks.md │ └── specs/auth/spec.md ← delta └── archive/

what CoralDoc adds

  • +The spec library becomes a browsable capability index — not a folder you have to cd into
  • +Proposals get line-anchored comments and @mentions before the agent starts building
  • +Spec deltas render as diffs beside the spec they change
  • +A platform team's specs are readable from every other project — scoped read-only, no cloning
  • +Archived changes stay searchable, so "why did we do it this way" has an answer
BMAD Method agentic agile
docs/ ├── brief.md ├── prd.md ← PM agent ├── architecture.md ← Architect agent ├── epics/ │ └── epic-002-checkout.md ├── stories/ │ ├── story-014-guest-checkout.md │ └── story-015-payment-retry.md └── sprint-status.yaml ← SM agent

what CoralDoc adds

  • +PRD and architecture become readable by people who will never open a repo
  • +Story frontmatter drives tags and filters — a board view over the files themselves
  • +Architecture diagrams render from Mermaid and DBML instead of pasted screenshots
  • +Agent personas are Markdown too — version them, review them, share them across teams
  • +Retrospectives and epics keep their history instead of scrolling out of a chat window

// and everything shaped like them

Spec Kit, Kiro, AGENTS.md, CLAUDE.md, ADR templates, your own house convention — CoralDoc doesn't know or care which one you picked. It reads directories of Markdown. If the convention changes next quarter, the knowledge base doesn't need to change with it.

OpenSpec and BMAD Method are independent open-source projects. CoralDoc neither requires nor is affiliated with them — it just reads the files they produce.

section: use cases

One knowledge base, five different jobs

Unified doesn't mean everyone uses it the same way. Pick the seat you sit in.

the problem

Service docs rot because they live somewhere the code doesn't. An ADR written in a wiki is invisible during code review, and nobody updates it when the decision changes.

with CoralDoc

  • ✓ADRs, READMEs, and service docs stay in the repo, edited in the same PR as the code
  • ✓One sub-project per repo under a domain root — no monolithic wiki space
  • ✓Schema and sequence diagrams as DBML and Mermaid, diffable line by line
  • ✓Coding assistants read the same docs the humans do, straight from the working tree
# Platform/api-service/ adr-014-event-pipeline.md → git deploy-rollback.md → git orders-schema.md → dbml   # linked from ← 6 pages across 3 projects

section: structure

Structure knowledge the way your organization already works

Large companies don't keep everything in one wiki space — and they shouldn't. Model each domain — Platform, Payments, Product, People — as a top-level project holding cross-cutting docs, with sub-projects for repos, vaults, or archives underneath.

Each sub-project is a full content root — its own storage provider, path, comments, and permissions. The parent is organizational glue, not a forced merge of every source into one tree.

A domain isn't a special type: it's just a project that happens to have children. It holds its own pages, has its own provider and grants, and any project can become a parent later — or stay flat. That's the difference between a wiki space that grew forever and a hierarchy someone can navigate.

tenant: acme/
├── Platform/ ← ADRs, cross-cutting runbooks │ ├── api-service/ → git: services/api │ └── web-app/ → git: apps/web ├── Payments/ ← PCI docs, payment flows │ ├── billing-worker/ → git: workers/billing │ └── archives/ → s3: compliance/ ├── Product/ ← specs, research │ └── vault/ → local: ~/product-vault └── handbook/ ← flat is fine too   ## every project — parent or child: own pages · own storage · own permissions · own comments

Grants stay per project. Hierarchy organizes; it never collapses access control.

section: ownership

The exit is the feature

Every knowledge tool is easy to adopt. The question worth asking during evaluation is what happens the day you leave — or the day the invoice arrives with a per-seat increase and a renewal deadline attached.

With CoralDoc there's nothing to extract, because nothing was ever converted. Pages are .md files. Boards are .canvas files in the open JSON Canvas format. Comments are files beside the pages they annotate. Metadata is YAML frontmatter. All of it sits in storage your organization already owns and already backs up.

Your knowledge base shouldn't cost more because your organization grew, and it shouldn't be held hostage because you stopped paying.

migrating off coraldoc
$ git clone git@github.com:acme/platform-docs.git $ ls platform-docs/runbooks deploy-rollback.md oncall-guide.md system-map.canvas _comments/   # that's the whole migration. # no export job. no support ticket. # no conversion script. no CSV of your own words.

The same command works on day one, on day one thousand, and on the day you leave.

section: features

Enterprise collaboration on a file-first foundation

Everything an organization expects from a modern knowledge base — stored as files you control, not rows in a vendor's database.

editors/

Three editor modes

Monaco (VS Code's engine), WYSIWYG (Tiptap), or plain textarea — switch anytime, with side-by-side live preview and draft recovery when the network drops.

collab/

Comments, mentions, backlinks

Line-anchored comments with threaded replies, @mentions, tags, favourites, and a "linked from" panel — stored as Markdown files alongside your pages.

access/

Multi-tenant RBAC that scales

Tenant isolation from day one. Groups, custom roles, and scoped grants at project, folder, and page level — across every connected source.

history/

Git-backed audit trail

Auto-commit on every save with author attribution. Browse revisions, diff side-by-side, and restore — docs can sit in the same repo as the systems they describe.

canvas/

Native JSON Canvas

Create and edit .canvas boards in the browser — nodes, edges, groups, pan and zoom. The same open format Obsidian uses, not view-only.

render/

Technical content that works

Mermaid, DBML, Scalar/OpenAPI, in-browser PDF embeds, and syntax highlighting for 100+ languages — with a plugin SDK for PlantUML, GraphQL, or your own fence types.

render/ — spotlight

Diagrams that search, diff, and feed AI

A PNG of last year's schema tells you nothing about what changed or why, and it never appears in org-wide search. Describe the schema in DBML or a flow in Mermaid inside an ordinary code fence and it renders live — versioned line by line, greppable across the whole knowledge base, and directly readable by the assistants your engineers already use.

Change a column, see the diff, re-render. Try that with a screenshot.

```dbml Table orders { id uuid [pk] customer_id uuid [ref: > customers.id] status order_status } Table customers { id uuid [pk] email text [unique] } ```

renders as ↓

orders

id · uuid 🔑

customer_id · uuid

* ──── 1

customers

id · uuid 🔑

email · text ◆

section: migration

Review the diff

Most organizations run Confluence plus Notion plus SharePoint plus a few GitHub wikis, and still can't answer "where is the source of truth?" Here's what changes.

org-knowledge.patch −9 +9

@@ your-organization @@ migrate: fragmented tools → unified knowledge base

-knowledge scattered across Confluence, Notion, drives, and wikis

+one knowledge base spanning Git, vaults, and object storage

-proprietary formats locked inside a vendor database

+plain Markdown + JSON Canvas with YAML frontmatter — portable forever

-"AI for docs" that only sees one tool's incomplete export

+AI-native: one corpus LLMs, RAG, and agents can use end to end

-diagrams as screenshots or third-party plugins

+native Mermaid, DBML, and editable canvas — greppable and model-readable

-API docs, runbooks, and handbooks in separate products

+OpenAPI, runbooks, ADRs, and handbooks in one navigable hierarchy

-page history locked in; export is a project

+in-app diff and restore, plus Git auto-commit with attribution

-one sprawling space per team that fragments or grows forever

+hierarchical projects: domain roots + sub-projects, each with its own storage

-inconsistent permissions in every tool

+tenant RBAC + groups + project/folder/page scoped grants

-per-seat pricing that scales with headcount, across multiple vendors

+no per-seat tax — your knowledge base shouldn't cost more because your org grew

Already on Confluence or Notion? CoralDoc can coexist — start with one domain or one team. Unification is connecting sources and copying Markdown, not a big-bang rip-and-replace.

section: your tools

Your tools are already CoralDoc clients

Because pages are plain files, there's no plugin to install and nothing proprietary to sync. Keep Obsidian for thinking. Keep VS Code, Cursor, JetBrains, or vim for editing next to the code. Changes land in CoralDoc with full attribution and history — and coding assistants read those same runbooks and ADRs straight from the repo.

~/vaults/team-knowledge/
├── .obsidian/ ← auto-detected ├── architecture/ │ ├── adr-014-event-pipeline.md │ └── system-map.canvas ← editable in browser ├── runbooks/ │ ├── deploy-rollback.md │ └── _comments/ ← comments are files too └── specs/ └── vendor-api-v2.pdf ← ![[embeds in-page]]

Point CoralDoc at a folder containing .obsidian/ and it just works — wikilinks resolve, callouts render, PDF embeds open in-page.

$ activity · across the knowledge base
a3f91c2 Update ADR-014 decision status · CoralDoc web · mei 9d4e77b Fix rollback steps in runbook · VS Code · rob 71c0aa8 Refactor API docs beside code · Cursor · sam c58d210 Draft DBML schema for orders · AI Writer · agent 2b7f4e9 Typo sweep across handbook · Obsidian · priya

One knowledge base, five editors and one agent — no sync layer required, because it's just files.

section: get started

Unify in days, not quarters

  1. 01

    Stand up CoralDoc — self-hosted on your infrastructure, or managed cloud when you'd rather not run it.

  2. 02

    Create a tenant for your organization and invite teams with roles that match how you already work.

  3. 03

    Connect sources — Git repos, Obsidian vaults, S3 or Azure archives — nested under domain projects.

  4. 04

    Write and collaborate: comments, canvas, Mermaid, OpenAPI, and the AI Writer across the whole graph.

  5. 05

    Point your assistants and agents at the same files — one knowledge layer for people and models.

zsh
$ docker compose up coraldoc | Now listening on: http://localhost:9000 coraldoc | Tenant "acme" ready. coraldoc | + project Platform → git://services/* coraldoc | + project Product vault → ~/vaults/product coraldoc | + project Compliance → s3://acme-compliance/ coraldoc | 3 sources unified · search ready

A preview of the self-hosted install. The public Docker image isn't out yet — it ships with the open alpha, and waitlist members get it first.

who it's for today

  • ✓Teams whose docs already live in Git, vaults, or object storage
  • ✓Organizations that need content ownership for compliance or procurement reasons
  • ✓Anyone building RAG or agent workflows over internal knowledge
  • ✓Early adopters happy to shape a product in alpha

not yet

  • ×Public Docker image and managed cloud — both in progress
  • ×Microsoft and Google SSO — GitHub SSO and email sign-in work today
  • ×Automated Confluence import — bring Markdown by hand for now
  • ×A support SLA. It's alpha, and priced accordingly.
"Your organization shouldn't need five tools to find one answer. Your knowledge shouldn't be locked where AI can't reach it."
Join the early waitlist Explore connected sources

section: roadmap

Shipping next

CoralDoc is in alpha and actively developed. In rough order:

  • [ ]

    Public Docker image

    One command to a running knowledge base — docker compose up and you're writing.

  • [ ]

    Cloud hosting — app.coraldoc.com

    Same platform, zero ops. Your content stays plain files you can take with you.

  • [ ]

    Microsoft & Google SSO

    Joining GitHub SSO and email sign-in — enterprise identity for org-wide rollout.

  • [ ]

    Confluence-to-Markdown converter

    Make leaving the proprietary database a file copy, not a migration project.

list: early access

Join the early waitlist

Be first to hear when CoralDoc launches, and first to get the Docker image. Occasional product updates along the way. No spam.