Skip to main content

upd logo

upd

Update dependencies across a polyglot repository—locally, safely, and in one command.

Python · Node.js · Rust · Go · Ruby · .NET · Gradle · Docker · Terraform · Nix flakes · GitHub Actions · pre-commit · Mise

crates.io PyPI CI License: MIT

upd gives you one reviewable update plan across mixed stacks. It preserves hand-written constraints, comments, and formatting; previews every proposed change before it writes; and runs without a hosted service or repository onboarding.

Try it now

From any directory inside a Git repository:

uvx upd

That first run is a dry run: it reports what would change and leaves every file untouched. No repository onboarding or hosted account is required. Review the plan, then apply it with uvx upd --apply.

upd previewing six dependency updates across four files without changing them

One preview across four file types. Nothing changes until you pass --apply.

Install another way · See every supported file · Compare dependency tools

Why upd

  • One command for a mixed stack. Check application dependencies, tool versions, container images, GitHub Actions, pre-commit hooks, and Terraform modules in the same run instead of assembling a different updater for each file type.
  • Safe on the first run. Dry-run is the default, constraints and formatting are preserved, and major updates are called out before you decide what to apply.
  • Local first, automation ready. Start with an interactive terminal review, then use the same CLI, configuration, stable exit codes, JSON/SARIF output, and rolling PR or MR workflows in CI.

upd is a local checker and editor, not a package manager or a hosted update bot. It can delegate lockfile refreshes to the package managers already in your project and can run inside your own GitHub or GitLab automation. A refresh writes the lockfile without installing packages or syncing an environment; the exact command per ecosystem, and the one old bun release that is the exception, are listed under Commands run by --lock. See the decision guide and dated benchmarks for an exact comparison with adjacent tools.

For uv projects, upd update --apply --lock runs exactly uv lock after changing a manifest with an existing lockfile (at the workspace root when applicable). It passes no flags and never runs uv sync; synchronize your Python environment separately. Without --lock, a normal update refreshes neither the lockfile nor the environment. upd audit --fix-audit --apply refreshes applicable lockfiles by default; --no-lock opts out.

Where upd fits

Choose by the job rather than treating every dependency tool as interchangeable:

If you need to… Start with…
Preview and edit versions across a mixed-language repository from one local command upd
Resolve, lock, install, and manage a Python environment uv or PDM
Continuously create update branches and PRs across the broadest manager catalog Renovate or Dependabot
Enforce immutable GitHub Actions references as a dedicated policy pinact or ratchet

Dated performance evidence

On the committed 18-reference fixture, the verified 2026-08-28 run recorded:

Workload upd mean Same-workload cohort
Check 12 Python constraints 134.7 ms uppd: 269.7 ms
Update 12 Python constraints 138.7 ms uppd: 250.8 ms
Check 6 GitHub Actions 758.7 ms taze: 1,019.0 ms; ratchet: 1,029.1 ms
Update 6 GitHub Actions 746.3 ms taze: 566.3 ms; ratchet: 1,066.8 ms

Lower is better. These are five-run live-network observations, not universal speed claims. Every timed update was first verified to change all intended references and leave a parseable result. See the full matrix, methodology, variance, commands, and raw JSON.

Features

  • Multi-ecosystem: Python, Node.js, Rust, Go, Ruby, .NET, Docker, Terraform, Nix flakes, GitHub Actions, pre-commit, Mise/asdf
  • Dry-run by default: nothing is written without --apply
  • Fast: parallel registry requests, with a 24-hour version cache
  • Constraint-aware: respects >=2.0,<3 (Python), ~> 7.1 (Ruby), and ^2.0.0 / ~2.0.0 (npm, Cargo)
  • Format-preserving: keeps formatting, comments, and structure
  • Update filters: --only-bump, --max-bump, --package (exact names or quoted globs such as 'shiny*'), --lang, --exclude-lang, or approve one by one with -i
  • Major warnings: breaking changes are flagged with (MAJOR)
  • Pre-release aware: updates pre-releases to newer pre-releases
  • Cooldown: hold back releases younger than N days, against supply-chain attacks
  • Security auditing: OSV vulnerability scanning with auto-fix and SARIF output
  • Check mode: exit 1 if updates are available (for CI and pre-commit)
  • Gitignore-aware: honors .gitignore and prunes hidden directories, without missing the dotfiles it updates
  • Private registries: authentication for PyPI, npm, Cargo, Go, and GitHub
  • Config file: include or exclude paths, ignore packages, and pin versions via .updrc.toml

