Skip to content

Configuration overview

Pipemason is configured in three layers: a repo-level YAML file checked into your project, a small set of environment variables, and per-run CLI flags that override the defaults for a single invocation.

Repo configuration

Each repo Pipemason works in has a .pipeline/config.yml file. It is the single source of truth for repo-level pipeline behavior: which domains exist, the commands used to test and build them, how branches are named, cost guardrails, and which quality gates run. Running pipemason start in a repo that has no .pipeline/ directory scaffolds one with documented defaults, so you can commit it and tune from there.

Because the file is checked into your repo, the configuration travels with the code and is reviewed like any other change. See the .pipeline/config.yml reference for every block and its observable effect.

Environment variables

A handful of environment variables control how the CLI authenticates and which Claude Code executable the runner uses. These are most useful in CI or on locked-down machines. See the Environment variables page for the full list.

CLI flags

CLI flags override config and defaults for a single run. They are the right tool for one-off changes — a different base branch, a tighter cost ceiling, a dry run — that you do not want to persist into the committed config. See the CLI flags page for the global and per-command flags.

How the layers combine

The three layers resolve from least to most specific:

  • Built-in defaults ship with the runner.
  • .pipeline/config.yml overrides defaults for the repo.
  • Environment variables select credentials and the Claude Code executable.
  • CLI flags override the above for the current run.

Where a CLI flag and config set competing ceilings (for example the model-tier ceiling), the runner applies whichever value is more restrictive.