01The key facts
The repository stays in your account. Private, portable, and untouched by cancelling hosting.
Access is scoped OAuth. LoomWeb receives access to the repositories you connect, never a password, and GitHub lets you revoke the grant at any moment.
Private changes nothing about deploys. Same push, same validated build, same live site.
It is the default, not an upgrade. Most sites here are agent-built, and agents work in private repositories. The pillar page has the context.
02Why public repos feel wrong for client work
A public repository publishes more than a website. Drafts, half-built experiments, internal notes in commit messages, a pricing page that briefly said something you had not announced yet: public by default is a strange requirement for production work, and most people only notice after the fact.
On the Pages side of the world, serving a private repository requires a paid GitHub plan, which is a fair way for GitHub to charge and a real cost to weigh (the alternative guide does that weighing). Here, private is simply how repositories are. Your agent keeps working exactly as it does now, in the same repo it already uses; the Codex guide shows that loop, and every other agent works the same way.
03What LoomWeb receives, and what it never sees
Receives: scoped repository access
Read and deploy access to the repositories you connect at signup. GitHub shows you the exact grant when you approve it.
Never receives: your GitHub password
Sign-in is OAuth through GitHub. Credentials stay with GitHub; what we hold is a scoped token you can revoke whenever you like.
Never receives: raw card numbers
Card capture happens on the payment provider's own page, and LoomWeb never holds the numbers. Billing sits with BSimple (MrSoftware Pty Ltd).
Receives: your pushes
Commits to the connected default branch, which is the whole feed. Nothing else in the account is watched.
04Revoking, leaving, staying
The honest test of any access claim is whether revoking hurts. Remove the grant from your GitHub settings and the pipeline stops watching for pushes; the repository, the commits and the history were never anywhere but your account. Cancel the hosting and the same is true, with the live site standing down when you say so rather than on a notice period.
One limit worth naming while we are being tested: the host can read what it serves. The grant is scoped and the card vault stays closed, but access to the connected repositories is real, and if source code must stay unread even by your host, a managed pipeline of this kind is the wrong shape and self-hosting is the honest answer.
Staying and leaving are both ordinary operations here, which is the point. Ownership that only works while you keep paying was never ownership.
05Access and ownership questions
Does a private repository change what visitors get?
No. Visitors receive the built site over HTTPS; privacy applies to the source, not the output.
Does private cost extra?
No. Private repositories are the normal case on every plan, including the trial.
Who can trigger a deploy?
Whoever can push to the repository, which keeps access control where it belongs: in GitHub, with your collaborators managed as usual.
Can the repository go public later?
Certainly. The pipeline does not care either way; flip it in GitHub settings and carry on.
Build it with your AI. Host it here.
Deploys on every push, from Australia, with nothing to maintain.