Where does the dependabot.yml file go?

It must live at .github/dependabot.yml in the default branch of your repository. Dependabot reads it from there automatically; no app installation step is needed for native GitHub Dependabot.

What is the directory field for?

It points at the folder containing the manifest for that ecosystem, such as / for a root package.json or /backend for a nested service. Use one update block per directory and ecosystem you want monitored.

How do I limit how many pull requests Dependabot opens?

Each update block honours a schedule interval, and you can ignore specific dependencies to silence noisy ones. Dependabot also caps open version-update PRs per ecosystem by default, which keeps the queue manageable.

Can one file watch several ecosystems?

Yes. The updates list can hold many blocks, so a single dependabot.yml can update npm, Docker base images, and GitHub Actions at once. This builder lets you add as many blocks as you need.

What does the ignore rule do?

An ignore entry tells Dependabot not to raise pull requests for a named dependency, which is useful for a package you pin deliberately or update manually. You list the dependency name and Dependabot skips it.

Dependabot Config Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Automated dependency PRs without hand-writing YAML

Dependabot keeps your dependencies patched by opening pull requests as new versions ship — but only once it has a correct .github/dependabot.yml. This builder generates that file from a form: choose each ecosystem, point at the right directory, set a cadence, and add ignore rules, with every block emitted as valid version-2 YAML.

How it works

The config follows Dependabot’s version-2 schema. Each update block declares a package-ecosystem (the manifest type, like npm, pip, docker, or github-actions), a directory where that manifest lives, and a schedule.interval of daily, weekly, or monthly. Optional fields are emitted only when set: a target-branch to base PRs on, an assignees list, and an ignore list of dependency names to skip. Multiple blocks are stacked under a single updates: key so one file covers every ecosystem in your repo. The output is generated locally and is ready to commit.

Tips and example

Add a separate block for github-actions with directory / — keeping your workflow action versions patched is an easy security win people often miss.
Use docker blocks pointed at the directory holding each Dockerfile to get base-image bumps.
Set a target-branch like develop if you do not want update PRs landing directly against your default branch.
Reach for ignore sparingly: silencing a dependency hides real security updates too, so prefer it only for packages you pin on purpose.