In a monorepo, scope each fix pull request to the directory it changes, route it to that directory's owners, and group updates that span directories only when the same dependency is involved. Without that, one shared repository produces a flood of pull requests nobody owns.
What goes wrong by default
A monorepo may hold dozens of manifests across services and libraries. A tool that treats the repository as a single unit can open overlapping pull requests, touch shared lockfiles from several branches, and assign them to nobody in particular. Reviewers who own one service get asked to approve changes to another.
Configure per directory
GitHub's options reference for its dependency update bot shows one approach. A directories setting lists multiple manifest locations and supports globbing, and a grouping option can create one pull request per dependency across all the listed directories. The docs limit that to version updates in one ecosystem, and say separate pull requests are created when version constraints conflict.
Whatever tool you use, the questions are the same:
| Question | Why it matters |
|---|---|
| Which directories does the tool scan? | Excludes vendored and generated code |
| Does one finding create one PR across directories, or many? | Controls review load |
| How are shared lockfiles handled? | Avoids conflicting branches |
| Who gets assigned? | Owners must see it |
Ownership
Use a code owners file with a rule per directory, so the pull request requests review from the right team automatically. See code owners for a monorepo. If a change touches several owned directories, each owner must approve, which is correct but slower. Consider whether a cross directory update should be split.
Cross cutting vulnerabilities
Some fixes are shared: a vulnerable library used by ten services. Two reasonable choices:
- One PR for the shared dependency, reviewed by an owner of the shared tooling, with a note listing affected services. Good when the services share one version policy.
- One PR per service, so each team tests its own code. Good when services diverge.
Pick one per dependency and say which in the pull request.
Keep the CI bill sane
Run only the tests for affected directories on bot pull requests where your build system supports it. A full monorepo run for each bot branch costs time and discourages merging. Make sure required checks still cover every affected target.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers repositories with many manifests, and its autonomous remediation is off by default with every category on Manual. The one SBOM or many for a monorepo post explains inventory choices. A free scan is a quick start.
Quick check
Should bot PRs run the whole monorepo test suite?
Run what the change affects, and keep required checks covering every affected target.
Who approves a shared library fix?
The owner of the shared code, plus owners of directories the change touches.
Sources
Last reviewed: 19 October 2026.