Installation

From crates.io

cargo install upd

# or with cargo-binstall (faster, pre-built binary)
cargo binstall upd

From PyPI

pip install upd
# or with uv
uv pip install upd

If you installed an earlier release under the old distribution name, migrate once with pip uninstall upd-cli && pip install upd. The upd-cli command remains available as a compatibility alias.

From source

git clone https://github.com/rvben/upd
cd upd
cargo install --path .

Usage

# Preview changes without modifying files (default when no --apply)
upd

# Apply updates to files
upd --apply

# Limit to specific files or directories
upd --apply requirements.txt pyproject.toml

# Approve updates one by one
upd -i

# Only the packages you name
upd -p requests,flask

# Select a package family (quote globs so your shell passes them to upd)
upd --package 'shiny*'

# Cap the bump level (allow patch + minor, skip major). Updates above the
# ceiling are reported as held back, never as up to date, and do not
# change the exit code.
upd --max-bump minor

# Restrict to exactly one level (repeatable, comma-separated)
upd --only-bump major

# Write nothing but registry versions at that level: pins, flake revisions
# and other level-less writes are reported as held instead of written
upd --only-bump major --strict-bump

# One ecosystem at a time: python, node, rust, go, ruby, dot-net,
# docker, terraform, nix, actions, pre-commit, mise, annotated
upd --lang python

# Both pre-commit YAML and prek.toml, including supported hook dependencies
upd --lang prek

# Exit 1 if anything is outdated (for CI and pre-commit)
upd --check

# Regenerate lockfiles after writing; a failed refresh rolls its directory back
upd --apply --lock

# Print the effective configuration and exit
upd --show-config

upd --help lists every flag; Stability documents the ones that are contractual, and upd schema emits the whole interface as JSON.

--package accepts exact names and case-sensitive globs using *, ?, and character classes such as [ab]. Wildcards can cross namespace separators, so patterns such as '@scope/*' and 'github.com/org/*' work as expected. Quote globs on the command line to prevent shell expansion. A glob that matches no package produces a warning without changing the exit code; use repeated or comma-separated values instead of brace alternation.

Dry-run by default: upd without --apply only previews changes. Pass --apply to write updates. --check, --dry-run, and --interactive do not require --apply.

VCS-root scoping: When no path argument is given, upd scans from the nearest .git ancestor directory rather than the current working directory. This prevents accidental rewrites when CWD is a subdirectory inside a repository.

Commands

upd --version      # Print version
upd self-update    # Check for upd updates
upd clean-cache    # Clear the version cache
upd lock-refresh   # Refresh uv, npm, and Cargo locks within manifest constraints
upd align          # Align versions across files (--check exits 1 on misalignment)
upd audit          # Scan for known vulnerabilities (exit 6 if found)
upd schema         # Machine-readable interface description

For repositories replacing dependency bots, upd also provides separate reusable GitHub workflows for policy-constrained freshness updates and validated security-remediation pull requests. See GitHub dependency pull requests.

Example Output

.pre-commit-config.yaml:37: Would update pre-commit/pre-commit-hooks v4.6.0 → v6.0.0 (MAJOR)
.github/workflows/ci.yml:16: Would update actions/checkout v4 → v6 (MAJOR)
.github/workflows/ci.yml:18: Would update jdx/mise-action v2 → v4 (MAJOR)
.mise.toml:8: Would update rust 1.91.1 → 1.94.0
Cargo.toml:33: Would update clap 4.5.53 → 4.6.0
Cargo.toml:36: Would update tokio 1.48.0 → 1.50.0

Would update 6 package(s) (2 major, 3 minor, 1 patch) in 4 file(s), 8 up to date

