Garrett Delfosse
2cbce86eee
Updates the install docs for the v2.34.0 release, branched off the latest `main`. Supersedes #25995: same release-docs update, but cut from current `main` and with every "Latest Release" link refreshed. The automated PR carried stale patch links and a `vv2.34.0` typo. ## Changes - `docs/install/releases/index.md`: regenerate the release calendar. 2.34 → Mainline, 2.33 → Stable, and every "Latest Release" link points to the current patch per minor (`2.24.6, 2.29.16, 2.30.9, 2.31.14, 2.32.5, 2.33.6, 2.34.0`). - `docs/install/rancher.md`: version selector → Mainline `2.34.0`, Stable `2.33.6`. - `docs/install/kubernetes.md`: Helm `--version` → Mainline `2.34.0`, Stable `2.33.6` (chart + OCI), matching the Rancher guide. Addresses the review feedback on #25995: the `vv2.34.0` typo, bumping Stable to `2.33.6`, and keeping the Kubernetes guide in sync with Rancher. <details> <summary>Notes for reviewers</summary> - Verified with `markdownlint-cli2` (0 errors) and `markdown-table-formatter --check` (no reformatting needed). - The calendar was regenerated via `scripts/update-release-calendar.sh`. That script's `get_latest_patch` does not exclude prerelease tags, so it selected `v2.34.0-rc.0` over `v2.34.0`; that row was corrected by hand. A follow-up fix to the script would prevent this recurring. - The linkspector 404 on `coder.com/changelog/coder-2-34` is expected for a fresh release; that page publishes alongside the release. </details> --- *Generated by Coder Agents on behalf of @f0ssel.*
5.8 KiB
Releases
Coder releases are cut directly from main in our GitHub on the first Tuesday of each month.
We recommend enterprise customers test the compatibility of new releases with their infrastructure on a staging environment before upgrading a production deployment.
Release channels
We support four primary release channels, as well as ad-hoc release candidates:
- Mainline: The bleeding edge version of Coder
- Stable: N-1 of the mainline release
- Security Support: N-2 of the mainline release
- Extended Support Release: Biannually released version of Coder
- Release Candidates: Ad-hoc builds to validate in-development features
We field our mainline releases publicly for one month before promoting them to stable. The security support version, so n-2 from mainline, receives patches only for security issues or CVEs.
Mainline releases
- Intended for customers with a staging environment
- Gives earliest access to new features
- May include minor bugs
- All bugfixes and security patches are supported
Stable releases
- Safest upgrade/installation path
- May not include the latest features
- All bugfixes and security patches are supported
Security Support
- In-product security vulnerabilities and CVEs are supported
For more information on feature rollout, see our feature stages documentation.
Extended Support Release
- Designed for organizations that prioritize long-term stability
- Receives only critical bugfixes and security patches
- Ideal for regulated environments or large deployments with strict upgrade cycles
ESR releases will be updated with critical bugfixes and security patches that are available to paying customers. This extended support model provides predictable, long-term maintenance for organizations that require enhanced stability. Because ESR forgoes new features in favor of maintenance and stability, it is best suited for teams with strict upgrade constraints. The latest ESR version is Coder 2.34.
For more information, see the Coder ESR announcement or the 2.29 to 2.34 ESR Upgrade Guide.
Release Candidates
- Ad-hoc builds that Coder releases to validate in-development features with select customers
- Not guaranteed to be stable or free of bugs
- Features introduced in an RC are not guaranteed to be included in a mainline or stable release
- Not intended for production use
Release candidates give Coder a way to push out builds for customers and other users to try out new, under-development functionality without cutting a new minor version. Unlike mainline and stable releases, RCs do not follow a fixed schedule and carry no guarantees around stability or long-term support. They exist purely as a feedback mechanism: Coder can ship targeted builds, gather real-world input, and iterate before committing changes to the standard release channels.
Installing stable
When installing Coder, we generally advise specifying the desired version from our GitHub releases page.
You can also use our install.sh script with the stable flag to install the
latest stable release:
curl -fsSL https://coder.com/install.sh | sh -s -- --stable
Best practices for installing Coder can be found on our install pages.
Release schedule
| Release name | Release Date | Status | Latest Release |
|---|---|---|---|
| 2.29 | December 02, 2025 | Extended Support Release | v2.29.16 |
| 2.30 | February 03, 2026 | Not Supported | v2.30.9 |
| 2.31 | February 23, 2026 | Not Supported | v2.31.14 |
| 2.32 | April 14, 2026 | Security Support | v2.32.5 |
| 2.33 | May 05, 2026 | Stable | v2.33.6 |
| 2.34 | June 02, 2026 | Mainline (ESR) | v2.34.0 |
| 2.35 | Not Released | N/A |
Tip
We publish a
previewimageghcr.io/coder/coder-previewon each commit to themainbranch. This can be used to test under-development features and bug fixes that have not yet been released tomainlineorstable.The
previewimage is not intended for production use.
January Releases
Releases on the first Tuesday of January are not guaranteed to occur because most of our team is out for the December holiday period. That being said, an ad-hoc release might still occur. We advise not relying on a January release, or reaching out to Coder directly to determine if one will be occurring closer to the release date.