# sbt-updates reads Maven metadata so you can see which dependencies moved

> sbt-updates is an sbt plugin that reports available updates for project dependencies and for plugins declared in a global plugins file, using Maven metadata rather than inspecting your build. It fits teams that want a report they can check in CI, and it misses anything that does not publish metadata properly.

**rtimush/sbt-updates** — sbt plugin that can check Maven and Ivy repositories for dependency updates

- Repository: https://github.com/rtimush/sbt-updates
- Stars: 771 · Forks: 59
- Language: Scala
- License: BSD-3-Clause
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/rtimush-sbt-updates

## The plugin reads repository metadata, so it never looks at your build graph

sbt-updates is an sbt plugin for Scala builds that lists the updates available for the dependencies a project declares. The mechanism is simple and worth stating plainly, because it explains both what the tool gets right and where it stops: update information is taken from the maven metadata published alongside artifacts, not from a resolution of your build.

That design is what lets the plugin show a patch, a minor and a major candidate for each module in one pass. It also means the result depends on the publisher having written metadata correctly. The project notes this explicitly for other sbt projects, and points at sbt-aether-deploy as one way to make sure that happens.

Coverage of the repository types is uneven. Maven repositories are the main case. Support for Ivy repositories is described as limited, and it is limited to those hosted on BinTray. If your artifacts come from a repository of another kind, expect gaps in the report rather than a clear explanation of them.

## Each row shows patch, minor and major candidates side by side

The output format is the most useful part of the plugin and it is unusual enough to be worth reading carefully. Reading from left to right, a row gives the version currently in use, then the patch update, then the minor update, then the major update.

```
> dependencyUpdates
[info] Found 3 dependency updates for test-project
[info]   ch.qos.logback:logback-classic : 0.8   -> 0.8.1 -> 0.9.30 -> 1.0.13
[info]   org.scala-lang:scala-library   : 2.9.1 -> 2.9.3 -> 2.10.3
[info]   org.slf4j:slf4j-api            : 1.6.4 -> 1.6.6 -> 1.7.5
```

Because each column is a different kind of jump, a reader can see at a glance that logback-classic has a safe 0.8.1 available and also a much larger 1.0.13 in the pipeline. Nothing is applied here. The plugin reports, and the decision to change a version stays with whoever owns the build.

Projects that set crossScalaVersions see only the updates that are available for every Scala version in that list. The plugin will not propose a version that exists for one Scala version and not another, which avoids a class of failure that is easy to introduce otherwise.

## Installing as a global plugin, and the snapshot variant that never refreshes

The preferred installation is as a global plugin, because that is what makes plugin update checks possible later. For the sbt 1.x series you create a plugins file under the 1.0 directory in your sbt home, and for sbt 0.13.x the path differs:

```
addSbtPlugin("com.timushev.sbt" % "sbt-updates" % "x.x.x")
```

A snapshot build is also possible, in which case you add the Sonatype snapshot resolver and use a snapshot version string:

```
resolvers += Resolver.sonatypeRepo("snapshots")
addSbtPlugin("com.timushev.sbt" % "sbt-updates" % "x.x.x-y+gzzzzzzz-SNAPSHOT")
```

The version strings in both examples are placeholders in the original documentation, so you have to replace them with a real published version. The stable version is the one you want for most setups, and the documentation states plainly that snapshots are not updated automatically, which means the reported updates for a snapshot install can be stale.

Version support is broad but not uniform. The plugin needs sbt 0.13.9 or later, sbt 1.x is covered from version 0.3.1 of the plugin, and sbt 2.x is covered from version 0.7.0.

## Two tasks, a report file, and a filter that supersedes the old exclusions setting

Two tasks do the work. dependencyUpdates prints the list of project dependencies that can be updated, and dependencyUpdatesReport writes the same kind of list to a file. The report file location is set by the dependencyUpdatesReportFile setting, and it defaults to target/dependency-updates.txt.

For continuous integration the useful piece is dependencyUpdatesFailBuild, which makes the dependencyUpdates task fail the build when updates are found. Combine it with a report written to disk and a build that refuses to go green on drift gives you a policy you can enforce rather than a list somebody has to remember to read.

Two filters control what is reported. dependencyUpdatesFilter selects matching dependencies that should be included, and dependencyUpdatesExclusions is listed as a deprecated setting for excluding matches. The documented form for excluding a module is:

```
dependencyUpdatesFilter -= moduleFilter(organization = "org.scala-lang")
```

There is also dependencyAllowPreRelease, which is off by default and, when enabled, adds pre-release dependencies to the report.

