Skip to main content

​
Configuration overview

ZAR reads configuration from two places:
  1. A .zar.yml file in your repository root — version-controlled, reviewed in PRs, lives with the code.
  2. The dashboard / database — per-repo settings you toggle at app.zarlabs.tech.
Some settings exist in both; some only in one. This page explains who wins when they disagree, and which setting belongs where.

​
Precedence: dashboard wins

When a setting can be configured in both places and is explicitly set in the dashboard, the dashboard value wins. If the dashboard leaves it unset, ZAR falls back to .zar.yml, and then to the built-in default.
Example: your .zar.yml says trigger: daily but the dashboard has trigger mode set to on_significant_change. ZAR uses on_significant_change. If the dashboard trigger were left unset, ZAR would use daily from .zar.yml.

​
What goes where

​
Settable in .zar.yml (and most also in the dashboard)

These describe how docs should be produced and are natural to version with the repo: Full schema and an example: .zar.yml reference.

​
Dashboard / database only

These are operational toggles and safety switches, kept out of the repo so a PR can’t silently flip them: The complete table of every setting, with types, defaults, and ranges, is in the Settings reference.

​
New-repository defaults

When ZAR first sees a repository, it starts conservative: So out of the box: ZAR watches main, acts only on significant changes, opens small PRs, and never commits or blocks.
  1. Leave everything at defaults and open a few PRs to see ZAR’s suggestions.
  2. Add a .zar.yml with a style_guide so edits match your voice.
  3. When you trust the output, enable the CI gate — start in dry-run to preview.
  4. Only after that, consider auto-commit.

​
Next steps