Between the push and the visitor

01Why this page exists

Most deploy documentation is a happy path with the middle removed. Since the machinery runs on the pillar pipeline rather than on your machine, it is worth seeing once: what a push triggers, what can stop it, and what the portal shows at each stage. The model behind it is commit and push hosting; this page is the blow-by-blow version. Knowing the order matters on the one afternoon a deploy misbehaves, because then you can name the stage instead of guessing at it.

02The order it runs in

1. Webhook

   The push reaches GitHub, and GitHub tells LoomWeb. The push itself is the message; nothing polls and nothing waits for a schedule.

2. Fetch

   The host reads the branch it follows and takes the committed files, the same set a fresh clone would get.

3. Build

   If the site needs generating, that happens here. Plain HTML sites skip most of it.

4. Validation

   The output must be a clean static site before it can go live. A build that fails never reaches visitors; the old release keeps serving.

5. Release

   The output is published as a numbered, immutable release and traffic moves to it. HTTPS is already standing on the address.

6. History

   The release joins the timeline in the portal, beside every one before it, each restorable at any time.

03The two honest failure points

Nothing in the chain is magic, so it can fail in exactly two places. A build can fail, in which case nothing new goes live and the previous release keeps serving; the fix lives in your repository, and your agent is usually the fastest reader of the error. Or a successful build can contain something you did not want, which is not a pipeline failure but a review miss, and that is what rollback exists for: one click, the previous release returns, and nobody has to revert commits in a panic.

What does not fail is the middle. There is no staging server to misconfigure and no pipeline config drifting out of date, because the pipeline is maintained on our side as part of the service.

04What you will actually see

In practice, the portal ties each deploy to the commit that caused it, with a timestamp, so what went live and when is a record rather than a memory. From there the page is served from Australian infrastructure, so local visitors get short round trips. If the change touched the contact form, submit it once after the release; the endpoint is the only stateful thing on the site, and it deserves a click whenever a deploy goes near it.