CLI
Run a documentation site from a config file and a folder of Markdown.
On this page
ZenithDocs can be used two ways. As an Astro integration, inside a project you control, or through its CLI, which needs no Astro project at all:
my-docs
content
zenith devNo astro.config.mjs, no content.config.ts, no src directory. npx github:AymericChaverot/zenith-docs create my-docs sets up exactly this layout, ready to run.
| Command | What it does |
|---|---|
zenith create |
Creates a new site in a directory, see installation |
zenith dev |
Starts the development server |
zenith build |
Builds the site into dist/ |
zenith preview |
Serves the built site |
zenith init |
Creates a config file and a first page |
zenith docker |
Adds a Dockerfile, see deployment |
dev and preview accept --port, --host and --open. Every command accepts --help.
zenith.config.ts exports the same options as the integration, plus site and base, which the integration reads from astro.config.mjs instead.
import { defineConfig } from 'zenith-docs/config';
export default defineConfig({
title: 'My Docs',
site: 'https://docs.example.com',
accent: 'violet',
});Pages are read from content/ unless docsDir says otherwise. public/ is served as-is if it exists, and the build lands in dist/.
Astro needs a couple of files that this layout does not have, so the CLI writes them into .zenith/ and rewrites them on every run:
.zenith
pages
The directory ignores itself in git, so there is nothing to add to your .gitignore. Editing anything in it is pointless: the next command overwrites it.
Use the CLI when the site is only documentation. Use the integration as soon as you want the rest of Astro: your own pages and routes, other integrations, framework components, or a landing page in front of the docs.
Moving from one to the other is mostly mechanical: create an astro.config.mjs with the integration, move zenith.config.ts into it, and add the content.config.ts that the CLI was generating for you.