The change that ships
Merging a pull request is easy to say and easy to gloss over. Here is what actually happens between that merge and a visitor seeing the change.
One word, two jobs, and a third case
What "deploy" actually means depends on what is running underneath it.
Publishing new files
On a static site, a deploy builds new files and publishes them to the edge network. There is no process to restart.
Replacing a running process
On a dedicated instance, a deploy starts a new copy of your app and retires the old one once the new copy answers correctly.
A change that carries a database migration
When a change alters the schema, the migration runs as its own step, ahead of the new code, so the app never queries a shape the database has not caught up to yet.
A deploy, hop by hop
7 steps, every time. Nothing is promoted until the one before it has passed.
- 1
Merge
Approving and merging the pull request is the trigger. Nothing ships before this.
You
- 2
Build starts
The pipeline picks up the merged code and starts a fresh build from it.
CustomHosted
- 3
Checks run
The same checks that gate every change on this platform run against this one — see the worked artifact below for the full list.
CustomHosted
- 4
Artifact produced
A successful build produces a real, deployable artifact — the built files, or a new image ready to run.
CustomHosted
- 5
Artifact published, or the process replaced
On a static site, the new files publish to the edge. On a dedicated instance, a new process starts alongside the old one.
CustomHosted
- 6
Health check
The new version has to answer correctly before it takes over traffic. Nothing is promoted on a guess.
CustomHosted
- 7
Old version retired
Only once the health check passes. Until then, the version already serving traffic keeps serving it.
CustomHosted
What it takes down, by hosting shape
The honest answer to "will my visitors see anything?" — confirmed by the health check above, not assumed.
- Static site
- None — there is no running process to restart.
- Dedicated instance
- A few seconds while the process restarts, confirmed by the health check above before the window closes.
- Managed database, minor version
- A brief connection blip during failover — existing connections reconnect on their own.
What survives a deploy
A deploy replaces code. It does not touch a file your app already wrote — Files owns the row-by-row detail below in full.
| Event | Survives? | Detail |
|---|---|---|
| A deploy | Yes | A deploy replaces the code that runs, not the disk underneath it. A file already written is still there once the new build starts. |
| A restart | Yes | The process comes back up; the disk it was writing to never went anywhere. |
| A resize | Yes | The disk moves with the instance during a scheduled move. See Scaling for the procedure, minute by minute. |
| A restore | Depends on the tier | Backed up alongside the database, same nightly schedule. See Recovery for the retention ladder, and the Extended backup retention (30-day) add-on for a longer window. |
| An exit | Yes | Ordinary files, not a proprietary export. Every file your app ever wrote, not just what shipped in the build. |
When the build fails
A failed build produces no artifact to publish. Production keeps serving the last good version — it has nothing else to switch to.
What fires A deploy that fails partway, or a build that doesn't complete First response The pipeline halts and the last known-good version keeps serving; a human is notified
| Tier | What counts | What happens first | Who hears, and when |
|---|---|---|---|
| Auto-handled | A known, safe failure with an established fix — a crashed process, a failed health check, a stuck deploy | Restart, retry, or redeploy the last known-good version, done automatically | No one, unless it recurs — it goes in the log, not a message to you |
| You hear from us | Something that touched the app and needs a person to pick the right response, not just a retry | A human looks at it and decides what to do — revert, restore, or a fix in code | You, in writing, on the same quote channel as everything else — business hours for anything that isn’t urgent |
| Outage handling | The site or a core function is down, or badly degraded, for real users | Worked ahead of the routine queue | You, as soon as there is something to say, with priority handling; out-of-hours response is best effort, not a staffed round-the-clock desk |
When it ships and the app is still wrong
A clean build is not the same as a correct change. Here is the way back.
Revert the merge
The same pipeline that shipped the change redeploys the last known-good version. No data touched, because none was.
Promote the previous deploy
On static hosting, the last deploy is already built and kept. Going back is a request through the usual channel, a straight promotion of it rather than a rebuild.
A data problem is a restore, not a rollback
If the thing that's wrong is data rather than code, that's the other procedure entirely — see Recovery for the backup and point-in-time paths, and where that boundary actually sits.
This site's own pipeline
Every row below is provable from this repository — see Built in the open and Case files for the real history behind it.
- 1
Build
This site is built fresh from source on every merge — nothing published is edited by hand after the fact.
- 2
Check gates
17 automated checks run against the build. Any one of them failing stops the deploy before it reaches the edge.
- 3
Publish to the edge
Once every check passes, the build publishes to the edge network — the same path described step by step above.
The 17 checks behind the "Check gates" stage above:
check:anchors
Every hub page's "On this page" index still matches its own numbered bands, in order.
check:a11y
Every route is crawled for accessibility faults, at two sizes, in both themes.
check:ledger
The public build-history page still matches what this repository's own history says.
check:llms
The machine-readable site directory lists every route exactly once, and every link actually resolves.
check:perf
Every route stays inside its own published page-weight budget.
check:security-txt
The security-contact file is present, and not expired.
check:supply-chain
The dependency-safety rules — locked versions, no install scripts, a release cooldown — are still in place.
check:seo
Every route carries one canonical URL, one title, one description, and valid structured data — and nothing meant to stay out of the index does.
check:forms
The form page's own field caps, its POST-only check, its honeypot field, and its log retention still match the real contact-form terraform.
check:images
Every image stays under its published weight ceiling, and every picture carries alt text, its dimensions, and a loading value.
check:limits
Every module that publishes a limits array is collected on /limits, and its published count matches what the page actually renders.
check:logins
No password input exists anywhere on the site, every form carries a known id with no off-site action, and /logins' own worked artifact still renders.
check:compliance
No affirmative compliance or certification claim appears anywhere on the site, and /your-data's residency and deletion bands still render.
check:spacing
No run-together word slipped past a stripped space next to a link or other inline element, on any route.
check:reveal
Every section that fades in on scroll actually appears, on a phone-sized screen as well as a desktop one.
check:twins
Every route's Markdown twin exists, starts with the page's real heading, carries no stray HTML, and is linked from the page exactly once.
check:quotes
No published quote bills an add-on its plan already includes, and the estimator prices only through the same code as the quote form.
Deploys are not a meter
The priced line is the change behind the deploy, not the deploy itself.
A deploy itself has no separate charge
Shipping a change is part of every plan, as often as you need it. There is no per-deploy fee and no cap on how many ship in a month.
The briefed change behind it is the priced line
An agent-opened pull request is what Agentic iteration — CodeHerder ($25/mo) prices — brief a change in plain words. an agent opens a pull request, a person reviews it, and the same pipeline ships it. See Billing for where that line sits on the invoice.
The honest limits
No canary, no blue-green, no second copy standing by. Said plainly, not buried.
No autoscaling
A flat rate means fixed, known capacity. Nothing on this platform grows itself in the background and bills you for it afterwards.
A dedicated release restarts — it does not swap
A single dedicated instance has no second copy standing by to take traffic while the new version starts. A release is a short, health-checked restart, not an instant handoff between two running copies.
No canary or partial rollout
A deploy ships to everyone at once, once it passes its health check. There is no percentage of traffic held back to watch first.
No build log handed over
You are told whether a build passed or failed, and what changed. Handing over the raw build output is not part of the standard note — ask through the quote channel if you need it for a specific change.
Deploy questions
What people ask once "we just deploy it" stops being a good enough answer.
01Is a deploy zero-downtime?
On a static site, yes — new files publish to the edge with no process to restart. On a dedicated instance, a release is a short, health-checked restart rather than an instant handoff between two running copies — see the honest limits above.
02What happens if the build fails?
A failed build produces no artifact to publish. The pipeline halts and the last known-good version keeps serving; a human is notified.
03The build passed, but the change is wrong. Now what?
That is not a deploy problem, it is a change to undo — see "When it ships and the app is still wrong" above for the paths back, and where a data problem stops being a rollback at all.
04Do you do blue-green deploys?
Not on a single dedicated instance — there is no second copy to run traffic through in parallel. A release there is a health-checked restart. A workload that genuinely needs two live copies is a Custom shape, sized and quoted for it.
05Can I see the build log?
You are told whether a build passed or failed and what changed, in the same note shape as any other change. The raw build output is not handed over by default — ask through the quote channel if a specific change needs it.
06Does merging to the default branch always deploy?
Yes. Merging is the trigger — see "A deploy, hop by hop" above for every step between that merge and the change serving traffic.
07What does a deploy cost?
Nothing extra by itself — shipping a change is part of every plan. The priced line is the briefed change behind it, under Agentic iteration — CodeHerder ($25/mo). See What it costs above.
08Does a database migration deploy differently?
A change that carries a schema migration runs that migration as its own step, ahead of the new code, so the app never queries a shape the database has not caught up to yet — see "What a deploy actually is" above.
What deploys connects to
- Logins
What this page's restart does to a session held in memory — everyone signed in gets signed out.
- What visitors see
What a visitor gets during the health-checked restart this page's "no seamless swap" limit describes.
- Environments
Where a change stands before it merges — the address, the data, and the steps that lead up to the merge this page starts from.
- Review
The pull request and the approval that come before the merge this page starts from — what you see, and how to review it without reading code.
- Checks
What the "checks run" hop above actually runs, whose checks they are, and what happens with no tests at all.
- The Loop
The commercial arc — who briefs a change, who opens the pull request, and why an agent in the loop makes it faster.
- Patching
The per-shape downtime answer this page's hosting-shape table reuses whole.
- Files
What a file keeps across a deploy, a restart, a resize, a restore, and an exit — reused whole in "What survives a deploy" above.
- Monitoring
The watch list and the escalation ladder behind "When the build fails" above.
- Scaling
The flat-rate, fixed-capacity limit this page's "no seamless swap" limit sits beside.
- Billing
Where the briefed-change line behind a deploy actually lands on the invoice.
- Built in the open
The real pull-request ledger behind the pipeline described in the worked artifact above.
- Case files
Three of those ledger rows, followed end to end, with the real diff stats behind each.
- Content
The most common kind of merge this pipeline ships — a word, a picture, or a new page.
- In flight
The "no cap on how many ship in a month" line above, and what actually sets how many changes are in the air.
Want to see what a deploy on your stack actually looks like?
Brief it through the same quote channel as any other request — see Billing for how the number is priced.