OpenCode Download — latest signed builds.

How the OpenCode Download channels are organized.

The OpenCode download page publishes three parallel channels: stable, LTS, and nightly. Each is signed with the same pinned key so verification tooling does not have to branch on channel.

The stable channel is the default. It ships every six weeks, carries the latest feature set, and is what developers running the CLI or the desktop app on a laptop should pick. The LTS channel is a once-a-year cut that collects stable for twelve months and then adds six more months of security-only patches, for a total of eighteen months of support per LTS line. The nightly channel is a daily rebuild of main, published to its own directory so it cannot be accidentally served to a stable user; it is the right choice for a platform team validating an unreleased feature ahead of stable freeze.

Signed builds and reproducible provenance.

Every OpenCode download is signed with a Sigstore-rooted key. The detached signature, the SHA-256 checksum, and the build attestation are published next to the binary.

Reproducibility is not a claim — it is a check. Every release is built twice in isolated environments and the output is compared byte-for-byte. If the build does not reproduce, the release is held. Downstream distributors can rebuild from the tagged source and compare their output against the published hash before republishing. This is the same posture documented in the NIST supply chain risk management guidance and is the control that most procurement teams ask for by name.

LTS policy for the OpenCode download.

LTS exists for teams that cannot absorb a breaking change every six weeks. One LTS tag per year, eighteen months of security fixes.

Each LTS release carries a pinned set of supported operating systems, a frozen tool protocol version, and a public deprecation schedule. Features slated for removal are announced in the LTS announcement and removed no sooner than the next LTS, which gives regulated teams a full twelve-month window to migrate. Security fixes are backported; behavioral changes are not. A team that pins to an LTS tag gets predictable behavior, a steady SBOM, and a build attestation that does not shift under them.

Nightly vs stable.

Nightly is a daily build of main published for early adopters. It is signed, it has an SBOM, and it is not recommended for production work.

Nightly is the right channel when you want to validate an upcoming feature against your own repository a week or two before it ships on stable. Each nightly is labeled with the git short hash and the build date, so regressions can be bisected precisely. The stable channel never auto-upgrades onto nightly; switching channels is explicit, done with opencode self-update --channel nightly, and reported by opencode doctor.

Checksums, signatures, and SBOMs on every OpenCode download.

The OpenCode download page links every artifact to four companion files: the SHA-256 checksum, the detached Sigstore signature, the bundle metadata, and the CycloneDX 1.5 SBOM. Verification is scriptable.

# Verify the binary you just downloaded
shasum -a 256 -c opencode-v2026.4.0-linux-x86_64.tar.gz.sha256

# Verify the signature
cosign verify-blob \
  --certificate-identity "release@opencode.gr.com" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --signature opencode-v2026.4.0-linux-x86_64.sig \
  --bundle opencode-v2026.4.0-linux-x86_64.bundle \
  opencode-v2026.4.0-linux-x86_64.tar.gz

# Inspect the SBOM
cyclonedx-cli validate --input-file opencode-v2026.4.0.cdx.json

Keep the bundle metadata alongside the binary if you mirror it internally. Running the verify step on every mirror hop — from the OpenCode download page, to your internal object store, to a developer laptop — is the control that proves the artifact is the one we shipped.

Mirror list.

Regional mirrors in Europe, North America, and Asia-Pacific serve the same artifacts with the same signatures. The mirror list is published on this OpenCode download page and signed with the same release key.

Verification does not care which mirror an artifact came from. The pinned identity is the release pipeline, not the host that served the file, so a binary pulled from a regional mirror validates identically to one pulled from the canonical origin. That property is what lets large fleets mirror the OpenCode download into a private object store and still satisfy an auditor that the binary on the workstation is the same one we published.

How procurement teams evaluate an OpenCode download.

Procurement teams look for four things in a developer-tool download: a signed binary, a reproducible build, a documented SBOM, and a published disclosure channel. The OpenCode download satisfies all four out of the box.

The binary is signed with a pinned Sigstore identity. The build reproduces byte-for-byte. The SBOM is CycloneDX 1.5 and lists every upstream dependency with version and license. The disclosure channel is published on the trust and safety page and mirrored at security@opencode.gr.com — an alias handled by the maintainer council. Procurement packets align to NIST software quality group guidance and are refreshed every LTS cycle.

Endpoint management.

Endpoint management teams pin one version across the fleet and update on a cadence. The OpenCode download page lists every artifact URL with a predictable path, so fleet automation can fetch the latest stable or LTS without scraping HTML.

A small JSON manifest at /download/stable.json lists the current stable version, the LTS version, and the artifact URLs for each OS and architecture. Endpoint management tools poll the manifest, compare to the pinned version, and either stage or push the update according to policy. The manifest is signed; rolling back to a prior pinned version is a one-line change in the manifest URL.