How a cloud is written
Written as files, checked as a whole.
A cloud is written the way one machine is: in plain text files, in one language, checked before anything boots. Nothing manages it afterwards. There is no discovery, no orchestrator and no program that decides what runs where, and this page says what stands in their place and what is left out on purpose.
What you write
Three kinds of file, in one language.
A machine file
Says what one machine is and what each program on it may use: the network, which disks, which user, how much memory. harb check reads it against the language's rules and refuses what breaks one, naming the line.
A fleet file
Names the machines of one estate, each with the public key it is enrolled by, the networks it sits on (the fleet file calls a network a link), and which machine is the way between two of them. It is judged as a whole, because some mistakes belong to no single machine: two machines that each serve the same network are each faultless, and together a broken network.
A pack
A solution's server programs on their own, written apart from any machine: what each one needs to run. harb place puts a pack on a machine, and the machine's own checks judge the result as one machine. A pack that asks for what the machine does not grant is refused at the pack's own line, before any image is built.
An ordinary cloud has a control plane: a service that decides what runs where and watches that it keeps running. Here that job is done by the files in git and by each machine's own check of its own boot. There is nothing to install, nothing to keep alive, and nothing that holds a second copy of who is in the set and could disagree with the file. The part of harb that checks the files is called the court, and it refuses a mistake while the cloud is still text.
What matters in a set of machines is the list of states it must never be in. Here each one is a refusal the court can make before anything boots.
Left out on purpose
What most clouds have, and this one does not.
No discovery, no autoscaling
The fleet file is the list of who is in the set. A program that discovered the set would be a second source of truth about it, and one that added machines by itself would be deciding what the file should say. Capacity is declared: adding a machine is one line in the file and one image.
No automatic enrolment
A machine joins when a person copies its public key into the fleet file. An automatic enrolment would have to trust whatever answered on the wire, and the key is the one thing that says whose a signed record is.
No hypervisor in the product
A hypervisor cuts one computer into several virtual ones. Here, more programs on one machine is density, more machines is isolation between owners, and a provider's virtual machine is simply the hardware. The emulator used on these pages is the court's instrument for trying a machine on a laptop, and is not part of what ships.
Whose cloud
What you keep when somebody else owns the hardware.
The same files describe a cloud on hardware you own and, once the fourth step is built, on a machine you rent. What changes between them is who holds the keys. Each machine makes its own key the first time it boots, and whoever holds the hardware holds that key.
So on a machine somebody else owns you keep two things: the declaration, which is the file, and the evidence, because every machine's record is signed and anyone holding the fleet's public keys can check it, holding no secret. You do not keep the hardware. Run the same files on hardware of your own and you do; it is the same act.
The honest promise is your declaration and your evidence, never “your cloud”.
Next: Where the cloud stands → The six steps, which are built and which are not, and what judges each.