Use it for your own docs

Clone FeastDocs, point it at your own repository, and publish.

FeastDocs is a template as much as a product: clone it, make the repository yours, replace the content. Everything specific to a site lives in two places — feastdocs.config.mjs and the docs/ folder.

1. Make the repository yours 

git clone https://github.com/example-org/feastdocs my-docs
cd my-docs

Point the clone at your own repository (create an empty one on GitHub first):

git remote set-url origin https://github.com/your-org/my-docs.git
git push -u origin main

Prefer a clean history? Delete the .git folder and git init instead.

npm install
npm start

http://localhost:4200 now serves the template's own documentation — which you are reading. It doubles as your feature reference until you replace it.

2. Configure the site

Everything is in feastdocs.config.mjs:

feastdocs.config.mjs
export default {
  title: 'My Product Docs',
  tagline: 'Everything about My Product.',

  theme: {
    defaultMode: 'dark',
    accent: '#2f6fdb',
    accentDark: '#6ba1f4',
  },

  // "Edit this page" links on every page:
  editUrl: 'https://github.com/your-org/my-docs/edit/main/docs/',

  // Web editing: lets the content manager commit to your repo:
  github: {
    repo: 'your-org/my-docs',
    branch: 'main',
  },
};
owner/name of your repository. Setting it enables the GitHub mode of the content manager — editing on the deployed site, committing as the signed-in GitHub user. Branch that web edits are committed to. Base URL for "Edit this page" links; the file's path inside docs/ is appended.

3. Replace the content

Delete the template's sections and write your own — every top-level folder in docs/ becomes a navbar tab (Pages & sections):

docs/
├── index.md              your landing page
├── getting-started/
│   ├── _section.json     { "label": "Getting started", "position": 1 }
│   └── index.md
└── api/
    ├── _section.json     { "label": "API", "position": 2 }
    └── index.md

Keep one copy of the template docs

Before deleting, skim this Guide and Reference — or keep them around in a draft: true state while your team learns the features.

4. Deploy

npm run build produces static files in dist/feastdocs/browser/. Any static host works; the one rule is that unknown paths must fall back to index.html.

The repository ships a ready workflow at .github/workflows/ci.yml: it builds and tests every push and pull request, keeps the built site as an artifact, and can deploy to Cloudflare Pages on pushes to main.

To enable the Cloudflare deploy, create the Pages project once and add two repository secrets (Settings → Secrets and variables → Actions):

Secret Where it comes from
CLOUDFLARE_API_TOKEN Cloudflare dashboard → API tokens, with the Cloudflare Pages — Edit permission
CLOUDFLARE_ACCOUNT_ID Cloudflare dashboard → Workers & Pages (right sidebar)

Without the secrets the deploy job skips itself, so the workflow is safe to keep even if you deploy some other way.

SPA routing on Cloudflare Pages

No extra configuration needed: the build emits no top-level 404.html, and in that case Cloudflare Pages automatically serves index.html for unmatched paths — exactly what the client-side router requires.

Prefer deploying from the workflow

Cloudflare's own Git-integration builder can clone the repository shallowly, which blanks out the "last updated by" authors (they are read from git history at build time). The workflow checks out with fetch-depth: 0, so deploying from it keeps attribution intact.

5. Optional: "Sign in with GitHub" for web editing

Web editing works out of the box with personal access tokens. For a real OAuth login button, three steps (the exchange function already ships in functions/):

  1. Create a GitHub OAuth App (Settings → Developer settings → OAuth Apps) with callback URL https://your-site/_editor.
  2. Set github.oauthClientId in feastdocs.config.mjs to the app's client id.
  3. Add GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET as secrets on the Cloudflare Pages project (Settings → Variables and secrets).

Editing rights are always the repository's collaborator permissions — GitHub enforces them on every commit, whoever is signed in.

6. Choose how people edit

Both strategies work at the same time; see the content manager for the full picture:

Strategy Who it fits How it commits
Git push People with a code editor and git They edit docs/, commit, push — normal review flow
Web editing People who live in the browser The content manager commits to github.repo as their GitHub user

Either way the history is git, so "last updated by" under every page stays truthful — it is read from the commits at build time.