Takes a green branch to a running deployment, and keeps the DNS, the cluster and the access list honest on the way.
Built for: The small team where the person shipping the feature is also the person who owns the DNS record it needs.
The button opens the checkout, where the 6 servers and 5 skills are listed one by one. Every member is free, so the checkout lists them and asks for no card.
The reason to buy a stack rather than five listings: each line below needs more than one member connected at the same time.
Create and read deploys on Vercel or Netlify and say which commit is actually live.
Inspect the cluster — pods, deployments, services — and hold a release when something there is unhealthy.
Manage the DNS record a launch needs on Cloudflare, and read back what resolves rather than what was intended.
Walk a pre-launch checklist and produce the runbook and monitoring the launch will be judged by.
What each part contributes, and why it was picked over the obvious alternative. Prices and permissions are read from the listings, so nothing here can disagree with the catalogue.
Connects to the Vercel API, which is where a front-end release is either live or is not.
Netlify's own API and CLI for creating and managing sites and deploys, for the half of the estate that lives there.
The cluster check before and after a release: pods, deployments and services, inspected rather than assumed.
The DNS record a launch depends on, managed and read back from the zone that actually answers queries.
Ties the deploy to the commit and the merge request, so a release note is assembled from the repository rather than from memory.
The monitors that tell you whether the release was fine, read from the same desk that shipped it.
Sets up the pipeline and its quality gates, so 'it deploys from main' is written down rather than known by one person.
The pre-launch checklist — monitoring, rollback, the announcement — which is what separates a launch from a push.
Recertifies who can reach which resource and whether that access is used, which is the audit nobody schedules until it is demanded.
Pre-deployment checks for router and switch configuration — dangerous commands, subnet overlaps, stale references — for teams whose stack ends at the hardware.
A release is the last moment a known vulnerable dependency is cheap to fix, and this turns the audit output into the upgrade.
Every member is free, so the monthly figure is $0 whatever you do with the stack: nothing here is billed by the call, and only adding a paid member could change it.
| Part | What you are paying for | Monthly, as quoted |
|---|---|---|
| Vercel | Free | — |
| Netlify | Free | — |
| Kubernetes | Free | — |
| Cloudflare DNS | Free | — |
| GitLab | Free | — |
| Datadog | Free | — |
| Skills | ||
| CI/CD and Automation | Free · context cost only | — |
| Shipping and Launch | Free · context cost only | — |
| Teleport Access Review | Free · context cost only | — |
| Network Config Validation | Free · context cost only | — |
| Audit Dependencies | Free · context cost only | — |
| Everything above | $0 of servers plus $0 of skills, the same in a quiet month and a busy one | $0/mo |
Subscriptions at their monthly plan price; one-off licences spread over 12 months.
Install only these and the bill is nothing: 6 servers and 5 skills, and all 13 tools.
Nothing in this stack carries a call allowance, so nothing here can run out before the month does. The bill is decided when you install it, not when you use it.
The spend cap is one figure for the whole account, set in your dashboard and checked when an order is placed. On the call path what stops a retry loop is the plan's call allowance and its rate limit, and a refused call is never billed.
The steps below come before the install lines: what to decide and scope before connecting anything, in the order it matters. The lines themselves follow, part by part, for the client you pick.
npx mcprush@latest stack add release-infra writes all 6 servers into Claude Code’s config in one go — or run the lines below one by one. The 5 skills are not included — add them with lines 07–11.
CLOUDFLARE_API_TOKEN — Cloudflare API token with DNS edit rights (dash.cloudflare.com/profile/api-tokens)CLOUDFLARE_ZONE_ID — ID of the zone (domain) to manage, from the domain's Overview pageGITLAB_PERSONAL_ACCESS_TOKEN — GitLab personal access token for local stdio useDATADOG_API_KEY — Datadog API keyDATADOG_APP_KEY — Datadog application keySet them where you start Claude Code — export CLOUDFLARE_API_TOKEN=… in your shell profile on macOS and Linux, setx CLOUDFLARE_API_TOKEN "…" on Windows, then open a new terminal. Claude Code reads them at start; the config keeps only the names.
Vercel: Put your own value in place of <your-api-key> before you run this.
# 01 · Vercel
claude mcp add --scope user vercel-mcp '--' npx -y vercel-mcp 'VERCEL_API_KEY=<your-api-key>'
# 02 · Netlify
claude mcp add --scope user netlify-mcp '--' npx -y @netlify/mcp
# 03 · Kubernetes
claude mcp add --scope user kubernetes-mcp '--' npx -y mcp-server-kubernetes
# 04 · Cloudflare DNS
claude mcp add --scope user --env 'CLOUDFLARE_API_TOKEN=${CLOUDFLARE_API_TOKEN}' --env 'CLOUDFLARE_ZONE_ID=${CLOUDFLARE_ZONE_ID}' --transport stdio cloudflare-dns-mcp '--' npx -y @thelord/mcp-cloudflare
# 05 · GitLab
claude mcp add --scope user --env 'GITLAB_PERSONAL_ACCESS_TOKEN=${GITLAB_PERSONAL_ACCESS_TOKEN}' --transport stdio zereight-gitlab-mcp '--' npx -y @zereight/mcp-gitlab
# 06 · Datadog
claude mcp add --scope user --env 'DATADOG_API_KEY=${DATADOG_API_KEY}' --env 'DATADOG_APP_KEY=${DATADOG_APP_KEY}' --transport stdio datadog-mcp '--' npx -y @winor30/mcp-server-datadog
# 07 · CI/CD and Automation
npx mcprush@latest skill add addyosmani/ci-cd-and-automation
# 08 · Shipping and Launch
npx mcprush@latest skill add addyosmani/shipping-and-launch
# 09 · Teleport Access Review
npx mcprush@latest skill add gravitational/teleport-access-review
# 10 · Network Config Validation
npx mcprush@latest skill add agenticweb/network-config-validation
# 11 · Audit Dependencies
npx mcprush@latest skill add payloadcms/audit-dependenciesnpx).Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once, or type npx.cmd instead of npx (codex.cmd, gemini.cmd, grok.cmd likewise). PowerShell 7 needs neither.Nothing is connected until you approve it in Claude Code. mcprush is not in the path and meters nothing here.
Installed together, these tool surfaces add up. It is the first thing a security reviewer asks for, so what has been counted — and what nobody has counted yet — is on the page rather than in a PDF.
| Member | Tool surface | Write tools |
|---|---|---|
| Cloudflare DNS | imported | 3 |
| Vercel | imported | 2 |
| Datadog | not imported | not recorded |
| GitLab | not imported | not recorded |
| Kubernetes | not imported | not recorded |
A stack's blast radius is the union of its members, not the worst of them. That union cannot be taken here, because 3 members of 6 have no imported tool surface — so the figure a review asks for is missing rather than low, and a member marked not imported is one nobody has counted rather than one that cannot write.
A stack is a default, not a verdict. These are the substitutions the maintainer would make, and what each one costs or saves.
A service that is a container rather than a set of functions belongs on Railway, and the deploy conversation moves with it.
Teams whose workloads are managed services rather than pods get more from talking to the cloud account directly than from a cluster server.
Written by the maintainer, kept on the page rather than in a support thread.
It cannot approve its own release. Every member here can act, and the order in which they act is a human's plan.
The access review it does is Teleport's, not your cloud provider's. IAM roles are out of this stack's reach.
It has no opinion about cost. Nothing here reads a bill; a deploy that doubles your spend looks exactly like one that does not.
A stack has an owner: whoever keeps it re-checks the combination when a member changes, and the members themselves are published by the people named on each row.
Tools to inspect code changes, run checks and prepare a pull request review.
Tools to investigate alerts, check recent changes and follow the runbook.
Reviews the code, the identities and the exposure of one service, and writes down what it found rather than a score.