Recently on Slack, someone asked whether they could promote straight from Unstable to Stable since their main branch is already production-ready for SaaS. The answer is yes, but it misses a more useful question: what’s the difference between the cadence at which you can release and the cadence at which your customers can consume? Get that right and Replicated becomes a natural extension of the development and delivery process you already have.
Alas, there’s always a much longer version when it comes to making technology decisions. My Slack reply turned into a treatise on all the different ways you can bring the Platform into your development lifecycle and releases process. That seemed much more suited for a community post than what would invariably come across as a rant on Slack.
Channels and Channel Types
Every Replicated application starts with three default channels: Unstable, Beta, and Stable. You can create as many custom channels as you need beyond those. The channel types below mix both defaults and custom channels I create to fit the release lifecycle.
Feature Channels
Every feature branch gets its own channel. This sounds like overkill until you see how it plays out in practice. When someone opens a PR, the reviewer can pull actual bits from that channel and run them in a cluster instead of just reading diffs. Your QA engineer can validate the feature before it merges. You can test it yourself without building locally.
Create them automatically in CI. Name them after the branch. Delete them when the branch merges. The overhead is near zero and the payoff is immediate.
Unstable
This is where merged code lands. Every PR that passes review and gets merged triggers a release to Unstable. Think of it as your integration channel. Nothing here has been blessed for customer use, but everything here has passed your CI checks and at least one human review.
I make Unstable the target for all CI-driven releases regardless of what other channel strategy I’m running. It’s the single source of truth for “what’s merged.”
Alpha
Alpha isn’t one of the defaults, but it slots nicely into the flow from Unstable through to Stable. An alpha release is the first release I might expose to a customer, so it makes sense I might have one or more channels to accommodate those releases. When a customer asks to try a feature that just landed, I update their license to point at Alpha and they can pull it down. This keeps experimental work separate from anything I’d call production-ready.
One alpha channel works for most teams. You may find yourself wanting more than one based on how you release your application: different features might be in alpha independently with uncertainty about when they’ll move to beta. That’s probably a good opportunity to use license entitlements as feature flags in your release. Entitlements are key-value pairs on the customer’s license that your application checks at runtime, so a single release on one channel can expose different features to different customers. That way you have a clean release process and can still limit alpha participation as appropriate. I’ll dig into this pattern in a future post.
Beta
Beta is one of the three defaults, and it signals “we believe this works, and we want you to prove us right.” I promote from Alpha to Beta when a feature has survived internal testing and at least one customer’s environment. Beta is where I invite broader participation from customers who want early access without signing up for the rough edges of Alpha.
You may also want to follow the “license entitlements as feature flags” pattern for beta features.
Stable
Stable is your GA channel. This is the channel most customers point at, and I always recommend that the release cadence here depends on one critical question: how fast can your average customer consume updates?
In a SaaS world, you deploy whenever you want. On-prem changes the equation. Your customers have change windows, approval processes, and teams that manage upgrades on their own schedule. Stable’s cadence should match the pace your typical customer can absorb, not the pace you can ship. You can use additional channels to handle faster and slower cadences.
On the flip side, you may want your customers to always have the very latest available bits every time they upgrade. That’s a valid alternative to matching your release cadence to their ability to consume. Customers consume when they want, but they always get the very latest bits when they do. This lines up more closely with how you ship to SaaS.
How you decide depends on your customer base. If most of your customers run change windows or approval processes, cadence your Stable releases to match what they can absorb. If most of your customers auto-upgrade or run in dev-heavy environments, ship the latest bits every time. And if you have both kinds of customers, that’s what Edge is for.
Edge
Edge lets you serve both philosophies at once. Run a cadenced Stable channel for customers who expect defined releases, and run Edge alongside it for customers who want SaaS-speed delivery. Every change that passes CI and promotion flows straight to Edge. Customers on this channel get updates as fast as you can ship them.
Not every customer can handle this. But those that can will appreciate the option. Consider Edge if you’re moving fast and have the capacity to support it, but the bulk of your customers expect a more clearly defined release cadence.
Long-Term Support
The customers who move slower than the average cadence you select for Stable often have a reason. Regulated industries, large enterprises with quarterly change windows, customers who treat upgrades as projects rather than routine maintenance. An LTS channel gives them a supported version that moves on a longer cycle.
LTS helps you support these customers and build a business model around it. Offer a longer support window, a slower release cadence, and additional stability guarantees to the customers who will pay for it. Then promote the releases to their own channel for those customers to consume. Turn those slower adopters and the constraints they face into a revenue opportunity.
The Promotion Flow
Everything starts in a feature branch with a CI pipeline that builds, tests, signs, and packages a release for every change. Those releases are available for end-to-end testing and PR review on a channel that directly maps to that branch. Use version numbers here that reflect the circumstance, typically with build metadata to distinguish the release. You may even choose to disable semver enforcement on the channel and use the commit hash as your version label, letting Replicated’s auto-assigned sequence numbers handle ordering.
Once you merge your code, another workflow takes over and releases to Unstable. That release is ready for wider internal validation and on the path to promotion. This is most often from the main branch, but I’ve also seen workflows with dev or some other pre-release integration branch. Those are also a good source for Unstable releases.
I generally use tagging to drive a CD pipeline from there, though I’ve also been known to use promotion-specific workflows that are manually triggered. My tagging flows follow semver, so 1.0.3-alpha.4 promotes to Alpha while 1.0.3-beta.1 promotes to Beta. I drop the pre-release signifier to release 1.0.3 to Stable. This pipeline often creates additional artifacts and has additional checks that don’t apply to feature channels or Unstable.
Edge gets most of the same releases as Unstable, but with the additional artifacts and assurances of a customer-facing release, some of which may be manual. LTS branches off from Stable at defined intervals.
