Skip to content

Configuration

Overview

CloudAEye's settings are saved inside the console, at console.cloudaeye.com under Settings. Each of those pages is described in the Settings UI section on the left: LLM, Code Review, Unit Tests, API Keys and Data Retention. These pages call them the console settings.

The convenient way to configure CloudAEye is to place two markdown files in your repository:

  • .cloudaeye.config holds your settings, and .cloudaeye.rules your review rules.
  • Place them at the root, or in any directory. A file applies to its directory and everything under it, so one part of the repository can have stricter settings than the rest.
  • The settings live beside the code they govern, where everyone working on it can read them.

Get the default file to start. It lists every setting, commented out, with its options beside it, ready to paste.

The Files Override the Console Settings

A setting placed in a file overrides the same console setting. Where no file sets it, the console settings apply: the repository's own when it has them, otherwise your account-wide (global) ones. A setting the console does not have takes CloudAEye's default.

Review Settings it uses
CloudAEye commands in your coding agent: /cloudaeye:inspect, /cloudaeye:security, /cloudaeye:review, /cloudaeye:ultrareview, /cloudaeye:control-flow, /cloudaeye:triage-prs The files, then the console settings
Pull request reviews by the CloudAEye GitHub App: @cloudaeye /review, Auto PR Review, the PR Checklist The console settings

What You Can Set Where

Settings Console settings Repository file
LLM Model, model inversion, and your own provider account and API key CloudAEye's models or your own, provider, model, model inversion, and your own provider's API key
Ultrareview Checks, hard limits, human review policy Checks, hard limits, human review policy
Code Review No Secrets in Code Severity floor, paths never reviewed, review rules
Linter Linters for each language Not in the file
PR Checklist Checklist items, and Warning or Error for each Only whether ultrareview runs the checklist
Unit Tests Test framework for each language, automatic test updates Not in the file
API Keys Create and delete keys for CloudAEye's API Not in the file
Data Retention How long review history is kept Not in the file

Two more sections exist only in the file: Control flow and Triage PRs.

Get Started

There are two ways to place the files. Both give the same result.

Place the File Yourself

  1. Get the default file and save it as .cloudaeye.config at the root of your repository, or in the directory it should cover.
  2. For each setting you want, remove the comment marks around its line and set its value. Every setting left commented out follows the console settings.
  3. Place a .cloudaeye.rules beside it if you have review rules of your own.

The Configuration File page explains the format, and the examples show common setups.

Let Your Coding Agent Place It

  1. In Claude Code, with the CloudAEye plugin installed, run /cloudaeye:config in your repository.
  2. If the repository has no .cloudaeye.config yet, CloudAEye offers to start it from your console settings: this repository's, or your account's.
  3. Go through the settings one section at a time, answering in your own words: risk 40, slop 50, turn off architecture, next, done.
  4. CloudAEye places .cloudaeye.config and .cloudaeye.rules in your repository.

See Working With Coding Agents for more, including how to go back to the defaults.

Keeping Your LLM Key Safe

With your own LLM provider account, the file can hold its API key. Anyone who can read the repository can read the file, so name an environment variable that holds the key instead of writing the key itself:

- API key: $OPENAI_API_KEY

Each developer sets that variable on their own machine. The CloudAEye commands read the key when they run and send it straight to CloudAEye; it never appears in your coding agent's output, and CloudAEye keeps it encrypted only for the reviews it was sent for. Writing the key itself in the file also works, if your team accepts that everyone with access to the repository can read it.

You can also leave the key out of the file and save it once in the console settings, under Settings > LLM > Bring your own LLM (see LLM in the Settings UI section). Never put any other token, password or secret in these files.

Self-Hosting

The files work the same way with self-hosted CloudAEye:

  • Point the plugin at your deployment's MCP endpoint, <app_base_url>/mcp, as described in Self-Hosted MCP.
  • The commands read the files on the developer's machine and send the settings that apply to your deployment, the same as on CloudAEye SaaS.
  • Starting a new file from the console settings, and syncing review rules, read your deployment's own console.
  • Your own LLM key can be named in the file as an environment variable, the same as on CloudAEye SaaS. Leave the LLM settings out to use the model and key your deployment is configured with. See LLM Model Configuration.

Next Steps