How Dokly works

The architecture in one page: how content is stored, rendered, and served.

If you're going to depend on Dokly for your docs, you should know how it works. Here's the model in one page.

The mental model#

Every Dokly project is three things:

  1. A subdomain (e.g., acme.dokly.co) and optionally a custom domain (e.g., docs.acme.com).
  2. A tree of pages — each page has a slug, a title, and MDX content. Pages can be nested.
  3. Branding settings — logo, primary color, social card, dark/light defaults.

The dashboard at dokly.co/dashboard is where you write and configure. The public site at your subdomain is where readers go.

What that means for you#

  • No deploys. Editing is publishing. There's no preview branch, no PR review, no CI queue.
  • No local environment. Everything happens in your browser. (You can still version-control MDX externally if you want — see Migration.)
  • Fast pages, always. The reader hits a CDN-cached static page, not a database query.
  • Search is client-side. Search runs in the browser using Fuse.js — instant results, no API calls.

The components are real React#

Dokly's MDX components (Callout, Tabs, Steps, Card, APIPlayground, etc.) are React components rendered by Next.js. That means:

  • They're styled, accessible, and dark-mode aware out of the box.
  • The same components render in the editor preview and on the live site, so what you see is what readers get.
  • You can't add arbitrary React components from outside the platform — you're limited to the built-in set. This is intentional: it keeps your docs portable and prevents your build from breaking.

The full list of available components is in Components → Overview.

Data and ownership#

  • Your content lives in our managed Postgres service.
  • You can export every page as MDX from Settings at any time. There's no lock-in.
  • Free-tier projects sit on the same infrastructure as Pro projects — no degraded performance.

Where to dig in next#