Automations

Fleet-Wide Maintenance Across Thousands of Repositories

Point Opulent at the whole estate, dependency updates, cross-repo refactors, and maintenance PRs batched, verified, and opened across thousands of repositories.

SchedulesAdvanced Capabilities

AuthorOpulent

CategoryAutomations

FeaturesSchedules, Advanced Capabilities

start it with one message

Run a fleet-wide maintenance sweep across our GitHub repositories. Find repos needing dependency updates, security fixes, or small refactors; run the maintenance playbook on each; verify with tests; and open PRs. Track progress in Linear and route orchestration through n8n or Zapier.

Run this in OpulentCopy it, swap the names for your own, and send it.

connected systems

GitHubManage repositories, track code changes, and collaborate on team projects

LinearTrack issues, manage projects, and organize workflows across your team

n8nAutomate and orchestrate complex workflows across your entire tech stack

ZapierAutomate workflows across thousands of connected apps

step 1

Connect the fleet and define the maintenance playbook

Connect GitHub to read repo metadata, branches, and PRs. Connect Linear to track work. Use n8n or Zapier to fan out the same playbook across many repositories without writing custom orchestration code.

The maintenance logic lives in a playbook, a reusable, named set of steps Opulent follows per repository. It defines what to look for, how to verify changes, and when to open a PR versus flag for review.

Playbook: !fleet-maintenance

For each repository in the fleet:
1. Check outdated dependencies against a policy (patch/minor in
   one PR, major in separate PRs with changelog notes).
2. Run npm audit / pip-audit / equivalent and flag known
   vulnerabilities.
3. Check for small refactor triggers: deprecated APIs, stale
   patterns, or migration steps defined by the platform team.
4. Apply the changes on a branch, run the test suite, and build.
5. If tests pass and the change is low-risk, open a PR with a
   summary table.
6. If tests fail or the change is high-risk, open a draft PR and
   create a Linear ticket for review.
7. Record the outcome: repo, change type, PR link, status.

Tip

Start with a small fleet slice, one team or one language ecosystem. Running the playbook on 10 repos teaches you more about the edge cases than running it on 1,000 repos on day one.

step 2

Wire the trigger and routing

Set a schedule, weekly is common for dependency updates, or trigger the sweep after a known event, like a security advisory. n8n or Zapier receives the trigger, lists the target repos from a spreadsheet or GitHub organization, and kicks off one Opulent run per repo.

The orchestrator also aggregates the results: PR links, test outcomes, and repos that need human attention.

The sharp edge: without a change-type policy, the fleet sweep opens hundreds of unrelated PRs and overwhelms reviewers. Group changes by type and risk so each PR is reviewable.

n8n / Zapier flow:
- Trigger: weekly cron or security advisory webhook.
- List repos from GitHub org or a maintained registry.
- For each repo, call Opulent with the playbook and repo name.
- Collect PR links and status into a summary.
- Post the summary to Slack and update a Linear project board.

step 3

Watch one repo move through the sweep

Take a frontend repo with outdated dependencies. Opulent checks the lockfile, identifies patch and minor updates, applies them, runs the test suite, and opens a single PR with a summary table.

It also flags one major-version bump as a separate draft PR because the changelog notes breaking changes. A Linear ticket is created so the owning team reviews it in their next planning cycle.

Repo: acme/web-dashboard

Actions:
- Updated 4 patch/minor dependencies in one branch.
- Ran npm run test:ci, passed.
- Opened PR #234: safe dependency updates with table.
- Flagged zod v3 -> v4 as separate draft PR #235 with changelog
  notes and code changes.
- Created Linear ticket LIN-560 for major-bump review.
- Recorded outcome in fleet summary sheet.

step 4

What exists when the sweep finishes

A fleet sweep produces a dashboard of work: open PRs grouped by change type and risk; draft PRs and Linear tickets for high-risk or failed changes; a summary of repos with no changes needed; and an audit log of which playbook ran on which repo and when.

The audit log is the proof-of-work: it shows the fleet was touched systematically, not randomly, and lets any team see the status of their repos.

step 5

Sharpen the fleet loop

When a playbook step consistently fails on a repo pattern, add a rule or write it into memory (the notes a run recalls next time). When a low-risk change type always merges without issue, enable auto-merge for that type to reduce reviewer load.

Expand the fleet incrementally: add a new language stack, a new organization, or a new change type only after the previous slice is stable.

The natural chain: for security fixes, use Security Swarm Fix Vulnerabilities at Scale; for framework upgrades, use Create a React 18 to 19 Upgrade Playbook; for refactoring a single large repo, use Refactor a Multi-Million-Line ETL Monolith.