Workstation AI Shop on Ring Promoter: Orbit, Version-Verified Health and the Path from INT to PROD

This article is the release-engineering deep dive for Workstation AI Shop — the storefront at shop.workstation.co.uk that sells GPU machines and uses a fully autonomous AI Sales Agent to configure baskets. Companion blog (stakeholder-friendly): Promoting the AI Shop through the rings. Control-plane reference: ringpromoter.com.

Watch on YouTube · Product: ringpromoter.com

1. System under promotion

Workstation AI Shop is a Next.js server app (Helm chart shop-chart) on k3s. The browser talks only to the shop; the shop BFF calls OpsAPI in-cluster (http://workstation-opsapi/). Payments use Stripe Checkout with webhooks on OpsAPI. Catalogue freshness is a CronJob (market/sync.mjs). The AI Sales Agent uses Anthropic (ANTHROPIC_MODEL, typically claude-sonnet-5-5, CHAT_MAX_TURNS capped) — if the key is missing, chat shows offline and the rest of the shop still works.

Public hosts

• INT: https://int-shop.workstation.co.uk
• PROD: https://shop.workstation.co.uk

Edge path (prod): Cloudflare DNS (DNS-only) → wslproxy → Traefik on the edge node → shop Ingress. Prod has been pinned to a dedicated edge worker where required for latency and certificate locality.

2. Why Ring Promoter owns the hop, not the build

CI still builds and pushes wsw-shop:<sha7>. Ring Promoter answers a different question: is this exact version healthy in ring N, and is it allowed into ring N+1 right now? That matches the product framing on ringpromoter.com:

1. One ring at a time — promote always targets the next ring.
2. Source must prove health before anything deploys.
3. Target must earn health after deploy (retries, then auto-rollback).
4. Failure undoes itself to the previous recorded version.
5. Every seed / promote / rollback is written to history.

Shop-specific risk amplifies those rules: the AI agent, market sync and BFF trust keys must move together. A “green Helm job” that leaves an old chat binary answering is a silent sales failure.

3. Reading the Orbit screenshot (release semantics)

From the console capture used in this article:

• Application name: Workstation AI Shop (human label on the roster and Orbit node).
• Version in flight: 7cd70f6 (short git SHA — matches image tag convention).
• Current ring: INT — status Deploying; copy such as “has reached int, N rings to go.”
• Pipeline legend: int → test → acc → prod across the top of Orbit.
• Signals: blue node = deployment in progress; green trail = how far the newest version earned; Earth = PROD / live users.
• SLO breadcrumbs: TTFB ~71ms, location London, GB — useful in the same pane as promotion state so latency regressions are not a separate tool hop.

Lanes (APP × INT/TEST/ACC/PROD matrix) is the complementary view when you need to see whether PROD lags the SHA that already spans ACC.

4. Mapping rings to shop deploy mechanics

Ring	Shop mechanism	Gate intent
INT	GitHub Actions shop-deploy.yaml on main paths under shop/** / chart → deploys int	Engineer smoke: /api/health, agent turns, catalogue read
TEST	Ring Promoter promote INT→TEST (same image SHA)	Automated regression; market sync dry observations
ACC	Promote TEST→ACC	Stakeholder UX on AI basket; quote PDF; optional Stripe test mode
PROD	Promote ACC→PROD (+ production password). Chart prod may also be workflow_dispatch with TARGET_ENV=prod — Ring Promoter should remain the ledger of what customers run	Human gate; live secrets from vault path workstation-shop/prod/config

Important: treat Helm/workflow deploy as the deployer implementation detail. Ring Promoter remains the system of record for which SHA is current / previous per ring and whether the hop was rolled back.

5. Version-verified health for an AI storefront

Configure the shop health endpoint (or a dedicated readiness field) so Ring Promoter can assert the deployed SHA — via health_version_field or health_version_header as documented on the product site. That catches:

• Old ReplicaSets still answering while the new Deployment is stuck.
• Edge/cache serving a previous HTML shell in front of a mixed API.
• Agent worker and web process skew (chat binary ≠ storefront SHA).

Also verify the source ring reports the same version before promote — so you never promote a SHA that INT already lost.

6. Secrets and AI agent continuity across rings

Per devops/SHOP-DEPLOY.md:

• Vault: workstation-shop/<env>/config → ESO → shop-secret-<ns>.
• CI runtime Secret shop-runtime-<ns> may supply ANTHROPIC_API_KEY, OPSAPI_ADMIN_API_KEY, FIRECRAWL_API_KEY.
• SHOP_BFF_KEY must match OpsAPI’s key for that env or the BFF is treated as anonymous.
• Prod uses an isolated vault token / SecretStore so rotating INT cannot touch PROD.

Promotion does not invent secrets — but a ring that is “healthy” while the agent is offline is a business-visible defect. Include agent liveness in the health definition you gate on.

7. CI integration shape

After the image is published and INT is seeded (or after the int workflow lands the SHA), promotion is fail-closed HTTP:

curl --fail -sS -X POST "$RP/api/apps/$APP/seed" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"ring\":\"int\",\"version\":\"$VERSION\"}"

curl --fail -sS -X POST "$RP/api/apps/$APP/promote" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"from_ring":"int"}'

Non-2xx fails the job. 422 means the operation ran, failed health, and rolled back — evidence is in Ring Promoter history / job steps, not only in GitHub Actions logs. Optional ?async=1 returns a job id for live step polling (lock → source health → deploy → target health → record).

8. Auto-promote policy we recommend for the shop

• ON for early rings when smoke + version health are strong (e.g. INT→TEST).
• HOLD on ACC so product can sign off AI basket behaviour.
• Never config-enable auto-promote into PROD — require production password / human promote.
• Rollbacks remain exempt from the prod password so incidents are not blocked.

Optional gates (maintenance windows, version-specific Go/No-Go, Jira CR, Grafana panels with max_age) run before deploy so a failed gate leaves every ring untouched.

9. Failure modes this design prevents

Failure	Without Ring Promoter	With protocol
Skipped staging	Hotfix workflow_dispatch to prod	Cannot skip rings by design
Green job, old chat	HTTP 200 from previous ReplicaSet	Version-verified health → rollback
Half-updated prod	CI timeout aborts mid-rollout	Detached op context + advisory lock
Secret skew INT vs PROD	Shared token blast radius	Isolated prod SecretStore + ring-scoped config
Unclear “what’s live?”	Slack archaeology	Orbit/Lanes + per-ring history

10. Operational checklist (shop release)

1. Confirm image wsw-shop:<sha7> published.
2. INT host healthy; agent completes a basket configuration turn; /api/health reports SHA.
3. Promote through TEST → ACC; re-run market sync observation if catalogue code changed.
4. Stakeholder sign-off on ACC (AI copy, quote terms, checkout/quote path).
5. Promote to PROD with production password; verify shop.workstation.co.uk SHA + TTFB.
6. Leave Orbit open during soak — blue should clear to healthy green on PROD.

11. Related reading

• Ring Promoter product · Compare vs Argo CD / Kargo / CI
• Every release earns production · Protocol deep dive
• QA gates before production
• Which tool answers which release question
• In-repo runbook: devops/SHOP-DEPLOY.md

Published by Workstation — GPU storefronts and agentic sales with a promotion control plane you can show in a release review.