Output includes clickable file:line: locations (recognized by VS Code, iTerm2, and modern terminals).

Version Constraints

upd respects version constraints in your dependency files:

Constraint Behavior
>=2.0,<3 Updates within 2.x range only
^2.0.0 Updates within 2.x range (npm/Cargo); never crosses the major bound
~2.0.0 Updates within 2.0.x range (npm); ~2.0.0 (Cargo) stays within 2.0.x
~> 7.1 Updates within 7.x range (Ruby pessimistic)
>=2.0 Updates to any version >= 2.0
==2.0.0 Updates the exact pin to the latest version (e.g. ==2.0.0 → ==3.1.5). To freeze a package, use [pin] or ignore in .updrc.toml.
==2.0.* Never rewritten. A PEP 440 prefix match names a series, not a release. See Bounds that are not floors.

An update moves the lower bound and leaves every other clause where the author wrote it, so >=1.0, <2.0 becomes >=1.5.0, <2.0. A constraint is an unordered set of clauses, so the lower bound is found wherever it sits (<2.0, >=1.0 answers alike), and an upper bound is honored when picking the new version: the release chosen is the newest one the constraint already admits.

npm ranges keep the shape they were written in. A comparator range (">=1.0.0 <2.0.0") and a hyphen range ("4.17.0 - 4.18.0") each keep their ceiling. A wildcard or partial range takes its ceiling from its own floor, like a caret, so it follows the newest release and the whole shape moves with it: "4.3.x" becomes "4.4.x" and "^1.2" becomes "^3.1", never a fully written version. npm lets a comparator stand apart from the version it applies to, and that spacing is part of the shape: ">= 1.2.7 < 1.3.0" is read as the range it is and comes back spaced the same way. npm's tilde has two spellings and "~>1.2.3" means what "~1.2.3" does, ceiling included; each comes back spelled the way it was written.

An npm spec that names no published version is left alone and reported nowhere: "*", a dist-tag ("latest", "next", "beta"), and the workspace:, file:, link:, npm:, git+ssh: and github:owner/repo forms all resolve somewhere other than a release on the registry, so there is no version to compare and nothing an update could move.

Python bump labels and --only-bump / --max-bump follow the changed release component: 0.0.77 → 0.0.78 is patch, and 0.77 → 0.78 is minor. Other ecosystems retain their existing pre-1.0 compatibility classification. Python update reports include each declaration's section and full constraint.

Specifier shape changes are opt-in. A [normalize.pyproject] table in .updrc.toml can independently make project dependencies, optional dependencies, or standardized dependency groups use ==, >=, or <=; projects without that table retain the shape-preserving behavior above. See the configuration guide.

Bounds that are not floors

Only an inclusive lower bound names the version a project is on, so only that bound is raised. >1.2.3 names the one version its author refuses, <3 and <=3 are ceilings, != 1.5 is an exclusion, and an OR range ("^1 || ^2") has no single branch to edit. None of them is a floor, so none of them is moved. They are checked against the registry and reported anyway:

Outcome Reported as
The constraint admits the newest release Up to date
The newest release has outgrown it A warning naming the release and the constraint
The spec cannot be read at all An error, exit 2

The last row is the point of the other two: a dependency nothing looked at must not be counted as up to date, and a constraint that has quietly frozen a dependency should say so rather than pass under a green tick.

A PEP 440 prefix match reads the same way for the same reason. ==6.* and ==6.0.* name a series rather than a release, so there is no version in them to raise and nothing an update may write over them; they are checked and reported by the table above. pyyaml==6.* with 6.0.3 published is up to date, and rich==13.7.* with 15.0.0 published is a warning. [pin] and upd align answer the same way: neither writes a release into a specifier that has nowhere to hold one, and the pin reports an error rather than a rewrite.

Annotated Version Pins

Files without a dependency-manifest format can carry an inline annotation or one immediately above its value:

shinyhub_version: "0.11.16"  # upd: pypi shinyhub

