Self-Managed Repos

The Idea

Each repository manages its own settings by keeping a gh-infra YAML file alongside the code. Changes are applied automatically when merged via a GitHub Actions workflow.

This is the opposite of the central management pattern — there’s no dedicated config repo. Each team owns their repo’s infrastructure.

Directory Structure

• Directorymy-project/

  • Directory.github/

    • infra.yaml Settings for this repo
    • Directoryworkflows/

      • infra.yaml Workflow that auto-applies on merge
  • Directorysrc/

    • …

How It Works

1. A developer opens a PR that modifies .github/infra.yaml
2. The team reviews the infrastructure change alongside the code, with the plan posted as a comment
3. On merge, a GitHub Actions workflow runs gh infra apply automatically

.github/workflows/infra.yaml

on:
  push:
    branches: [main]
    paths: [".github/infra.yaml"]
jobs:
  apply:
    runs-on: ubuntu-latest
    env:
      GH_TOKEN: ${{ secrets.GH_INFRA_TOKEN }}
    steps:
      - uses: actions/checkout@v4
      - run: gh extension install babarot/gh-infra
      - run: gh infra apply .github/infra.yaml --auto-approve

The workflows in CI/CD Integration work here too with .github/infra.yaml as the path: plan on pull request with a comment, apply on merge, and drift detection.

GH_INFRA_TOKEN is a fine-grained token or GitHub App token for this repository with Administration: Read and write (see Authentication). The workflow’s own GITHUB_TOKEN cannot have the administration permission, so it cannot manage repository settings; it is enough only when the manifest manages nothing but labels and milestones (issues: write) and File / FileSet documents for this repository.

When to Use This Pattern

• Teams want autonomy over their own repo settings
• Infrastructure changes should go through the same PR review process as code changes
• You don’t have (or need) a central team managing repo governance

When Not to Use

• You need to enforce consistent settings across many repos — use central management with RepositorySet instead
• You want a single audit trail of all infrastructure changes across the org