# The change that ships

> A deploy takes a merged change to live traffic. See each step, what it takes down by hosting shape, and what happens if a build fails.

Source: https://customhosted.com/deploys/

№ 01 Deploys

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.

№ 02 What a deploy is

## 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.

№ 03 Merge to live

## A deploy, hop by hop

7 steps, every time. Nothing is promoted until the one before it has passed.

1. 1 — Merge — Approving and merging the pull request is the trigger. Nothing ships before this. — You
2. 2 — Build starts — The pipeline picks up the merged code and starts a fresh build from it. — CustomHosted
3. 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. 4 — Artifact produced — A successful build produces a real, deployable artifact — the built files, or a new image ready to run. — CustomHosted
5. 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. 6 — Health check — The new version has to answer correctly before it takes over traffic. Nothing is promoted on a guess. — CustomHosted
7. 7 — Old version retired — Only once the health check passes. Until then, the version already serving traffic keeps serving it. — CustomHosted

№ 04 What it takes down

## 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.

№ 05 What survives

## 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. |

№ 06 The anxiety question

## 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 |

№ 07 The other failure

## 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.

№ 08 Worked artifact

## 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. 1 — Build — This site is built fresh from source on every merge — nothing published is edited by hand after the fact.
2. 2 — Check gates — 17 automated checks run against the build. Any one of them failing stops the deploy before it reaches the edge.
3. 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.

№ 09 What it costs

## 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.

№ 10 Said plainly

## 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.

№ 11 Answers

## Deploy questions

What people ask once "we just deploy it" stops being a good enough answer.

1. 01 Is 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.
2. 02 What 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.
3. 03 The 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.
4. 04 Do 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.
5. 05 Can 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.
6. 06 Does 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.
7. 07 What 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.
8. 08 Does 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.

№ 12 Keep reading

## What deploys connects to

- [Logins What this page's restart does to a session held in memory — everyone signed in gets signed out.](https://customhosted.com/logins)
- [What visitors see What a visitor gets during the health-checked restart this page's "no seamless swap" limit describes.](https://customhosted.com/what-visitors-see)
- [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.](https://customhosted.com/environments)
- [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.](https://customhosted.com/review)
- [Checks What the "checks run" hop above actually runs, whose checks they are, and what happens with no tests at all.](https://customhosted.com/checks)
- [The Loop The commercial arc — who briefs a change, who opens the pull request, and why an agent in the loop makes it faster.](https://customhosted.com/loop)
- [Patching The per-shape downtime answer this page's hosting-shape table reuses whole.](https://customhosted.com/patching)
- [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.](https://customhosted.com/files)
- [Monitoring The watch list and the escalation ladder behind "When the build fails" above.](https://customhosted.com/monitoring)
- [Scaling The flat-rate, fixed-capacity limit this page's "no seamless swap" limit sits beside.](https://customhosted.com/scaling)
- [Billing Where the briefed-change line behind a deploy actually lands on the invoice.](https://customhosted.com/billing)
- [Built in the open The real pull-request ledger behind the pipeline described in the worked artifact above.](https://customhosted.com/built-in-the-open)
- [Case files Three of those ledger rows, followed end to end, with the real diff stats behind each.](https://customhosted.com/case-files)
- [Content The most common kind of merge this pipeline ships — a word, a picture, or a new page.](https://customhosted.com/content)
- [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.](https://customhosted.com/in-flight)

## 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.

[Get a quote →](https://customhosted.com/contact)