Skip to main content
Centralized Config lets you keep every code review setting and every Kody Rule in one repository instead of editing them per-repo in the web UI. Each change flows through a pull request on that repository, giving you version history, review, and rollback on your review configuration. Use it when you want:
  • A single source of truth for review behavior across many repositories.
  • Code-review-as-code: history, PR review, rollback, CI validation.
  • Consistent Kody Rules (review rules and memories) across the whole organization.
  • CLI-driven or CI-driven configuration changes.

How It Works

  1. Choose one repository to hold your centralized config.
  2. Enable Centralized Config in the UI and point it at that repository.
  3. Pick an initial sync mode:
    • pr — Kodus opens the initialization PR with your current effective settings and rules.
    • manual — Kodus generates the files; your team downloads and opens the PR.
  4. After the first merge, every future merge on the centralized repository automatically propagates changes to Kodus.
The centralized repository mirrors Kodus’s scope hierarchy (Global → Repository → Directory) through its folder layout.

Repository Layout

The centralized repository uses folder paths to map files to scopes. The layout covers both review settings (kodus-config.yml) and Kody Rules (.kody-rules/).
The repository name is arbitrary — pick whatever fits your organization. kodus-config is used below as a convention.
Rules:
  • A kodus-config.yml at the root of the centralized repo applies globally.
  • A top-level folder whose name matches a Kodus repository (e.g. backend-api/) scopes files to that repository.
  • A nested path inside a repo folder (e.g. backend-api/src/auth/) scopes files to that directory, following the same inheritance model as the web UI.
  • Rules under .kody-rules/review/ become review rules; rules under .kody-rules/memories/ become memories.
Any file missing a matching scope is ignored on sync.

Config Files

Each kodus-config.yml uses the same schema as the per-repo kodus-config.yml documented in General settings. Fields are applied at the level of the folder where the file lives and follow the usual inheritance rules (see Config Inheritance & Overrides). Minimal example:

Kody Rules Files

Each rule is a single YAML file under .kody-rules/review/ (standard rules) or .kody-rules/memories/ (memories). The filename is arbitrary — Kodus identifies rules by the title field and by the canonical file path stored with the rule. Example review rule (.kody-rules/review/require-tests-for-endpoints.yml):
See Kody Rules Overview for the full field reference and Rule Inheritance for how inheritance.inheritable, exclude, and include behave.

UI Workflow

From Settings → Code Review → General:
  1. Open Centralized Config.
  2. Enable Centralized Config.
  3. Select the source repository.
  4. Pick the Initial Sync Method:
    • Automatic (Create PR now)
    • Manual (Sync later)
  5. Save and confirm status.

Web UI Behavior When Enabled

When Centralized Config is enabled, the source of truth for configuration is the centralized repository. The web UI reflects this:
  • Repository, directory and global code review settings become read-only in the web UI. Edit them by opening a PR on the centralized repository.
  • Kody Rules and PR Messages remain editable in the web UI. Saving an edit does not mutate the rule directly — Kodus opens a pull request on the centralized repository with the proposed change. Once the PR is merged, the change becomes active.
This preserves the “everything is reviewed and versioned” guarantee while keeping the visual editing experience for rules and messages.

UI rules and repo rules coexist

Enabling Centralized Config does not wipe rules that were previously created in the web UI, and it does not prevent new rules from being created through the UI. Both sources feed the same pool of active rules:
  • Rules imported from the centralized repository are persisted with status SYNCED.
  • Rules created directly in the web UI live alongside them and stay active.
  • At review time, Kodus loads every active rule from the database regardless of origin. A rule that exists only in the UI is applied exactly like a rule that exists only in the repo.
  • Rules in status PENDING_ADD (a UI/CLI edit that opened a PR not yet merged) are excluded from reviews until the PR is merged and the status transitions to SYNCED.
In practice: if you bootstrap the centralized repo by hand and it’s missing a rule you already had in the UI, that rule keeps running — it just isn’t version-controlled in the repo. To bring it under version control, edit it once in the UI (which opens a PR) or use init so Kodus bundles every existing rule into the initialization PR.

Sync States

Each rule that comes from Centralized Config tracks its lifecycle through a status: PENDING_* transitions back to SYNCED once the corresponding PR is merged.

Sync Modes

Kodus opens the initialization pull request automatically with your current effective settings and rules.

Download Configuration Bundle

You can download a ZIP containing the generated kodus-config.yml files and .kody-rules/ tree that reflect your current settings and rules. Use this when:
  • Auditing generated configuration.
  • Sharing setup artifacts with another team.
  • Keeping a local backup before a rollout.
  • Bootstrapping the centralized repository in manual mode.

Disable Centralized Config

Disabling Centralized Config clears the selected source repository and returns all repositories to the standard non-centralized behavior (settings edited in the web UI, optional per-repo kodus-config.yml). Rules and settings that were synced in remain in Kodus — they are not deleted on disable.

CLI

Use these commands to manage Centralized Config from terminal workflows and CI scripts.

Requirements

  • Team key authentication.
  • At least one selected repository in Kodus.
Authenticate with:

Check Status

Initialize Centralized Config

Notes:
  • --sync-option defaults to pr.
  • If the repository is omitted in an interactive terminal, the CLI prompts for selection.
  • In non-interactive environments, the repository must be provided.
Examples:

Run Sync

Disable Centralized Config

Download Config ZIP

Notes:
  • --out is required.
  • Output is a ZIP bundle containing the generated config files and .kody-rules/ tree.

JSON Output

All centralized commands support structured output with --json.