## Checking plugins themselves takes reload plugins, and only for a global install

The plugin can also report updates for other sbt plugins, and the mechanism is less obvious than the dependency side. The update information for plugins is gathered by the reload plugins command, which re-reads the plugin definitions:

```
> reload plugins
...
> dependencyUpdates
[info] Found 2 dependency updates for project
[info]   com.timushev.sbt:sbt-updates          : 0.3.0  -> 0.3.4 -> 0.4.3
[info]   org.scala-lang:scala-library:provided : 2.10.6          -> 2.12.4
> reload return
```

To see both kinds of update in one session, the two tasks are chained in a single sbt invocation:

```
sbt ";dependencyUpdates; reload plugins; dependencyUpdates"
```

There is a hard limit here. Only plugins defined in a project are checked, and the documentation states that there is currently no way to check updates for global plugins. That is the same boundary that makes the global installation the recommended one: installed globally, the plugin is part of a project as far as the update check is concerned, but plugins sitting only in your own home directory stay invisible.

Using the plugin as a project plugin instead is possible, by adding the definition to project/sbt-updates.sbt. The trade-off is spelled out: in that mode you lose plugin update checks, and to get both you need the definition in project/sbt-updates.sbt and in project/project/sbt-updates.sbt, with the full chain:

```
sbt ";dependencyUpdates; reload plugins; dependencyUpdates; reload return"
```

## Where this plugin stops, and what a scheduled bot does differently

The gaps are concrete. A module whose publisher does not write Maven metadata correctly will not show up, so a clean report is not proof that everything is current. Ivy repositories outside the BinTray case are described as limited rather than fully supported. Global plugins are never checked. And the plugin reports without changing anything, which means a team still has to decide, review and land each version bump by hand.

That last point is where the difference from an automated approach lies. The repository root of this project contains a .scala-steward.conf file, and the project documentation does not describe how that file is used, so treat the mention as an indication of the ecosystem rather than a supported feature. The structural contrast is still clear: a bot works on a schedule, opens changes for you and leaves the review to a human, while sbt-updates produces a report that a human reads before doing the work. A report suits a build that you control, and a bot suits a repository with many dependencies that nobody has time to track.

Maintenance and licensing are unremarkable in a good way. The project is released under the BSD-3-Clause licence, the last push to the repository was on 2026-10-16, and the repository is not archived. Recent releases include 0.7.1 on 2026-10-08, 0.7.0 on 2026-06-16 and 0.6.4 on 2026-06-16.

## Conclusion

sbt-updates is worth adopting for a Scala team that wants a readable list of available upgrades before a manual bump, and it is the wrong tool when you need a bot to apply those bumps or when your artifacts are published without correct Maven metadata. Verify first that the coordinates you care about publish usable metadata, then decide between the console task and dependencyUpdatesReport with dependencyUpdatesFailBuild for a build that stops on drift.

## FAQ

### How do I install the sbt-updates plugin?

Create a plugins file at ~/.sbt/1.0/plugins/sbt-updates.sbt for the sbt 1.x series, or at ~/.sbt/0.13/plugins/sbt-updates.sbt for the 0.13.x series, containing addSbtPlugin("com.timushev.sbt" % "sbt-updates" % "x.x.x") with a real published version. Installing it as a global plugin is the preferred setup, because that is what allows plugin update checks to work.

### How do I check for updates to other sbt plugins?

Run the reload plugins command, then run dependencyUpdates again in the same session. You can chain both into one invocation with sbt ";dependencyUpdates; reload plugins; dependencyUpdates". Only plugins defined in a project are checked, and global plugins cannot be checked.

### Can I make the build fail when dependency updates are available?

Yes. The dependencyUpdatesFailBuild setting makes the dependencyUpdates task fail a build if updates are found, which is useful in CI. Pair it with dependencyUpdatesReport to write the list to a file, by default target/dependency-updates.txt.

### Which sbt versions does sbt-updates support?

sbt 0.13.9 and later are required, sbt 1.x is supported since version 0.3.1 of the plugin, and sbt 2.x is supported since version 0.7.0.

## Sources

- [Issues](https://github.com/rtimush/sbt-updates/issues)
- [License: BSD-3-Clause](https://github.com/rtimush/sbt-updates/blob/master/LICENSE)
- [README](https://github.com/rtimush/sbt-updates/blob/master/README.md)
- [Releases](https://github.com/rtimush/sbt-updates/releases)
- [rtimush/sbt-updates on GitHub](https://github.com/rtimush/sbt-updates)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rtimush-sbt-updates