Configuration

A repo’s Fabric settings live in a file at its root: fabric.yaml. It is an ordinary tracked file, versioned in the operation log like everything else. Edit it in a change, propose, and accept, and the new settings take effect the moment the change lands on trunk. There is no separate settings screen and no out-of-band state.

Every setting is optional. A repo with no fabric.yaml behaves exactly as Fabric did before the file existed, and an omitted key keeps its default. You only write down what you want to change.

Where it lives and how it is read

fabric.yaml sits at the repository root. When Fabric needs a setting, it reads the file from the trunk and parses it. Because the file is versioned, the settings in force are always the ones on trunk, and you can see exactly when they changed by looking at the file’s history.

A recommended header points an editor at this page and the machine-readable schema:

# Fabric repository configuration.
# Docs:   https://fabricemr.com/docs/config/
# Schema: https://fabricemr.com/config/schema.json

The schema

fabric.yaml is validated against a published JSON Schema. The schema is the validator: the same document your editor can load for completion and inline checking is the one Fabric uses. Point your editor’s YAML schema setting at https://app.fabricemr.com/config/schema.json to get completion and error squiggles as you type.

Validation runs when you propose a change that edits fabric.yaml. A malformed or out-of-spec file is rejected there, with a message naming the problem, so a bad file is caught against the change that introduced it. A change that does not touch fabric.yaml is never affected.

Referencing secrets

Some settings carry sensitive values: a notification webhook URL, a deploy token. You do not want those bytes sitting in a shared, versioned file. Reference them by name instead, with a ${secret.NAME} token:

notifications:
  webhook: ${secret.SLACK_WEBHOOK_URL}

The file records the name, never the value. The value lives encrypted in the repo’s secret store, which you manage under Settings, Secrets. When Fabric needs the setting, it looks the name up in the store, decrypts the value, and uses it. The decrypted value is held in memory for that one use. It is never written back into the file, the operation log, the application logs, or any settings page. Those surfaces show the name ${secret.NAME}, so anyone reading the file or the history sees which secret is used, never its contents.

NAME is an uppercase env-var key: an uppercase letter followed by uppercase letters, digits, or underscores (for example SLACK_WEBHOOK_URL), the same shape the secret store enforces.

A reference must point at a secret the store already defines. If you propose a change whose fabric.yaml names a secret that does not exist, propose is refused with a message naming the missing secret, so the gap is caught against the change that introduced it rather than at some later enforcement. Define the secret under Settings, Secrets first, then propose.

Change approval

The approval section controls how many reviews a change needs before it can be accepted into trunk.

approval:
  required: 2              # distinct approving reviews needed to accept (default: 0)
  allow_self_approve: false # may the change's author approve their own change? (default: false)
  reviewers:               # whose approvals count (default: anyone with write access)
    - alice
    - bob

required is the number of distinct approving reviews a change needs. The default is 0, which accepts without any approval, matching a repo that has no fabric.yaml.
allow_self_approve decides whether the change author’s own approval counts toward the total. It defaults to false, so by default someone other than the author must approve.
reviewers restricts whose approvals count. Leave it empty (the default) and an approval from anyone with write access counts. List identities and only their approvals count.

Record an approval with fabric approve (or fabric approve --request-changes for the opposite). When you run fabric accept, Fabric counts the distinct approving reviews and lands the change only if the policy is met. If it is not, accept is refused with a message saying how many approvals are still needed.

A change is judged by the policy it forked from

A change is measured against the approval policy in force at the point it forked from trunk, not the policy written inside the change itself. This matters when a change raises the bar. If a change edits fabric.yaml to require more approvals, that change is still judged by the old policy, so it can be accepted normally and the stricter rule applies to changes that fork after it. Raising the requirement never traps the change that raises it.