A **project** is one documentation property in Doxbrix. It has its own content, structure, branding, publishing settings, access rules, and localization setup. I...
A **project** is one documentation property in Doxbrix. It has its own content, structure, branding, publishing settings, access rules, and localization setup. I...
A project is one documentation property in Doxbrix. It has its own content, structure, branding, publishing settings, access rules, and localization setup. If your workspace contains several documentation experiences, each one should usually be its own project.
Common examples include:
- a public Product Docs site
- a private Internal Knowledge Base
- a support-focused Help Center
- a separate docs site for partners, admins, or developers
Separating these into distinct projects keeps navigation, permissions, analytics, and publishing workflows clean. It also makes it easier to assign ownership and governance at the right level.
Use the Dashboard as your project hub
The Dashboard is the operational home for projects in your workspace. It is where teams create new projects, review activity at a glance, and jump into the right editing or settings workflow.
At the top of the page, Doxbrix shows:
- the global search field, Search projects, docs, or settings…
- summary cards for Projects, Pages, Spaces, Articles, and AI Usage
Below that, the Projects area shows one card per project. Each card helps you understand the project quickly before opening it:
- visual identity through the icon and project name
- whether the project is public or private
- a short description, when one is present
- counts for pages and spaces
- actions to continue editing or manage configuration
The dashboard also surfaces editorial follow-up work through panels such as Drafts & needs attention and Publishing status. Those panels are useful once you have more than one project in flight, because they expose incomplete descriptions, lingering drafts, and publication gaps across the workspace.
Create a project deliberately
When you click New project, Doxbrix opens Create a new project. The setup flow is intentionally structured so teams can make foundational decisions before they start writing.
The page is organized into four sections and a Summary rail:
Choose whether the project should begin from a ready-made structure or from a blank starting point. Templates are useful when you want a strong first draft of your information architecture rather than an empty shell.
Doxbrix surfaces common options such as Blank, Help Center, API Documentation, Product Documentation, and Internal Knowledge Base. Use Search templates… to filter the list or Browse all to inspect the full gallery.
Define the visible identity of the project:
- Icon
- Project name
- URL slug
- Description
- Brand color
- Font family
These choices affect both workspace navigation and the reader-facing experience, so it is worth treating them as product decisions rather than temporary placeholders.
Configure how the project will be used:
- Visibility
- Editor mode
- Primary language
- Multi-language docs
This section determines who the site is for, how authors will work inside it, and whether the project needs to support more than one locale.
If your team plans to maintain the project as docs-as-code, connect Git during setup. If not, you can leave this unconfigured and return later when the workflow is ready.
Review the Summary rail, then click Create project. Doxbrix creates the project, applies the selected template if one was chosen, and opens the authoring workspace.
Every setting above can be refined later. The goal of the initial setup is not perfection. The goal is to create a well-named, well-scoped project that starts with the right structure and ownership model.
Know what belongs in project settings
Open Project settings when you need to change how a project behaves rather than what a page says. This is the administrative surface for project-level configuration.
The settings experience is divided into clear sections:
| Section | What you control |
|---|---|
| **General** | Core identity, visibility, and archive state for the project. |
| **Branding** | Reader-facing visual identity, including colors and typography. |
| **Localization** | Default language, enabled locales, locale labels, and locale structure behavior. |
| **Editor Configuration** | Editor mode, page template defaults, source mode defaults, and formatting behavior. |
| **Custom Domains** | Domain connection and verification for the published site. |
| **Publishing Controls** | Canonical behavior, indexing rules, sitemap behavior, preview path, and how unpublished pages behave. |
| **Reader Access** | Whether the site is public or private and how readers authenticate. |
| **Site Layout** | Whether the published site uses the classic docs layout or the help-center layout. |
| **Content Governance** | Ownership rules, reviewer defaults, review cadence, stale-content thresholds, and approval requirements. |
| **Git Sync** | Repository-backed docs-as-code sync for supported plans. |
| **API Tokens** | Project-scoped tokens for integrations and the CLI. |
This distinction is important: if a change should affect only one docs site, it belongs here. If it should affect the whole organization, it probably belongs in workspace settings instead.
Choose the right editor mode
Every project has an Editor mode:
- Block editor (default) — a structured canvas with the
/block palette - WYSIWYG editor — a document-style surface with a formatting toolbar
The choice does not change the value of the project. It changes the authoring experience. Teams that want structured, component-rich documentation usually prefer Block editor. Teams that want a simpler document-style flow may prefer WYSIWYG.
The same settings area also includes authoring preferences such as Source mode default, Smart quotes, Heading anchors, and Tighten lists.
Switch between projects without losing context
Inside the authoring workspace, use the project switcher in the top bar to move between projects in the same workspace. This is useful when one team maintains several doc sets at once and needs to compare structure, wording, or settings across them.
Archive or delete with care
Projects are long-lived documentation assets. Before deleting one, decide whether it should instead be archived.
- Archive is appropriate when the content should be preserved but removed from active delivery workflows.
- Delete project is appropriate only when the content and settings should be removed permanently.
Treat deletion as a final administrative action, not as a cleanup shortcut for inactive projects.