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.
kodus-config/
├── kodus-config.yml                      ← global settings
├── .kody-rules/
│   ├── review/                           ← global review rules
│   │   └── require-tests-for-endpoints.yml
│   └── memories/                         ← global memories
│       └── logging-convention.yml
│
├── backend-api/                          ← matches a Kodus repo
│   ├── kodus-config.yml                  ← repository-level overrides
│   ├── .kody-rules/
│   │   ├── review/
│   │   │   └── no-raw-sql.yml
│   │   └── memories/
│   │       └── auth-module-layout.yml
│   │
│   └── src/auth/                         ← matches a repo subdirectory
│       ├── kodus-config.yml              ← directory-level overrides
│       └── .kody-rules/
│           ├── review/
│           └── memories/
│
└── frontend-web/
    └── kodus-config.yml
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: 
version: '1.2'
reviewOptions:
  security: true
  kody_rules: true
  error_handling: true
suggestionControl:
  groupingMode: full
  limitationType: pr
  maxSuggestions: 9
  severityLevelFilter: medium
ignorePaths:
  - yarn.lock
  - package-lock.json
automatedReviewActive: true

​
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): 
title: Require tests for new endpoints
rule: |
  Every new HTTP endpoint handler must include at least one integration test
  that exercises the happy path and one common failure mode.
severity: high
scope: pull_request
path: apps/api/**
examples:
  - snippet: |
      // endpoint added with matching *.spec.ts
    isCorrect: true
  - snippet: |
      // endpoint added with no test file touched in the PR
    isCorrect: false
inheritance:
  inheritable: true
  exclude: []
  include: []
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.

​
Sync States

Each rule that comes from Centralized Config tracks its lifecycle through a status:
StatusMeaning
SYNCEDThe rule in Kodus matches the file in the centralized repository.
PENDING_ADDA new rule has been created via UI/CLI and a PR was opened; the file does not exist on the default branch yet.
PENDING_EDITAn edit was proposed via UI/CLI and a PR is open; the existing file has not been updated yet.
PENDING_DELETEA deletion was proposed via UI/CLI and a PR is open; the file still exists on the default branch.
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: 
kodus auth team-key --key <your-key>

​
Check Status

kodus config centralized status

​
Initialize Centralized Config

kodus config centralized init [owner/repo] --sync-option <pr|manual>
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: 
kodus config centralized init kodustech/kodus-config --sync-option pr
kodus config centralized init kodustech/kodus-config --sync-option manual

​
Run Sync

kodus config centralized sync

​
Disable Centralized Config

kodus config centralized disable

​
Download Config ZIP

kodus config centralized download --out ./centralized-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. 
kodus config centralized status --json
kodus config centralized init kodustech/kodus-config --sync-option pr --json
kodus config centralized sync --json
kodus config centralized disable --json
kodus config centralized download --out ./centralized-config.zip --json