deno upgrade: Manage the Deno Version
deno upgrade replaces the running Deno binary with a newer (or specified) release.
deno upgrade is great locally, but in CI you generally pin the version in the setup step instead of upgrading inside the job.
What it does
deno upgrade downloads a Deno release and replaces the current executable. Without flags it moves to the latest stable; --version pins an exact release and --canary tracks the bleeding edge.
Common usage
deno upgrade
deno upgrade --version 2.1.4
deno upgrade --canary
# in CI, prefer pinning at setup instead:
# uses: denoland/setup-deno@v2 with deno-version: 2.1.4Options
| Flag | What it does |
|---|---|
| --version <ver> | Upgrade (or downgrade) to a specific version |
| --canary | Switch to the latest canary build |
| --output <path> | Write the new binary to a path instead of replacing |
| --dry-run | Show what would be installed without doing it |
In CI
Pin the Deno version in the setup-deno action (or your container image) rather than running deno upgrade inside a job, so builds are reproducible. Calling deno upgrade at runtime makes the toolchain version depend on the day the job ran, which defeats caching and reproducibility.
Common errors in CI
"Permission denied" replacing the binary means the install path is not writable by the CI user; pin at setup instead. "Version <x> not found" means a non-existent release string. On a read-only or hermetic runner, deno upgrade simply cannot work, which is another reason to pin.