Directory walks scan annotations in otherwise-unrecognized Makefile, makefile, GNUmakefile, justfile, Justfile, *.mk, *.sh, *.bash, *.yml, and *.yaml files. Any file passed explicitly is scanned as annotated. To add other files to normal repository discovery, use repository-relative globs in .updrc.toml:

include = ["deploy/*.env", "config/version.conf"]
exclude = ["**/archive/**"] # exclude wins over include

An include never changes a recognized manifest's parser: for example, a matching main.tf remains Terraform. Use --verbose to diagnose an upd: marker in an otherwise undiscovered UTF-8 text file up to 1 MiB.

Dockerfiles also scan annotated ARG and ENV versions alongside FROM updates:

# upd: pypi uv
ARG UV_VERSION=0.9.30

Use upd --apply to update both image tags and annotated versions. --lang annotated selects annotations only; --lang python selects PyPI annotations, and --lang docker selects image tags only. Place the comment immediately above a single-line ARG or ENV assignment. Docker treats inline # text as instruction arguments, so inline annotations are refused. Renovate comments such as # renovate: datasource=pypi depName=uv work too.

Downloaded GitHub release binaries can keep their version and SHA-256 together in any file scanned for annotations:

MISE_VERSION=2025.12.9 # upd: github-releases jdx/mise
MISE_CHECKSUM=afe7e9f2ea8e1704e9cc41e4b020798b8c60e5924ab4a313ccbf201a062f54d0 # upd: checksum MISE_VERSION asset=mise-v{version}-linux-x64.tar.gz

This works in Makefiles, shell scripts, YAML, GitHub workflows, and other explicitly selected text files. Add id=<name> to the version annotation when the version has no simple assignment key or the file repeats that key. The checksum references that ID. Comments may also immediately precede the value line; Dockerfiles require that form:

# upd: github-releases jdx/mise
ARG MISE_VERSION=2025.12.9

# upd: checksum MISE_VERSION asset=mise-v{version}-linux-x64.tar.gz
ARG MISE_CHECKSUM=afe7e9f2ea8e1704e9cc41e4b020798b8c60e5924ab4a313ccbf201a062f54d0

upd resolves the exact release asset's GitHub SHA-256 digest before updating both assignments. Add checksums=SHASUMS256.txt to explicitly use a release checksum manifest instead. If any linked checksum cannot be resolved, the entire version/checksum group stays unchanged. See linked release checksums for multiple architectures, templates, and diagnostics.

Check annotation syntax and checksum links without accessing any registry:

upd annotations validate Dockerfile versions.sh

upd annotations init <release-asset-url> --checksum <published-sha256> prints a linked snippet. Choose --syntax docker, shell, toml, yaml, or javascript; use --output text for plain text when piping it. Replace --checksum with --resolve-checksum to fetch the published digest online, optionally selecting a manifest with --checksums. Use --asset-template to override filename inference; it must expand exactly to the URL asset. Neither command writes files. See annotation tools for examples.

A GitHub Actions workflow keeps its Actions updater and is scanned for annotations as well, so a tool version passed to an action through a with: input can be updated beside the uses: refs around it. See GitHub Actions.

Version Precision

By default, upd preserves version precision from the original file:

# Original file has 2-component versions
flask>=2.0        →  flask>=3.1        (not 3.1.5)
django>=4         →  django>=6         (not 6.0.0)

# Original file has 3-component versions
requests>=2.0.0   →  requests>=2.32.5

# GitHub Actions major-only tags
actions/checkout@v3  →  actions/checkout@v4  (not @v4.2.0)

Use --full-precision to always output full semver versions:

upd --full-precision
flask>=2.0        →  flask>=3.1.5
django>=4         →  django>=6.0.0
requests>=2.0.0   →  requests>=2.32.5

Version Alignment

In monorepos or projects with multiple dependency files, the same package might have different versions:

# requirements.txt
requests==2.28.0

# requirements-dev.txt
requests==2.31.0

# services/api/requirements.txt
requests==2.25.0

upd align updates every occurrence to the highest version found:

upd align              # Align all packages to highest version
upd align --dry-run    # Preview changes
upd align --check      # Exit 1 if misalignments (for CI)
upd align --lang python # Align only Python packages

