Adapters

An adapter tells Briter where content lives and where it goes when published. The adapter is chosen during setup and can be changed in Settings.

local-mdx (default)

Briter is the blog. Posts live in content/posts/ and Briter's built-in reader serves them at /posts/<slug>. RSS, sitemap, and SEO metadata are generated automatically.

Use this when: You want Briter to be your blog. Readers visit your Briter instance.

No additional configuration required.

git-target

Briter pushes content into a separate git repository — a sibling static site — instead of serving it itself. Briter is the editor; your existing site is the reader.

Use this when: You already have a site and want to keep its frontend while gaining Briter's writing experience.

Configuration. The git-target adapter writes posts as .mdx files. Where it commits and pushes is governed by the worktree/branch/remote runtime config (set in the wizard's git step or via environment variables — see the Configuration Reference):

Setting	Env var	Description
Worktree path	BRITER_GIT_WORKTREE	Absolute path to the external repo on the same filesystem
Branch	BRITER_GIT_BRANCH	Branch the worker commits to and pushes (default main)
Remote	BRITER_GIT_REMOTE	Remote the worker pushes to (default origin)
Commit author	BRITER_GIT_AUTHOR_NAME / BRITER_GIT_AUTHOR_EMAIL	Identity on sync commits
Published URL template	BRITER_PUBLISHED_HREF_TEMPLATE	e.g. https://<your-domain>/notes/{slug}, used to build "view published" links

Path security. Before staging, the git-sync worker validates every file path against the adapter's allowed-path list (getAllowedPaths()). The git-target adapter permits only paths under content/ and public/uploads/; anything outside is never committed. See Worker & Queue for how validation fits into job processing.

Briter's content directory is content/posts/ and section JSON lives under content/sections/ — both fall under the allowed content/ prefix, so they ride the same git-sync. See Sections.

Switching adapters

Go to Settings → Adapter. Change the adapter and save. Briter rewrites storage/config.json. Posts already committed to the old adapter's target are not moved automatically.

v1 constraints

• The external repo must be on the same filesystem as Briter (or mounted into the same Docker volume). HTTP-based git push via the GitHub API is not in v1 — this is a settled decision ("External worktree must be local filesystem").
• One external repo per Briter instance.
• The git-target adapter writes .mdx. Configurable per-site frontmatter presets and a revalidate webhook are not implemented today; see the Roadmap.