Ring Promoter: Modern CI/CD You Cannot Miss for AI-Powered Deployments

Ring Promoter is Workstation’s modern CI/CD promotion control plane — the tool you cannot miss for AI-powered deployments. It moves versions of many applications through ordered deployment rings int → test → acc → prod with live health gates, optional version verification, automatic rollback, and a full audit trail. Product site: https://www.ringpromoter.com/ · source: github.com/bwalia/ring-promoter. Companion: blog · product page: /ring-promoter.

1. Positioning: CI/CD for the AI shipping era

AI platforms do not ship like a single monolith. You promote inference services, agent runtimes, MCP gateways, RAG APIs, and supporting microservices on different clocks — often from different repos and different deploy mechanisms (Kubernetes vs VM CI). Classic “merge to main and hope” pipelines skip rings, fake green health, and leave no shared promotion protocol across apps.

Ring Promoter is the missing control plane: one ordered set of rings, many applications, strict promotion rules, and swappable deployers. It is small enough to run on k3s, serious enough for production history and cross-replica locks, and designed so AI workloads and classical services share the same promotion language.

2. The ring model

Rings are shared and ordered (defined once). Each managed application declares, per ring, where it lives and how to reach it — namespace, Deployment, container, image repository, and a health URL. That mapping lives in configuration, not code.

Ring	Role	Typical AI use
int	Integration	First landing for agent/API builds
test	Test	Eval suites, canary traffic, load smoke
acc	Acceptance	Stakeholder / staging gate
prod	Production	Customer-facing AI and APIs

3. Promotion rules (non-negotiable)

• One ring at a time; never skip. promote {from_ring} always targets the next ring in the pipeline.
• Source must be healthy before promotion proceeds (live health check).
• After deploy, the service runs a health check with configurable retries.
• If the target stays unhealthy after retries, it is automatically rolled back to the previous version.
• Every seed / promote / rollback is written to history, success or failure.
• Auto-promote (optional, per ring): a healthy landing can continue onward in the same locked operation — e.g. auto-promote on test so int → test carries on to acc, while acc stays human-gated before prod.

4. Version-verified health (critical for AI)

A plain URL check can be fooled: the deploy “succeeds” but an old inference sidecar or previous agent binary still answers 200 OK. If a ring sets health_version_field (JSON field in the health response, e.g. version or dotted build.version) or health_version_header (e.g. X-App-Version), every post-deploy check also requires the endpoint to report the exact version that was just deployed — otherwise the check fails and auto-rollback kicks in. The same source verifies the source ring really runs the version about to be promoted.

On a ref-pinned ring (ref: release) the expected version is not knowable up front — the pipeline decides what the ref ships — so the field is used the other way: after a healthy deploy the ring records the version the endpoint reports instead of the ref name.

5. Deployers and executors

Clean interfaces keep the promotion engine stable while backends swap:

Concern	Production impls
Deploy	KubectlDeployer, GitHubActionsDeployer, k8sjob
Execution	GitHub Actions executor; Kubernetes Jobs executor
Health	HTTPChecker (dev: always-healthy fakes)
Persistence	Postgres (prod) / memory (dev)

• KubectlDeployer — shells out to kubectl set image + rollout status, authenticating in-cluster via ServiceAccount.
• GitHubActionsDeployer — for VM/CI apps that already have a pipeline: triggers workflow-dispatch, waits for conclusion, then applies the same health + rollback logic.
• k8sjob — runs seed/promote/rollback as a Job in ring-exec; runner env (RP_APP, RP_RING, RP_VERSION, …); stdout streams to step logs; exit code decides success.

The deployer is selected per application, so one control plane can promote Kubernetes apps and VM/CI apps side by side — useful when AI training jobs stay on VMs while serving runs on Kubernetes.

6. Concurrency and reliability

• Operations on the same application are serialized by a store lock. Postgres uses a session advisory lock, so serialization holds across replicas.
• Seed/promote/rollback runs under a context detached from the HTTP request and bounded by operation_timeout — a client disconnect cannot abort an in-flight deploy or its automatic rollback.
• Stored state updates as soon as a deploy lands, so it never lags the cluster even if a later health check and rollback both fail.

7. Why Workstation ships Ring Promoter for AI

Workstation builds AI workstations, private AI, agent platforms, and edge products (including Workstation WSL Proxy). Those stacks need a promotion protocol that treats “AI-powered deployments” as first-class: many apps, mixed deployers, version-honest health, and human gates where they matter. Ring Promoter is that protocol — open at ringpromoter.com and integrated into Workstation solution conversations as the modern CI/CD control plane you cannot miss.

Operators / CI / Agents
    → Ring Promoter (UI + REST API)
        → seed / promote / rollback
        → Deployer (kubectl | GitHub Actions | k8sjob)
        → Health (HTTP + optional version verify)
        → Store (Postgres history + locks)
Rings: int → test → acc → prod

8. Getting started

1. Visit https://www.ringpromoter.com/ for product context and demos.
2. Clone github.com/bwalia/ring-promoter and run locally or on k3s.
3. Read the Workstation product page and the blog summary.
4. Talk to Workstation about CI/CD for AI platforms via contact.

Published by Workstation. Upstream docs: README and design notes in the Ring Promoter repository.

Product site: https://www.ringpromoter.com/