It only aligns within one ecosystem, skips packages with upper bound constraints (e.g. >=2.0,<3.0) to avoid breaking them, and ignores pre-release versions when finding the highest version.

Pre-commit Integration

Add upd to your .pre-commit-config.yaml:

repos:
  - repo: https://github.com/rvben/upd-pre-commit
    rev: v0.0.24
    hooks:
      - id: upd-check
        # Optional: only check specific ecosystems
        # args: ['--lang', 'python']

Available hooks:

Hook ID Description
upd-check Fail if any dependencies are outdated
upd-check-major Fail only on major (breaking) updates

Both hooks run on pre-push by default. Uses language: python which installs upd from PyPI automatically, so no manual installation is needed.

Documentation

Everything you look up rather than read lives in docs/.

Releases

Vership workflow, publication guarantees, automated integration pins, and safe retry procedures. → docs/releases.md

Supported files

Every file upd discovers, per ecosystem, plus annotated version pins in files it does not otherwise understand. → docs/ecosystems.md

Comparison and benchmarks

A dated feature matrix for related dependency tools, plus workload-based, reproducible benchmarks that avoid ranking unlike operations. → docs/comparison.md

Security auditing

OSV vulnerability scanning, --fix-audit, SARIF output, and CI integration. → docs/audit.md

Security policy

Private vulnerability reporting, supported versions, trust boundaries, and release integrity. → SECURITY.md

Configuration file

.updrc.toml discovery order and every key it accepts. → docs/configuration.md

Cooldown (minimum release age)

Hold back versions published less than N days ago, per ecosystem or per language, and keep --lock refreshes to the same cooldown. → docs/configuration.md#cooldown-minimum-release-age

Caching

Where the 24-hour version cache lives and how to clear or bypass it. → docs/configuration.md#caching

Environment variables

Every variable upd reads, in one table. → docs/configuration.md#environment-variables

Private repositories

Credential detection for PyPI, npm, Cargo, Go, and GitHub, including private indexes declared in pyproject.toml. → docs/private-registries.md

GitHub pull requests

Run any supported dependency updates as one rolling GitHub PR, with immutable Action SHA verification, validation, artifact reporting, and opt-in auto-merge. → docs/github-actions.md

GitLab merge requests

Run scheduled dependency updates as one rolling GitLab MR, with validation, lease-protected branch updates, and explicitly opt-in GitLab-native auto-merge. → docs/gitlab.md

Stability

The stable CLI surface, exit codes, --lock commands, and output guarantees. → docs/stability.md

Development

# Build
make build

# Run tests
make test

# Lint
make lint

# Format
make fmt

# All checks
make check

License

MIT

Metadata

Release files for upd 0.16.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for upd 0.16.0
File Size Uploaded
upd-0.16.0.tar.gz 1.3 MB Details

Built distributions (wheels)

Table of built distributions (wheels) for upd 0.16.0
File
upd-0.16.0-py3-none-win_amd64.whl Python 3 none Windows x86-64 Details
upd-0.16.0-py3-none-musllinux_1_2_x86_64.whl Python 3 none Linux musl 1.2+ x86-64 Details
upd-0.16.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl Python 3 none Linux glibc 2.17+ x86-64 Details
upd-0.16.0-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl Python 3 none Linux glibc 2.17+ ARM64 Details
upd-0.16.0-py3-none-macosx_11_0_arm64.whl Python 3 none macOS 11.0+ ARM64 Details
upd-0.16.0-py3-none-macosx_10_12_x86_64.whl Python 3 none macOS 10.12+ x86-64 Details

Total release size: 42.1 MB

Release files / upd-0.16.0.tar.gz

Download URL upd-0.16.0.tar.gz
Size 1.3 MB
Tags Source
SHA-256 checksum
How to use checksums
d3a414dbd86ae41c6b416ddd1084ffcd7b4288609e44ecf7007df24f36656991
BLAKE2b-256 checksum
How to use checksums
d005dd48267a66af0262ace9af024d73a42fde6bc72722c08a2f5081f31582bf
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Release files / upd-0.16.0-py3-none-win_amd64.whl

