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 documentation 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

Display publishes docs and files. Ask your agent:

"Publish the Markdown files in ./docs to Display for everyone at my company."

Each document gets a link, such as https://acme.dsp.so/0kzNYG7O-engineering-docs. Display renders the Markdown to HTML 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
      # Publish step: the job calls Display's REST API with a scoped API key
      # (DISPLAYDEV_API_KEY), or an agent publishes the changed Markdown files
      # to the links stored in your repo variables.

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 real-time co-editing and no Confluence-style page tree with drag-and-drop organization. Reviewers can leave inline comments on a published page, and your team can correct a single page with Edit. For docs built in CI, you still author the content in git, because the next build replaces edits made in the browser.

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