01The key facts
The push is the deploy. Commit to the default branch and the hosting pipeline takes over; there is no second command and no dashboard visit.
Every push becomes a release. Versioned, dated, kept, and one click away from being restored.
Validation gates the live site. The build must come out as a clean static site before visitors see it.
Any agent can drive it. Codex, Claude Code, Cursor, Copilot, Hermes: if it can push to GitHub, it can publish. The pillar page has the wider map.
02A push, from commit to live site
You commit
The change lands on the default branch, typed by you or by your agent. Publishing is not a separate chore to remember afterwards; the commit is the chore.
The webhook notices
A webhook on the repository fires as the push arrives. There is no polling loop and no scheduled job in between; the push is the only trigger, and nobody visits a console to press it.
The build is validated
The static build runs and its output is checked before it can be served. A build that does not come out as a clean static site is stopped at the door, and the live site keeps running untouched.
The release goes live
The validated build becomes the public site over HTTPS and joins the history as a numbered release with its date.
Undo exists
A push that turns out wrong is one click from being replaced by the previous release, while you read the diff in your own time.
03What the webhook sees
Only the default branch. Pushes to any other branch are ignored by the pipeline, which is not a limitation but the basis of every sane workflow: experiments live on branches precisely because nothing there can reach visitors. Open pull requests deploy nothing either, because a pull request is a proposal, and proposals do not go live until merged.
That single rule does most of the work people expect from a staging environment. The preview and production guide shows the pattern, and deploying the main branch covers the default-branch rule in detail.
04Two wrong pushes, two recoveries
The push that broke something
It went live because it was merged or pushed to the default branch, so put the site back first and diagnose second: rollback in the portal restores the previous release while you read what happened. After the fix, a normal push deploys like any other. Nothing in your git history was rewritten to get there.
The push you are unsure about
Then it does not belong on the default branch yet. Push it to a branch, run the site locally, sleep on it, merge tomorrow. The pipeline ignoring branches is the feature doing its job.
05Answers to the usual mechanics
How long does a deploy take?
A static build is a small job, and the swap to the new release happens as soon as one validates. We will not quote a stopwatch figure we have not measured against your repository, but there is no CI queue to wait behind.
Do I need a config file in the repository?
No. The pipeline is the product, which means the repository holds the site and nothing that exists to serve it.
What if my agent pushes something broken?
Two gates: validation stops a build that is not a clean static site, and rollback covers a build that validates but misbehaves. Between them, broken is temporary.
Can a deploy be scheduled instead?
The trigger is the push, not a clock. If something should change weekly, change it weekly; the deploy follows the commit rather than a calendar.
Build it with your AI. Host it here.
Deploys on every push, from Australia, with nothing to maintain.