Yes, in at least one widely used bot. Its multi-ecosystem groups combine updates from several package ecosystems into a single pull request, with their own schedule. By default the same tool opens a separate pull request per ecosystem. Combine only ecosystems that you test and deploy together, such as infrastructure files.
Default behavior and the option
In the options reference of that bot, the default is to create separate pull requests for each package ecosystem that has updates. If you define a multi-ecosystem group, updates from the ecosystems assigned to it are combined into one pull request. The group has its own schedule, and individual ecosystem settings can be inherited or overridden. The reference example puts container image updates and infrastructure provider updates into one group called infrastructure, each limited by name patterns, on a weekly schedule.
The reference also says these updates need specific configuration patterns and have unique behavior when settings are merged, and points to a dedicated guide for full setup. Read that guide before you roll it out, because parameters from several sections end up in one pull request.
When combining makes sense
The test is whether the changes are reviewed and released together.
| Combination | Reasonable? | Why |
|---|---|---|
| Container base images and infrastructure modules | Often | Same team, same deployment pipeline |
| Application libraries and CI workflow actions | Rarely | Different reviewers, different risk |
| Several language ecosystems for one service | Sometimes | One build, one release |
| Everything in the repository | Almost never | Failures block unrelated changes |
The costs
One pull request that spans ecosystems fails if any part fails. A broken infrastructure module bump can hold back an unrelated image patch. Review gets harder, because the reviewer must understand several kinds of change. Rollback gets harder too, since you cannot revert half a pull request without editing it.
Compare with the benefit: fewer pull requests and one schedule. For a platform team that owns many small repositories, this can be the difference between a manageable queue and an ignored one.
How to try it
- Pick one repository and one pair of ecosystems that already ship together.
- Define a shared schedule for the group, and keep the rest as they are.
- Use name patterns so the group includes only the packages you mean, not the whole ecosystem.
- Run for two cycles. Count how often a combined pull request failed because of one part.
- If failures are rare and review is fast, extend to another repository. If not, split them again.
Security notes
Different ecosystems carry different risk. Workflow actions run with access to your CI, container images run in production, and libraries run inside your app. A single approver clicking merge on a mixed pull request may not examine each. Keep a rule that anything touching CI workflows or base images gets a second look, whether or not it is grouped. Our post on updating CI workflow actions explains why.
Also remember that security fixes should not be delayed by a group schedule. Check whether your tool lets security updates bypass it.
Quick check
Is a cross-ecosystem group the same as a monorepo group?
No. A monorepo group combines related packages within one ecosystem. A cross-ecosystem group combines different package managers into one pull request.
Will this reduce my review effort?
It reduces the number of pull requests, but each one is larger and mixed. Measure review time before and after.
Safeguard discovers your assets and builds an SBOM from manifests and lockfiles across ecosystems, including container images, so you can see what depends on what. Reachability analysis shows which flagged dependencies your code calls. Fix pull requests are off by default, with every category on Manual. A free scan is available.
Sources
Last reviewed: 19 October 2026.
