Share Internal Docs Without Confluence

The Confluence problem

Confluence is documentation software for teams that want to write documentation in Confluence. If your team already lives in Confluence, maintains a page tree there, and uses Confluence's editor as the authoring workflow, this post isn't for you.

But many engineering teams use git as their knowledge base. READMEs, ADRs (Architecture Decision Records), runbooks, API contracts, onboarding guides all live in Markdown, versioned in the repository, reviewed via pull requests.

The audience for this documentation often extends beyond engineering: PMs read the ADRs, DevOps reads the runbooks, new employees follow the onboarding guides. These readers don't have GitHub access. Even with GitHub access, reading raw Markdown in a browser is a poor experience.

Confluence is the traditional answer. But Confluence requires:

• Manually copying or syncing content from git to Confluence
• Maintaining two sources of truth (the Markdown in git, the page in Confluence)
• Per-seat licensing ($5–6/user/month at the Standard tier)
• An editor that strips code formatting and breaks technical content

A simpler path

If you have a documentation directory in your repository:

docs/
├── architecture/
│   ├── overview.md
│   └── decisions/
│       ├── adr-001-database.md
│       └── adr-002-api-design.md
├── runbooks/
│   ├── deployment.md
│   └── incident-response.md
└── onboarding/
    └── new-engineer.md

dsp publish ./docs/ --name "engineering-docs"

display.dev renders the Markdown to HTML, creates navigation, and serves it at a company-authenticated URL. Non-engineers click the link, authenticate with their company email, and read rendered documentation with syntax-highlighted code blocks, formatted tables, and working internal links.

Auto-publish when docs change

on:
  push:
    branches: [main]
    paths: ['docs/**']
 
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Publish docs
        run: |
          npm install -g @displaydev/cli
          BASE_VERSION=$(dsp get "${{ vars.DISPLAY_ARTIFACT_ID }}" | jq -r .currentVersion)
          dsp publish ./docs/ --id "${{ vars.DISPLAY_ARTIFACT_ID }}" --base-version "$BASE_VERSION"
        env:
          DISPLAYDEV_API_KEY: ${{ secrets.DISPLAYDEV_API_KEY }}

Docs update whenever the Markdown changes on main using the artifact ID stored in DISPLAY_ARTIFACT_ID. Git is the source of truth. The Confluence page tree stays empty.

What this doesn't give you

display.dev is a publishing layer, not a documentation platform. There's no editor, no collaborative authoring, no Confluence-style page tree with drag-and-drop organization, no inline comments on documentation pages.

For teams that need those features (editorial workflows, non-git authoring, content management for non-technical writers), Confluence or Notion is appropriate.

For teams that author in git and need a non-engineer-readable URL for the output, display.dev is a lighter and cheaper path.

Pricing comparison