Put a dependabot.yml file in the service template, with one entry per package ecosystem the template uses. Every repository created from it then starts with scheduled update pull requests, instead of waiting for someone to remember to turn updates on.
Why the template is the right place
Update automation that depends on a manual step reaches the teams who already care. Services created last month by a busy team often have none. A config file in the template removes the decision. GitHub documents the file as the place where you define the ecosystems, directories and schedules for version updates.
Fields worth setting in the template
The Dependabot options reference lists the available keys. For a template, these matter most:
| Key | Why it belongs in the template |
|---|---|
| package-ecosystem | One entry per ecosystem, such as npm or docker |
| directory | Where the manifest lives in the generated repo |
| schedule.interval | Sets the update rhythm so pull requests are predictable |
| groups | Batches related updates to reduce pull request noise |
| cooldown | Delays version updates for a set number of days after release |
| registries | Points updates at your private registry when you use one |
Do not forget the docker ecosystem entry if the template ships a Dockerfile. Base images age as fast as libraries do.
Steps
- List the ecosystems in the template: application dependencies, base images, CI workflow actions if you use them.
- Write one entry for each, with the directory your template generates.
- Pick one schedule for all services so reviewers can plan for it.
- Decide how updates are grouped, to keep the pull request count tolerable.
- Generate a test service from the template and confirm that update pull requests actually open.
- Add a note in the template README on who reviews update pull requests.
Step 5 catches the most common failure, a directory path that does not match the generated layout.
Mistakes to avoid
- Turning updates on without telling anyone who reviews them. Pull requests pile up and teams learn to ignore them.
- Setting the schedule so tight that every service opens a dozen pull requests a day.
- Forgetting that a config in the template does not reach repos that already exist. Those need a separate rollout; see how to retrofit existing services.
- Letting update pull requests merge without a test and scan gate. The automation proposes changes; your gates decide.
Version updates and security updates differ
GitHub's reference makes a distinction worth knowing: some options, such as cooldown, apply to version updates and not to security updates. Keep that in mind when you explain behavior to developers, because a security update can arrive sooner than the schedule suggests.
Where Safeguard fits
Update pull requests tell you a newer version exists. They do not tell you whether the vulnerable code is reachable in your service. Safeguard applies reachability analysis and policy gates to pull requests, and can open fix PRs (off by default, every category on Manual). Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and see how a fixed version is surfaced next to the finding, then compare that to a plain version bump.
Click through it at your own pace, or open it full screen.
Quick check
Does a template file update repositories that already exist?
No. It applies to repos created after the template changes. Existing repos need their own rollout.
Should the template include docker updates?
Yes, if it ships a Dockerfile. Docker's guidance recommends Dependabot with the docker ecosystem to refresh base image tags and digests.
Sources
Last reviewed: 19 October 2026.
