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 6 servers and 5 skills are listed one by one with what each does to the bill — free, already yours, monthly or a one-off licence. Nothing is charged until you confirm it there, in Stripe’s own card frame on that page rather than a redirect, and each paid member keeps its own budget cap.
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 a subscription or a licence bought once, so the monthly figure is a price rather than an estimate: what moves it is adding or dropping a member, not how hard the stack is worked. The one assumption is that a one-off licence is spread over a year so it can sit in the same column as a subscription.
| 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 | $49 · $4.08/mo over 12 months | $4.08/mo |
| Shipping and Launch | $35 · $2.92/mo over 12 months | $2.92/mo |
| Teleport Access Review | Free · context cost only | — |
| Network Config Validation | $15 · $1.25/mo over 12 months | $1.25/mo |
| Audit Dependencies | $69 · $5.75/mo over 12 months | $5.75/mo |
| Everything above | $0 of servers plus $14 of skills, the same in a quiet month and a busy one | $14/mo |
Subscriptions at their monthly plan price; one-off licences spread over 12 months. One-off purchases in this stack total $168 — CI/CD and Automation $49, Shipping and Launch $35, Network Config Validation $15, Audit Dependencies $69 — paid once and spread here so they sit in the same column as a subscription. Everything arrives on one mcprush invoice, taken by Stripe from the card on your account, not one per publisher — mcprush.com is the merchant of record and each publisher is paid out of it.
Install only these and the bill is nothing: 6 servers and 1 skill.
Left out, and what goes with it:
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.
Budget caps are set per install and enforced at the gateway, so a retry loop is refused at the cap rather than left to run through an allowance overnight.
One step per part, in the order they are useful: connect what the work reads before what it writes, and install the skills that decide how the work is done last. Each step is a command you can read before you run it.
npx mcprush@latest stack add release-infraNothing in this stack installs from one command today: 11 members are either paid, run from its own source, or a skill with its own command — the steps above name each one. Nothing is connected until you approve it.
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 | not imported | not recorded |
| Datadog | not imported | not recorded |
| Gitlab | not imported | not recorded |
| Kubernetes | not imported | not recorded |
| Netlify | not imported | not recorded |
| Vercel | 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 6 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.
Reads the branch, runs it in a throwaway sandbox, and leaves the review on the merge request before a human opens it.
Answers the page: what fired, what changed, what the runbook says, and what to tell the channel.
Reviews the code, the identities and the exposure of one service, and writes down what it found rather than a score.