DevDocs Portal

Getting Started

The fastest way to understand the DevDocs split between the docs surface and the operator control plane.

The first task is simple: understand where readers go and where operators go. The public docs site should stay welcoming and polished, while the control plane stays focused on management workflows.

Start with the two surfaces

SurfaceAudiencePurpose
devdocs.devReaders, reviewers, stakeholdersBrowse docs, inspect previews, read product guidance
admin.devdocs.aiOperators and customersManage sites, previews, domains, and publishing workflow

Use the docs shell as the public face

The docs app is where we should show clarity, navigation quality, and content depth. It is the best place to demonstrate the pieces that matter to a buyer or reviewer:

  • the section selector at the top of the sidebar
  • a meaningful hierarchy of pages and subsections
  • readable long-form pages with a sticky right-side TOC
  • branded but still familiar Fumadocs styling

No login in the docs UI

The docs portal should stay focused on reading and review. Authentication belongs in the admin control plane, not in the public docs shell.

Initial operator flow

Open the docs site

Use the public docs app to review navigation, structure, and the current documentation surface.

Move into the admin portal only when you need control-plane work

Operators switch to admin.devdocs.ai for provisioning, preview management, and domain changes.

Review the proof loop before promotion

Promotion should only happen after preview review, proof artifacts, and post-merge verification all line up.

Pick the right section in the docs nav

Use this section for the story readers need first: overview pages, architecture, and authoring guidance.

Use this section for preview-safe deployment rules, promotion proof, and domain orchestration details.

Use this section to verify the docs shell actually shows off cards, tabs, callouts, steps, and polished link treatment.

Read these next

Common confusion

On this page