Skip to content
arbe docs

Releases

The CLI ships as standalone arbe binaries built with bun build --compile. This page is the durable contract — installer scripts, Quickstart, and release tooling reference it. Change here first, then update consumers.

Targets

darwin-arm64, darwin-x64, linux-x64. linux-arm64 is deferred.

Versioning

There is no semver. A release is identified by the git commit SHA and build date baked into the binary at compile time. arbe --version reports:

arbe 34b67d0 (2026-04-13)

Artifacts

dist/release/latest/arbe-<target>.tar.gz   # contains a single `arbe` at archive root
dist/release/latest/SHA256SUMS             # `<sha256>  <filename>`, sorted, one per line
dist/release/latest/release.json           # build metadata, becomes latest.json on upload

Download URLs

One channel: latest (mutable) — always the newest published build.

https://downloads.arbe.0sk.ar/arbe/latest/arbe-<target>.tar.gz
https://downloads.arbe.0sk.ar/arbe/latest/SHA256SUMS

latest.json (mutable metadata) — machine-readable update metadata:

https://downloads.arbe.0sk.ar/arbe/latest.json

Shape:

{
  "commit": "34b67d0...",
  "published_at": "2026-04-13T11:05:00.000Z",
  "artifacts": {
    "darwin-arm64": {
      "url": "https://downloads.arbe.0sk.ar/arbe/latest/arbe-darwin-arm64.tar.gz",
      "sha256": "...",
      "size": 12345678
    }
  }
}

Because latest/ is mutable, the tarball and SHA256SUMS must be fetched together — pulling them at different times can mismatch. latest.json is the only stable metadata pointer and exists for the CLI update-check flow. The commit SHA baked into the binary (arbe --version) is authoritative for “what build do I have.”

Release flow

Advance the release bookmark to the commit you want to ship and push it:

jj bookmark set release
jj git push --bookmark release

The cli-release GitHub Actions workflow triggers on pushes to the release branch, runs bun run release:build and bun run release:upload, and overwrites arbe/latest/.

The workflow reads CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_API_TOKEN from repo secrets — wrangler picks them up automatically, no interactive login in CI. One-time setup in deployment.md.

Build

bun run release:build

Wraps scripts/release-build.ts: resolves commit SHA + UTC timestamp, compiles each target with --define process.env.ARBE_BUILD_COMMIT and process.env.ARBE_BUILD_DATE baked in, tars, writes SHA256SUMS, and writes release.json. dist/release/latest/ is wiped on each run.

arbe --version reports the baked-in commit SHA and date. In dev (no defines), it reports arbe dev.

Upload

The workflow runs this automatically. As a break-glass path — e.g. an Actions run failed mid-upload, or R2 is being poked at by hand — invoke it directly:

bun run release:upload

Wraps scripts/release-upload.ts: uploads everything from dist/release/latest/ to arbe/latest/ in R2, then writes arbe/latest.json from release.json. Always overwrites.

Local invocation requires bunx wrangler whoami to be authed against the oskar@rough.dk Cloudflare account. In CI the same script runs with CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_API_TOKEN in the environment. The bucket and custom domain are provisioned once — see deployment.md.