Push to GitHub. The site deploys.

01Push to deploy, without the CI project

Publishing from a repository used to start with assembling a pipeline: a workflow file, a deploy key, a target server, all of it maintained alongside the site itself. LoomWeb is the pipeline. You connect your GitHub account once, through OAuth, with access scoped to the repositories you choose. From then on a push to your default branch is a release: the build is validated, the site goes live over HTTPS, and the previous version sits in history one click away.

There is no CI configuration in the repository and no server to patch, which is the entire appeal and also the honest boundary. If what you want is build choreography you can rewire, that is a different product, and the Actions comparison treats it fairly.

02The life of a push

1. Push received

   A webhook on your repository sees the commit land on the default branch. The pipeline is built in; the commit itself is the trigger.

2. Build validated

   The build output is inspected before anything is served: it has to come out as a plain static site, and one that fails never meets a visitor.

3. Release served

   The validated build goes live over HTTPS as an immutable release, recorded in the deployment history with its own number and date.

4. Rollback available

   If the change was wrong, the portal restores any earlier release in one click. Your git history is never touched by any of it; fixing forward stays a normal push.

03Every release is kept

That history is the part people underestimate until they need it. Each deploy is a numbered release with a date, and releases are kept rather than overwritten. A bad push stops being an outage with a diagnosis standing in front of it and becomes a menu of the last known-good versions. It also settles arguments: when someone asks what the site looked like before last week's redesign, the answer is a release number rather than an afternoon in git log.

Restoring happens in the portal and rewrites nothing. The site returns to the earlier version while you work out what happened, at whatever pace the day allows.

The history also changes how you hand the site around. A collaborator or an agent can be let near the repository without a safety net being built first, because the net already exists: whatever lands, the portal can put back. That is a different way of working from hosts where a mistake stays live until someone proves otherwise.

04Where GitHub Pages still wins

GitHub Pages is free, and for a large class of sites it is the right answer, full stop. A personal project, a documentation set, a portfolio updated twice a year: Pages publishes it from a push and charges nothing for it. If your repository is public, the site is a hobby, and you enjoy reading documentation when something misbehaves, stay there and close this tab.

This pillar exists for the pushes after that one. Private code that should not be searchable. Business sites where a broken deploy needs undoing in one click rather than a revert commit at midnight. Contact forms, Australian serving, and an inbox that answers. The honest comparison lives in the Pages alternative guide.

05What managed adds

The fair reading: Pages is excellent at the thing it was built for. This table lists what a managed host adds around it, and the docs on the GitHub side remain the source of truth about their platform.

06Private repositories and ownership

The repository is created in your GitHub account and stays there. LoomWeb receives scoped access to it, never your GitHub password, and the grant can be revoked from GitHub at any time, which is the quickest way to find out who holds the keys. Cancel the hosting and the repository survives with every commit; point a different host at it and the site moves with you.

Most sites here are built by an agent working in exactly that private repository, which is why private serving is the default rather than an upgrade. The private repository guide covers the access model in detail.

07Domains and certificates

Every site gets a yourname.loomweb.co address with HTTPS from the start. A custom domain attaches any time from the portal: add it, point your DNS records at it, and certificates are issued and then renewed automatically for as long as the site runs. Nobody writes a calendar reminder about certificate expiry, because there is nothing to remember.

The domain work splits the same way on every host: the DNS records belong to you and your registrar, and the serving side belongs to the host. The custom domain comparison walks through where managed hosting takes over.

08What it costs

Fourteen days free, and you are never charged at signup. After the trial the plan is $39 a month, and cancelling is self-serve from the portal at any time. Card details are captured on a hosted, tokenised payment page; LoomWeb never stores card numbers. Billing runs through BSimple (MrSoftware Pty Ltd), an Australian company. Pricing has the numbers and the fine print, which is short.

09Who should not use this

Static hosting only, and the boundary is firm. PHP does not run here, there is no database to connect to, and email mailboxes and shop platforms are out of scope. A contact-form endpoint is included, which covers the one dynamic thing most sites actually need. If the site computes, logs users in, or sells things server-side, it needs an application platform, and liking our price does not change that.

The agents this suits are all of them: Codex, Claude Code, Cursor, Copilot, Hermes, or your own hands. Anything that can write files and push can publish here. That neutrality is deliberate; a host tied to one AI vendor is a dependency you did not ask for. Every guide in this set stays inside the boundary above; doing static properly is the product, and pretending the walls sit farther out than they do is how hosting companies end up explained in forum threads.

10The guides in this set