📦 Update Dependencies

Updates your dependencies and opens a pull request, gated on your checks passing when you give it any to run.

Configuration → · Supported package managers → · FAQ →

• Scans every package manager in your repo, in one run. npm, Yarn, pnpm, pip, Cargo, Go, Maven, Gradle, Bundler, Composer, and NuGet, across every path in a monorepo, not just the root.
• Keeps your GitHub Actions current too. Every uses: owner/repo@v4 in your workflows and composite actions is moved to the newest tag, majors included by default. Turn it off or keep it within the current major in the config file. See GitHub Actions.
• Opens a pull request either way, gated on checks when you give it any. Put your tests, lint, and build in check-commands to stop a failing update before a pull request ever opens, or leave it empty and let your repo's own pull request CI check it there instead. See check-commands or your own CI for which one we recommend.
• Non-breaking by default, breaking on your own schedule. Every change in the pull request is labeled breaking or non-breaking based on the actual version jump, not just the mode you ran.
• Holds back versions that were just published. min-release-age-days (default 3) waits out a version's first few days before updating to it, the same tradeoff Dependabot's own minimum release age makes, so a compromised release has a window to get caught before it reaches you. A version that fixes a known vulnerability always bypasses this. See release-age policy.
• Stable versions only. An update that resolves to an alpha, beta, rc, snapshot, or other pre-release is walked back to the newest stable version, and the pull request says why. Set allowUnstableVersions: true in the config file to allow them. See stable-version policy.

Usage

Save this as .github/workflows/update-dependencies.yml. Runs every Monday at 02:00 UTC:

name: Update Dependencies

on:
  schedule:
    - cron: '0 2 * * 1' # every Monday at 02:00 UTC
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: yanovian/update-dependencies-action@v1
        with:
          update-strategy: non-breaking
          create-pull-request: true
          github-token: ${{ secrets.PAT_TOKEN }}

This is the recommended setup: no check-commands, a PAT for github-token (see permissions and tokens), your repo's own pull request CI checks the update once it's opened, same as any other pull request.

More examples, each in its own folder under examples/:

• examples/breaking/: the monthly breaking-updates workflow
• examples/with-check-commands/: the simpler check-commands
  • default-token alternative
• examples/pull-request-checks/: the pull request CI workflow the recommended setup expects you to already have
• examples/with-config/: skipping an ecosystem or a path with a config file
• examples/with-branch-name/: a custom branch-name prefix instead of the default
• examples/no-token-pull-request/: generating the update without giving this Action any token, and opening the pull request in a separate, trusted step

Don't trigger this Action itself on pull_request. See why in the FAQ.

Supported package managers

Ecosystem	Language	What it updates
npm, Yarn, pnpm	JavaScript/TypeScript	package.json + lockfile
pip	Python	requirements.txt
Cargo	Rust	Cargo.toml + Cargo.lock
Go	Go	go.mod + go.sum
Maven	Java/JVM	pom.xml
Gradle	Java/JVM	version catalog or build.gradle(.kts)
Bundler	Ruby	Gemfile + Gemfile.lock
Composer	PHP	composer.json + composer.lock
NuGet	C#/.NET	*.csproj
GitHub Actions	YAML	uses: refs in .github/workflows/*.yml and action.yml

Every manifest in the repo gets updated, not just the ones at the root, so a monorepo with several languages gets all of them in one run. Full detail on exactly which command runs for each one, and what it deliberately won't touch: _docs/supported-package-managers.md.

What the pull request looks like

The pull request description lists, for every path in your repo where something changed: the package, the path, the version it moved from and to, and whether that change was breaking or not. It also lists every command that ran and passed, credits Update Dependencies, and explains why keeping dependencies current matters for security while making clear that testing the change is still on you.

Both the title and the body say what date the run happened on. Running it again the same day updates that same pull request instead of opening a new one; a run on a later date opens a new one, and if an earlier one from this Action is still open, the new pull request points to it and recommends closing it. Full detail: does it create a new pull request every time it runs.

Permissions and tokens

Your workflow needs to grant these permissions either way:

permissions:
  contents: write
  pull-requests: write

For github-token, there are two paths, explained in full in the FAQ:

• Recommended: a PAT, so your repo's own pull request CI runs on the update automatically. How to create one.
• Simpler, not recommended: the default GITHUB_TOKEN, paired with check-commands.

FAQ

Quick answers to the questions that come up most before adopting this Action. Full FAQ: _docs/faq-and-limitations.md.

What if I don't trust this Action and don't want to pass it my personal access token?

Set create-pull-request: false and leave github-token empty. This Action then only updates dependencies and writes the rendered pull request title and body to disk, no token, no network call with one. A later step in the same job, using an official action like actions/github-script, opens the pull request itself. Full answer →

Why does it need write permissions?

Pushing the update branch and opening the pull request need contents: write and pull-requests: write from something in your workflow, though not necessarily from this Action itself (see the token question above). Full answer →

Can I trigger this on pull_request?

No. GitHub gives the default token read-only access on a pull_request run from a fork, so pushing a branch would fail. Use schedule or workflow_dispatch instead. Full answer →

Does it open a new pull request every time it runs?

Only when it finds updates, and only one per day: the branch is dated, so running it again the same day updates that same pull request instead of opening a duplicate. Full answer →

check-commands or my own CI, which should I use?

Your own CI, with a PAT for github-token, is recommended: it checks the update the same way it checks every other pull request, nothing duplicated. check-commands is simpler to set up but runs its own separate check. Full answer →

Docs

• Configuration: every workflow input, output, and config file field.
• Supported package managers: exactly what command runs for each ecosystem, in each mode.
• FAQ and limitations: what this Action won't do, and why.

A note on trust

If you give this Action commands to run, a pull request only opens once they all pass, that's a real signal, but it's not a guarantee. Review the diff yourself before merging, especially for a breaking update.

Contributing

This project uses pnpm and Node 24. See Makefile for the available dev commands (make install, make test, make lint, make verify, and so on). See CONTRIBUTING.md for how to add support for another package manager.

Projects using it

• Tabby: Chrome extension
• Why Am I Here?: Chrome extension
• Breadcrumb: Chrome extension