release.garden

Getting started

Publish your first release.

Give your software a home with release pages, downloads, and install scripts. This guide uses Grove as an example; use your own project name and build files.

Use the rls CLI to manage projects and releases, and the dashboard for your team and billing. The CLI reference covers every command; the API reference covers integrations.

1. Install and sign in

Install rls on macOS or Linux:

curl -fsSL 'https://release.camp/rls/latest/install.sh' | sh

On Windows, run this in PowerShell:

irm 'https://release.camp/rls/latest/install.ps1' | iex

Then sign in:

rls login

Your browser opens to approve CLI access. If you’re new, create an account with your email first. The CLI saves its key in your system keychain.

2. Create a project

From your app’s directory, create a project:

rls project create "Grove"

The command writes rls.yml with your project’s slug:

project: grove

If grove is already taken, use the slug the CLI gives you in the examples below. Commit rls.yml so you and your CI publish to the same project.

New projects are public. The free plan is enough to start; Plus adds private projects, more storage, and larger files.

3. Publish a release

Build your app, then pass a version and the files you want customers to download. Any file format works.

rls push 1.0.0 grove.tar.gz grove.zip

The CLI uploads the files together and prints your release page URL when publication finishes. Versions can use SemVer, dates, or your own labels. Each version is unique within its project.

Add Markdown release notes with a file:

rls push 1.0.1 grove.tar.gz grove.zip --notes notes.md

Or keep a CHANGELOG.md with a heading for each version. The CLI picks up the matching section automatically. For another location, set changelog in rls.yml or pass --changelog PATH. See release notes for path resolution and overrides.

Published files and notes cannot be replaced. For a correction, publish a new version.

Share your releases

Your project page lists releases, each release gets its own page with notes and files, and the changelog brings the notes together. Public projects need no account to browse or download.

https://release.camp/grove
https://release.camp/grove/1.0.0
https://release.camp/grove/changelog

Use a versioned download to pin a file, or latest to follow the stable channel:

https://release.camp/grove/1.0.0/grove.tar.gz
https://release.camp/grove/latest/grove.tar.gz

Keep filenames consistent between releases so your latest links keep working.

Add installers

If you ship command-line tools, release.garden can generate install scripts for macOS, Linux, and Windows. Add targets to rls.yml that match your builds:

project: grove
install:
  targets:
    - os: linux
      arch: amd64
      file: grove-linux-amd64.tar.gz
      executables:
        grove: bin/grove
        grove-admin: bin/grove-admin

Each command name maps to its path inside the archive. This example installs two commands; use just grove if that’s all you ship. Use .tar.gz for macOS and Linux, or .zip with .exe files for Windows.

Include every target’s archive in your next push:

rls push 1.1.0 grove-linux-amd64.tar.gz

The release page now shows install commands. For this Linux build, customers can run:

curl -fsSL 'https://release.camp/grove/latest/install.sh' | sh

The installer detects the platform, checks the archive’s SHA-256 checksum, and installs the configured commands. See installer setup for the configuration details.

Use release channels

Releases go to stable by default. Use another channel to let customers try a build before everyone else:

rls push 1.2.0-beta.1 grove-linux-amd64.tar.gz --channel beta

Share a latest link with ?channel=beta to follow that channel. When the release is ready, promote it without uploading again:

rls promote 1.2.0-beta.1 --channel stable

The most recent publish or promotion determines a channel’s latest release, regardless of the version label. Promotion keeps the release in beta too; use --from beta --to stable to move it instead. See the channel commands.

License private releases

On Plus, make your project private before publishing software that needs restricted access:

rls project visibility private

Issue a customer license with the CLI:

rls license create "Order #1842"

Save the complete key and send it to your customer. It appears only once and cannot be retrieved later. Customers enter it on your project or release page to unlock downloads without a release.garden account.

Leave the update cutoff blank for lifetime updates. To offer a year of updates, set a cutoff:

rls license create "Order #1843" \
  --updates-until 2027-10-04T23:59:59Z

The customer keeps access to releases published on or before that cutoff, even after it passes. Later releases are excluded, and latest resolves to the newest eligible release in the selected channel.

For direct downloads, send the key as an Authorization: Bearer header. For installers, set RELEASE_GARDEN_LICENSE_KEY and copy the authenticated install command from the release page. Treat license keys as secrets.

Owners and support members can issue and revoke licenses, as can project automation keys. Revocation immediately and permanently blocks new download requests and unlocked browser sessions. Download URLs already issued can remain usable for up to one minute. Yanked releases cannot be requested with any license.

To issue licenses after a purchase, call the API from your checkout or webhook. Use an Idempotency-Key for each purchase and project to avoid duplicates on retries. A retry returns the existing license without its key, so save the first response. Attach order or customer IDs as metadata, a JSON object up to 4 KiB; it does not affect access.

See license commands and the API reference to build your integration.

Automate publishing

Create a project automation key with the CLI:

rls project key create --name "CI"

Save the key as a CI secret named RG_API_KEY. It appears only once, expires after 30 days, and can publish and manage releases and licenses for that project. Replace it before it expires.

Install rls on your runner, check out your repository with rls.yml, and add a publish step after the build. For a GitHub Actions workflow that runs on version tags:

- name: Publish a release
  env:
    RG_API_KEY: ${{ secrets.RG_API_KEY }}
  run: rls push "$GITHUB_REF_NAME" dist/grove-linux-amd64.tar.gz

Use the filenames from your build, including all configured install targets. No browser login is needed in CI. Keep the key out of source control and logs, and revoke it with rls project key revoke KEY_ID when it’s no longer needed.

You can also publish through the API. If a push loses its connection, check the dashboard before retrying; the release may already have published.

Invite your team

Use your project’s Members tab to invite collaborators by email. Both plans include unlimited collaborators.

Choose contributor for someone who publishes and yanks releases, or support for someone who issues, inspects, and revokes customer licenses. The project owner manages settings, keys, and membership.

Invitations expire after seven days. Owners can cancel pending invitations, change member roles, or remove members. You can also manage your team from the CLI.

See what’s downloaded

Open the project’s Analytics tab to see artifact downloads, installer requests, and release page views. Choose 30 days, 90 days, or all time, and compare downloads by release.

The owner’s Activity tab records project changes and actions, including who performed them.

Verify releases

The CLI signs each push, and release.garden adds a signed attestation. Release pages show whether a release is signed.

For independent verification of a public release, fetch its signature bundle and release.garden’s current or historical signing keys through the public API. The bundle includes the file manifest, publisher signature, and attestation. See signing and verification.

Manage your project

Use the CLI to rename a project, change its slug, or set its visibility. Renaming keeps your links; changing the slug changes its URLs and requires updating rls.yml.

If a release needs to be withdrawn, yank it:

rls yank 1.0.0

Yanking blocks new download requests and keeps the version reserved. It cannot be published again. Deleting a project removes the project and all its releases. Revoke any active customer licenses before deleting it.

See the project commands for settings and the pricing page for storage and file limits. Manage your plan and extra storage from Billing in the dashboard.