Sovereignty is not a cupboard
Owning your data is about who can read it, change it, take it away and rule on it — not which room the hardware is in. Those are two independent axes, and only one of them needs the house.
Updated 28 August 2026 sovereigntyhostinghome-assistant
Data sovereignty is a question about control, not geography. Five things decide it: who can read what you keep, who can change it, who can take it away, whose courts settle the argument, and whether you could walk out with a copy tomorrow. Where the hardware physically sits is on none of that list.
It gets treated as though it were the whole question. Ask how to own your own data and the answer usually arrives as furniture: a tower in the spare room, a NAS under the stairs, an external drive on a shelf. Accounts, correspondence, photographs, a film collection, and — for anyone with a smart home — the record of when the doors unlocked, all pulled back indoors on the theory that proximity is ownership.
Proximity is not ownership. It is a different property that happens to be easy to see, and treating one as the other quietly costs you both.
What the word actually decides
| Question | What turns on it |
|---|---|
| Who can read it? | Accounts, correspondence, photographs, when the door unlocked. |
| Who can change it? | What runs, what gets deleted, who is let in. |
| Who can take it away? | A lapsed subscription, a discontinued product, a dead drive, a seized machine. |
| Whose courts apply? | Where the operator is established, and where the hardware is racked. |
| Can you walk out? | Whether an export exists that you can restore elsewhere, without asking. |
A cupboard answers a question that is not on that list — is it near me? — and then has to answer all five from scratch, using you. Theft, fire, a flood in the utility room, a drive that was never copied anywhere, a firmware update that bricks the box, a fortnight away with nobody home to power-cycle it. You are the night operator, the fire suppression and the off-site copy. Some people enjoy exactly that, and it is a fine hobby. It is an operations posture, not a sovereignty posture, and the two get sold as one thing.
The vendor cloud fails from the other end. Someone competent does the operations, and in exchange they hold the keys. Terms change. Products get discontinued. A "works with" badge lasts until the next range review. When their bad day arrives, your photographs stop loading and your lights stop answering, and there is no export that would let you carry on elsewhere.
Two axes, not one
You do not keep the bank's ledger under the stairs in order to own your money. You care that the institution is somewhere your law reaches, that the record is yours to export, and that nobody can quietly rewrite it. The ledger lives in a building designed for ledgers, and none of your ownership depends on that building being yours.
| Vendor cloud | The cupboard | Dedicated host | |
|---|---|---|---|
| Who runs the hardware | Them | You, at 2am | A facility, on shift |
| Who holds the keys | Them | You | You |
| Off-site copy | Theirs, not yours | Whatever you remember to do | Part of the arrangement |
| If you want out | Screenshots | Already have it | An export, restored elsewhere |
| Costs you | Terms you do not set | Evenings | Money |
Leaving is the test
This is the test worth applying to us as much as to anyone else. A hosted machine running standard open-source software, whose backups you can download and restore onto hardware you bought yourself, is a sovereignty posture. A hosted machine running something only that provider can read is the vendor cloud with better marketing.
The library was a bandwidth argument
Keeping a media library at home was the right answer to a real problem, and the problem has largely gone away. Photographs, films and recordings went under the stairs because the line out of the house could not carry them. Most households are now on hundreds of megabits, and plenty are past a gigabit.
So compare the copies honestly. A drive on a shelf, or a NAS you keep alive yourself, against a disk in a facility with redundant power, a second copy somewhere else and somebody whose job is noticing that a disk has died. The one in the cupboard is not the safer copy. It is the nearer one, unpowered for the fortnight you are away, with no second site.
What genuinely cannot leave the house
Radio. That is the whole list.
Zigbee, Z-Wave, Thread and Bluetooth Low Energy are short-range by design. No connection, however fast, lets a machine in a datacentre hear a bulb in a kitchen. So a house with smart devices keeps a small always-on box with the radios in it, and everything upstream of that box can be anywhere.
One detail decides whether that arrangement works at all. Discovery, Matter and Thread assume the controlling machine is on the same network segment as the devices, so a routed tunnel between "the cloud" and "the house" is two places with a road between them, and the broadcasts never arrive. Extend the home network itself and the hosted machine is genuinely on the LAN: same broadcasts, same IPv6, same bulbs. The radios themselves are drawn out in how Thread and Matter actually work.
What we changed our minds about
We had "local first" muddled up with "the computer lives in the house." After moving an established Home Assistant out of a house and onto hosted hardware — while the house carried on heating itself — the line landed somewhere else: what has to be local is the LAN and the radios, and once the machine is on that LAN its postcode is an operations question. The library went the same way. We had been keeping media at home because that is where the bandwidth used to run out, and it stopped running out some years ago.
The honest trade is still a trade, and it runs both ways. You are trusting a facility and an operator, and a dedicated physical machine in your own house is stronger isolation than sharing a hypervisor — we say so in how your server is kept apart rather than implying otherwise. If the line into the house dies, a hosted brain cannot reach the bulbs until it comes back, which is why a small local fallback earns its place. A cupboard with no off-site copy fails the other way round, on the day the house itself is the incident.
Sovereignty is a spectrum, and the cupboard is one end of it. It is not the definition.
Where it landed
That is the general argument. VomeHome is the same argument built for one piece of software rather than as a generic VPS.
You get your own virtual machine running Home Assistant OS — Supervisor, add-ons, HACS, the same software the enthusiasts already run. It is not a shared instance with your automations in someone else's process. You administer it the way you would administer a box at home. You do not administer the hypervisor, and we do not pretend otherwise.
The hardware sits in a datacentre in the EEA. The operator is a Swedish sole trader, and the privacy page is where that claim is made properly. The house keeps the radios and a small always-on box. An encrypted tunnel carries the home network to the machine, dialled out from the house.
If you already run Home Assistant, the route in is the one described in out of the house first: a backup, a pre-flight, a rollback point, and a report of what came across. The same backup is the route out again, which is the point of the section above.
Fancy trying it?
VomeHome hosts Home Assistant properly: your own instance, in a datacentre, connected to the devices in your house over an encrypted tunnel. The radios stay where the physics is. Everything else sits where the power, the cooling and the second copy are.
Take a look at VomeHome — it is open to testers, and we would rather hear what breaks than be told it is fine.