01Where the tax comes from
A hand-launched site carries a list of jobs that have little to do with the site: rent a server, harden it, point DNS, install certificates and renew them forever, write a pipeline, watch it, patch it when a notice arrives. That list is devops, and people build careers on it for good reason; servers are genuinely awkward. The list exists because a server exists. Remove the server and most of the list has nothing to attach to. The pillar page describes what remains: a repository, a deploy on push, a release history.
02Each job, and where it went
| Devops job | On a self-run server | On LoomWeb |
|---|---|---|
| Provisioning | Choose, rent and harden a machine | Signup provisions repository and hosting together |
| Web server config | Install and maintain nginx or similar | The serving layer is the product |
| Certificates | Certbot, renewals, expiry scares | Issued and renewed automatically |
| Deploy pipeline | Write and debug CI YAML | Push the tracked branch and it deploys |
| Bad-deploy recovery | Revert, rebuild, redeploy by hand | One-click rollback to any kept release |
| Patching | OS and runtime updates, forever | Static files have nothing to patch |
| Uptime watching | On you | On the host, by definition |
What remains on your side is content and judgement: what ships, and when.
03The devops that does not disappear
Honesty about the residue: somebody still reviews what the agent wrote before it goes live, still decides what the site should say, and still owns the account, the domain and the payment. Deploying without devops is not deploying without judgement. It is deploying where the judgement is about the site rather than about servers. If the part of shipping you genuinely enjoy is tuning infrastructure, a managed host takes that hobby away, and a VPS is the better buy. That is a real preference, not a lesser one, and the maintenance treadmill it signs you up for is covered in the WordPress escape guides for anyone coming from that direction.
04Who this fits
Three situations fit naturally. A solo builder whose agent writes the site and whose interest stops at the site. A small business that wants a live address without hiring anyone on call. An agency that would rather bill for pages than for server babysitting, which is what the Studio plan exists for. If the site needs a backend, or you need infrastructure you can SSH into and bend to your will, this is the wrong tool; static hosting would be a constraint rather than a relief. The mechanics of the deploy itself, for when you do ship, are in what happens after a push.
05Shipping without a devops hire
Is static hosting enough for a business site?
For a site of pages with a contact form, yes. For logins, carts or anything that computes on a server, no.
What do I do when something breaks?
Identify the release, restore the previous one in a click, then fix forward calmly. The site is never more than one restore from good.
Who patches the host itself?
We do. It is the service being paid for, and it is why the platform can stay boring.
Do I still need monitoring tools?
Not for the serving layer; watching it is the host's job. You will still want to look at your own site now and then, because no monitor knows what it ought to say.
Build it with your AI. Host it here.
Deploys on every push, from Australia, with nothing to maintain.