Automated Releases

Automated Releases

Once a release source is connected, publishing a release becomes a hands-off pipeline from your repository to your customers' downloads.

The Flow

1. You publish a release (or push a tag, for providers where that applies) on the connected repository
2. The provider's webhook notifies the platform, which stages the source code and dispatches a signed build request
3. The build runs inside an isolated sandbox — a dedicated, capped, non-root Docker-in-Docker environment kept separate from your production containers
4. The finished artifact is checksummed and stored on the releases disk (Cloudflare R2 or S3-compatible storage)
5. A Product Release is created automatically, with its changelog captured from the body of the release you published
6. The release becomes available through the existing licensed download chain — the same path manual releases already use

Isolation & Safety

Every build runs in a throwaway sandbox: no host bind mounts, a capped memory/CPU/process budget, and a non-root user. The sandbox has no access to production data, license signing keys, or your Git credentials — only the source it was asked to build. A failed or misbehaving build can only damage its own disposable container; it never touches the current published release.

Watching a Build

Track progress under Admin → Licensing → Builds. Each build moves through Queued → Dispatched → Building → Uploaded → Verifying → Published, or Failed if any step errors — the currently published release is never touched on failure. Failed builds can be retried once the underlying issue is fixed.

Changelog Capture

When the release event carries a description (GitHub release notes, GitLab release description, and similar), it is copied directly into the new Product Release's changelog — no manual re-entry needed. You can still edit it afterward.