How I would run a fleet of client storefronts on my own CI

Most people who build small-business websites hand you a site and a login. What happens after that — the certificate that expires, the checkout that breaks on a phone, the change nobody can account for — is where the value actually is.

The infrastructure this site runs on was built to answer those, and it would extend to a fleet of client storefronts. Here is what exists, and what it would take. The honest boundary comes first: this runs a handful of my own surfaces today, not forty client stores. Nothing below is a claim about scale.

Adding a client is a generated file, not a hand edit

The web server loads per-customer routes from a directory that a provisioning script writes into. Onboarding a client means generating one config file, not editing a shared file that every other client also depends on. That matters because hand-edited shared config is how one client’s change takes down another client’s site.

Certificates issue themselves

New client hostnames get a certificate on first request, with a check that only recognised hostnames are allowed to ask. There is no wildcard certificate to rotate and no DNS credentials sitting in the deploy path. Client number forty needs no certificate work at all.

Every client gets a private preview

There is a single sign-in that can put any surface behind a login. In practice that means a client can look at their finished store, on a real URL, before it is public — without it being visible to anyone else, and without a separate staging stack to maintain.

Every change is a signed record

This is the part I have not seen offered at this price point. Deploys, config changes and fixes are written into the Forensic Fabric as signed entries, each attributable to whoever made it. For a store owner the practical version is: when your checkout broke on Tuesday, there is a record of exactly what changed and when, and it is not a record I could have quietly tidied up afterwards. You can check that property yourself — your own browser recomputes it, and you can try to tamper with an entry and watch verification fail at exactly the one you touched.

If you have ever argued with a supplier about whether something changed, you already know what that is worth.

Nightly proof that nothing broke on a phone

Deploys are verified by driving a real browser over each page at phone and desktop widths, asserting that the page does not scroll sideways and that the console is clean. Run across a fleet on a schedule, that is a standing check that no client’s storefront broke on mobile overnight — the failure that costs the most orders and gets noticed the last.

I am deliberately precise about this one: the tooling is real and I use it on every change to this site. Pointing it at a fleet is a scheduling job, not new software — but it is scheduled work I would be doing for the first time with your store, and I would rather say that than imply a track record I do not have.

Backups that ransomware cannot rewrite

Provisioning creates write-once storage, so a backup cannot be silently altered or deleted after the fact. A backup that an attacker who owns your server can also delete is not a backup, and that is the single most common gap I find.

What it would take

For one store: this is essentially in place. For a fleet, the missing pieces are scheduling the visual checks across many hostnames, and a per-client view of their own custody record rather than my operator view. Neither is research; both are work I have not done yet, and I would rather name them than let a diagram imply they are finished.