Engineering
Deployment Pipeline: releases that cannot skip their checks
The Deployment Pipeline is one command that ships your site or app only after 30+ automatic checks pass, with a rehearsed one-command roll-back. A one-off £999, with no monthly fee. Ready in 7 working days.
Why do website updates keep breaking things?
Most small businesses ship a change by having someone make it and press publish. That works until the day a small edit takes the checkout down, and nobody finds out until a customer says so.
The usual fix is a promise to be more careful. That holds for about a fortnight. Then there is a deadline, the checks get skipped, and the same thing happens again.
The fix that lasts is to make the checks the only way out. If the release cannot happen without them, nobody has to remember them.
How is this different from uploading by hand or auto-publish?
Uploading by hand checks whatever you remember, and a host's auto-publish runs a build and sometimes tests. The Deployment Pipeline runs 30+ checks in order, stops and names the one that failed, and rolls back with one rehearsed command.
| Upload by hand | Your host's auto-publish | Deployment Pipeline | |
|---|---|---|---|
| How it ships | Copy files or press publish | On every save | One command |
| Checks first | Whatever you remember | A build, sometimes tests | 30+ checks, in order |
| When one fails | A customer tells you | It stops, often vaguely | It stops and names the check |
| Going back | Hope you kept a copy | Usually a click | One command, rehearsed |
| Who knows how | Whoever did it last | The platform settings | One written page |
What do you get with a deployment pipeline?
The Deployment Pipeline gives you one command to ship, 30+ checks from leaked keys to payment rules, ratchets that never let a number slide back, a health check after release, a rehearsed roll-back and the process on one page.
- 01
One command
One way to ship your site or app, the same every time, whoever runs it.
- 02
30+ checks
Leaked passwords and keys, broken links, page and image size, code errors, payment rules - all before anything goes live.
- 03
Ratchets
Checks that let a bad number fall but never rise, so the code gets better a little each release and never slides back.
- 04
Stop and say why
The first failed check stops the release and names itself, so the fix starts in seconds.
- 05
Health check after
Once live, the pipeline checks the real site - can someone still sign in - and tells you if not.
- 06
Easy roll-back
One command puts the last good version back. We rehearse it before handover.
- 07
The process, written
One page that says how a release works, what each check is for, and what to do when one fails.
What does a release look like when a check fails?
A Deployment Pipeline release runs every check in order and prints each result. The first failure stops the release and says why, with the roll-back ready. Here is what the output looks like.
npm run deploy -- site
- ok secrets scan
- ok broken links
- ok type errors: 0 (held)
- ok image sizes
- ok page weight
- ok payment rules
- ok database rebuild matches live
- FAIL page weight grew - release stopped
- roll-back: one command, ready
- 36named checks across the GigXchange releases
- 82check scripts in the GigXchange code
- 751 to 0website code errors, held at zero since July
Source GigXchange's own figures, as of 25 October 2026
How long does it take to set up a deployment pipeline?
The Deployment Pipeline takes seven working days: two to survey how you ship today, three to wire the command and checks, one to make each check fail on purpose, and day seven for your first real release with me watching.
- 01
Days 1-2
Survey
We read how you ship today and list what has gone wrong before.
- 02
Days 3-5
Wire
The one command built, the checks chosen and set to today's baseline.
- 03
Day 6
Prove
Each check made to fail on purpose, so we know it catches what it claims. Roll-back rehearsed.
- 04
Day 7
Hand over
You or your developer run the first real release with me watching. The process page is yours.
Does your business need a deployment pipeline?
The Deployment Pipeline suits a site or app that changes at least once a month, where a release has broken something before. It is the wrong buy if your site lives in Wix or Squarespace, or you do not have its code.
A good fit if
- Your site or app changes at least once a month
- A release has broken something before
- More than one person, or an AI coding tool, ships code
Not for you if
- Your site lives in a builder like Wix or Squarespace
- Nothing changes for months at a time
- You do not have the code for your site
Questions
07Asked and answered
A deployment pipeline is the fixed route every change takes from someone's laptop to your live site, with automatic checks on the way. Instead of pressing publish and hoping, one command runs the checks in order and only ships if they all pass. If one fails, nothing goes live and you are told which check failed and why. On GigXchange, 36 named checks run across the releases.
Usually 30 or more, chosen for your site: leaked passwords and keys, broken links, page and image size, code errors, payment rules and, if you have a database, whether its rebuild file still matches live. Some are ratchets - the number of known problems may fall, never rise. If you have no database rules yet, a Database Security Audit adds them.
You can skip the checks in a real emergency, and the pipeline says so loudly every time. That route exists for a roll-back or a one-line hotfix, not for a deadline. In practice the stop is rarely the problem: the check names itself, so the fix is usually minutes. The one thing it will not do is quietly let a bad release through.
One command puts the previous version back live, usually in under a minute. On Cloudflare that uses the host's own roll-back feature, wired into the same command as the release. We rehearse a roll-back before handover, so the first time you use it is not the day you need it. A roll-back puts back the site, not your data, so database changes are planned to work with both versions.
Yes if your site or app is code you hold, hosted on Cloudflare, which is where I build first. Other hosts that publish from code usually work too; I check in the survey on day one and tell you before you pay for the build. It does not work for sites inside a builder like Wix or Squarespace, because there is no code to check.
Yes - the checks do not care who wrote the change. An AI tool that leaves a broken link, a leaked key or a code error is stopped at the same gate as a person. That matters more each month as more code gets written by AI. If you want AI agents doing routine work while you sleep, Autonomous Agent Operations adds a safety lock and a morning report.
No - the pipeline is a one-off £999 and runs on your own accounts after handover. There is no subscription and nothing to renew with me. If you add a new kind of check later, or move host, that is a small fixed-price job. The checks cost little or nothing to run, because they run on the machine doing the release.
For most small businesses, yes. Release safety is a big part of what a dev-ops engineer does, and most small firms need the system, not a full-time person to watch it. The pipeline is a one-off £999 and then runs itself. What it cannot do is design new systems or fix the code a check catches - that is still your developer, or me.