01The model in one breath
Commit and push hosting means the repository is the deployment interface: whatever the tracked branch holds is what visitors get, and getting it there is the same push you make after any work session. The pillar page sets the scene; this page stays on the model itself, because once you see it, every feature below reads as a consequence rather than a product bullet.
FTP uploads, control-panel file managers and drag-and-drop deployers all publish by copying files. Git-based hosting publishes by declaring a state. The difference surfaces the first time something goes wrong, because a declared state has a history, and a history can be argued with.
02The life of a push
Commit
Your agent stages the change with a message a human can read. Future you relies on that message more than you expect.
Push
The branch updates on GitHub. For most sites the branch is main, and main is what the host deploys.
The host reacts
A webhook sees the push, the static build runs, and the output is validated before it can go anywhere.
A release is cut
The result becomes an immutable, numbered release. Live traffic moves to it. Older releases stay exactly where they were.
Regret, handled
If the release was a mistake, the portal serves an older one again. Your git history never has to lie to make the site right.
03What the model replaces
Nothing about your working habits changes, which is the disorienting part. You will look for the deploy step and find you already did it. What disappears is the parallel world most sites keep: a separate panel where the live version drifts from the repository until someone reconciles them by hand. Here there is one source of truth, and it is the repository, which is also why changing agents later is a lane change rather than a rebuild.
04Where the metaphor strains
Push-to-deploy is a great fit until the site stops being a set of files. Migrations, queues, user sessions: a push cannot carry those, and static hosting will not run them. The model also assumes someone still reads commits. An agent pushing forty commits a day, unreviewed, is not a workflow; it is a slot machine with extra steps. Keep a human in the loop somewhere, even if the loop is a glance at the diff before merge. The governance questions this raises get a fuller treatment in the agentic deployment explainer.
05Push-to-deploy questions
Does every branch deploy?
Only the one the host follows, main by default. Other branches are just branches until you merge them.
Can I push without deploying?
Push to a branch the host does not follow. The deploy is tied to the tracked branch, so experimental pushes stay private.
What counts as a release?
Each validated deploy gets a number, a date, and a place in the portal where you can restore it.
Is this the same as GitHub Pages?
Similar idea with the operational edges handled: certificates issued and renewed, a contact endpoint included, and rollback to any kept release.
What if the build fails?
The broken build never goes live. The previous release keeps serving while you read the error and push again.
Build it with your AI. Host it here.
Deploys on every push, from Australia, with nothing to maintain.