Download URL upd-0.16.0-py3-none-win_amd64.whl
Size 6.2 MB
Tags Python 3 Windows x86-64
SHA-256 checksum
How to use checksums
f78433cc0ce0931511776642523a3022a597215b68b8c13df959f3bf5c5e3420
BLAKE2b-256 checksum
How to use checksums
b4133118cd2950e5afaade0e57eaaaa4659b5ba05054d3d0e18f58aa60a16740
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Release files / upd-0.16.0-py3-none-musllinux_1_2_x86_64.whl

Download URL upd-0.16.0-py3-none-musllinux_1_2_x86_64.whl
Size 7.9 MB
Tags Linux musl 1.2+ x86-64 Python 3
SHA-256 checksum
How to use checksums
99b7916c71f39768bc1ee0f24d723a1764eff9f9e0a93cc458895258f5eb30ad
BLAKE2b-256 checksum
How to use checksums
bddc708a10dfb826695919655ea6a71b820fc7a41f53b718fbcf4c7d2ff2dd6b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Release files / upd-0.16.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

Download URL upd-0.16.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Size 7.9 MB
Tags Linux glibc 2.17+ x86-64 Python 3
SHA-256 checksum
How to use checksums
0e0d9a0de7e1b7b48cfdb904ae72f5735514cae875efa2416a36dac187775c49
BLAKE2b-256 checksum
How to use checksums
3eff34d4ed514cdd87e4569e3b27d89423a979659f576d49bd637d8b3de1bfd0
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Release files / upd-0.16.0-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl

Download URL upd-0.16.0-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Size 7.8 MB
Tags Linux glibc 2.17+ ARM64 Python 3
SHA-256 checksum
How to use checksums
d442e6e498483cc6fde2d40e36f44bc774c59cebd44b0dff73dbe106435d4831
BLAKE2b-256 checksum
How to use checksums
edb7bb00c9a6ea37bd320da3562203fd29e470220610971a44b35a4a6c183581
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Release files / upd-0.16.0-py3-none-macosx_11_0_arm64.whl

Download URL upd-0.16.0-py3-none-macosx_11_0_arm64.whl
Size 5.3 MB
Tags Python 3 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
debb502d24e11bcc6437253cd9efb5562a7568f4dd5e6df5991b96ca416ed491
BLAKE2b-256 checksum
How to use checksums
e1492ea67c415254c34b8394d5db945146d62fc52b6437567c61b9c833992a07
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Release files / upd-0.16.0-py3-none-macosx_10_12_x86_64.whl

Download URL upd-0.16.0-py3-none-macosx_10_12_x86_64.whl
Size 5.7 MB
Tags Python 3 macOS 10.12+ x86-64
SHA-256 checksum
How to use checksums
ac2ae1fcd1c4e9d48b45e7ca9009c39c8822be57f7e5352c699371c32bad4167
BLAKE2b-256 checksum
How to use checksums
a2123c4be83ab9f914e861e1a2253ffce3128183e483c896da989c55ff363f71
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.3

Release history Release notifications | RSS feed

0.17.1

7 release files

0.17.0

7 release files

This release

0.16.0 This release

7 release files

0.14.4

7 release files

0.14.3

7 release files

0.14.2

7 release files

0.14.1

7 release files

0.14.0

7 release files

0.13.6

7 release files

0.13.5

7 release files

0.13.4

7 release files

0.13.3

7 release files

0.13.2

7 release files

0.13.1

7 release files

0.13.0

7 release files

0.12.4

7 release files

0.12.3

7 release files

0.12.2

7 release files

0.12.1

7 release files

0.9.2

7 release files

0.9.1

7 release files

0.9.0

7 release files

0.8.8

7 release files

0.8.7

7 release files

0.8.6

7 release files

0.8.5

7 release files

0.8.4

7 release files

0.8.3

7 release files

0.8.2

7 release files

0.8.1

7 release files

0.8.0

7 release files

0.7.1

7 release files

0.7.0

7 release files

0.6.5

7 release files

0.6.4

7 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page