Coming soon
The service has not launched. What follows is the shape of the project and one engineering question already worked through. As the build progresses, each decision — and each thing that goes wrong — will be written up in Fieldnote and published to this hub, so the record grows with the work rather than being reconstructed after it.
The project
What it is
A managed VPS offering built on one principle: the automation is the operations team. Every routine task — provisioning, hardening, patching, backup, health scoring, consent-gated remediation — is handled by an agent layer, so that human attention is spent on exceptions rather than on toil. Linux only, starting narrow on Ubuntu LTS.
The commercial detail lives elsewhere. What belongs on a working record is the engineering discipline behind it, and the honest answers it forces.
A worked example
How much can a Pi cluster actually host?
An early capacity question: as a substrate, how many sites could a 20-node Raspberry Pi 5 cluster serve? The instinct is to count cores. The honest answer starts by refusing to.
For isolated VPS, RAM is the binding constraint — it cannot be oversubscribed the way shared hosting oversubscribes it. Twenty 16 GB nodes hold 320 GB raw; after host overhead and a reserve to survive two dead nodes, roughly 260 GB is sellable. Divided into small instances, that is on the order of 120–150 managed instances — not the thousands a core-count guess suggests, and not the handful a naive one-VPS-per-node layout would give.
Where the claim would have drifted
A tempting mistake is to advertise the premium tiers on this hardware. A Pi 5 has four cores and no ECC RAM, one power input and one network port. A tier specified at eight vCPU per instance does not fit a four-core node at all, and a machine with no internal redundancy cannot honestly carry a premium uptime guarantee. The Pi cluster is right for an entry tier and for development and staging — not for the top of the range.
That is the pattern the whole project is built to enforce: a price, an SLA, and a capacity claim must each be backed by something that can be measured, not by something that sounds right.
Principles
The rules the build holds to
- Capacity-backed pricing. Every tier maps to real, measured headroom, with a redundancy reserve held back.
- Consent-gated automation. Low-risk fixes run automatically when opted in; anything high-risk waits for a human.
- Honest SLAs. A guarantee is only advertised once the substrate and the staffing can actually keep it.
- Automation density as the margin. Every manual operations hour is a cost; the agent layer exists to remove it.
What lands here next
The build log, as it happens
This page will be followed by entries covering the real work: the provisioning agent, the hardening baseline, the backup and monitoring stack, the first live nodes, and — deliberately — the mistakes and dead ends along the way. Each will be written in Fieldnote and published straight to this hub. Check back, or watch this space grow.
