How OpenClaw Ships Releases: Three Channels, a Weekly Beta Train, and an Agent as Gatekeeper

OpenClaw posted a video on X in which @dallinfinite explains how they ship releases. The original post calls it one of the largest open-source projects in history; let's set that title aside—the release process itself has substance.

They use three channels: dev, beta, and stable. Code in development goes to dev, there is one beta train per week, and stable releases come out of beta. Each release is overseen by an agent session. The video goes through the details.

For general readers, dev is the development version, beta is the test version, and stable is the stable version. A beta train can be thought of as a weekly test train: it leaves on schedule and doesn't wait for anyone. For readers with a development background, the point isn't the terminology but the cadence: fixed windows, fixed channels, fixed checkpoints. Releases are no longer someone's moment of courage.

One reply said that having one agent on the weekly beta is cleaner than most release dashboards. Another said they used to ship releases with gut courage, and users paid for it with broken mornings; now they want to copy the one-agent review step first—have it run before humans see the build. Someone else complained that after every update they have to go back into developer mode and fix the config before it will run; shipping fast is one thing—surviving the update is the real release.

Taken together, these reactions make the value and the cost of the process clear. A fixed beta train lowers the risk of big-bang releases, but as update frequency goes up, compatibility and configuration costs on the user side get magnified. An agent as gatekeeper doesn't mean no one is accountable; it takes repetitive checks out of human hands and turns releases into repeatable actions. The video explains the actual implementation more clearly than text can.

Original post link: https://x.com/openclaw/status/2118803977882181986