--- title: "The same OS in the cloud: KyberLinux as a KyberFusion node" url: "https://kyberlinux.com/blog/kyberlinux-as-a-fusion-node" description: "Work that leaves your device usually lands on a system you cannot see. A KyberFusion node runs the same KyberLinux you carry, so the rules travel with the job." --- # The same OS in the cloud: KyberLinux as a KyberFusion node October 8, 2026·4 min read·Editorial team Two identical install keys, one plugged into a server sled and one into a pocket deck lying in front of it Your assistant has a year of voice notes to transcribe and index. The card on your lanyard cannot do it, and the node on your shelf would take a week. So the job goes to the cloud, and from that moment you are trusting things you have never seen: an operating system image chosen by the provider, a hypervisor, the staff who can reach both, a logging pipeline that keeps who knows what for who knows how long, and an account that ties every job to your name. ## The real cause In a conventional cloud the trust boundary is the provider’s whole stack. You do not trust the machine your job runs on because you can check it; you trust it because a contract says you may. That is a reasonable arrangement for a company renting servers. It is the wrong one for an assistant that carries the most personal record you have. ## What goes wrong when work leaves your device **A different system at the other end.** The rules that held on your device, what an agent may read, which hosts it may reach, what gets logged, do not travel with the job. It lands somewhere with its own rules, and you do not know what they are. **The operator can see in.** Whoever runs the machine can usually inspect memory, attach a debugger or read the disk. Whether they do is a question of policy, not of technology. **Logs kept by default.** Requests, payloads and errors end up in logs designed for the provider’s convenience and retained on the provider’s schedule. **Identity attached to every job.** Billing needs an account, and the account is you. Every job you send is linked to every other one. **Trust by contract, not by check.** Nothing in the exchange lets you verify what actually ran. You are told, and you believe it. ## A node that runs what you run [KyberFusion](https://kyberfusion.com/blog/what-a-node-knows-about-you) is built differently, and the operating system is a large part of why. Every KyberFusion node is designed to run the same [KyberLinux](https://kyberlinux.com/) image you carry on a KyberDeck, with a cloud profile in place of a desktop. That gives the network three properties a rented server does not have. **The rules travel with the job.** An agent that left your device in a KyberCell arrives in a KyberCell: the same declaration, the same closed network, the same per-program rules, the same trajectory log. Moving the job changes where it runs, not what it may do. KyberAgent covers [where a swarm should run](https://kyberagent.com/blog/where-a-swarm-should-run); the system is what makes either answer safe. **The image can be checked.** A node boots a signed image whose definition is public and whose build is meant to be reproducible. The design goal is that a node proves which image it booted before it is given any work, so a modified system is refused rather than trusted. **The operator stays outside the cell.** Members of the network contribute hardware and energy, and the person whose machine hosts a node runs the image but does not get a shell inside its cells. Jobs arrive encrypted and unlinked from you. Anonymity is the goal the system is built for, not a promise we make today. Members are paid for that capacity in tokens. A token is a unit of settlement for compute in a network governed as a DAO, and the income behind it keeps the infrastructure running and funds development; it is not an investment return, and holders are promised nothing. This is not an offer. How the network pays for itself without selling data is covered in [who pays for the cloud](https://kyberfusion.com/blog/who-pays-for-the-cloud). ## The honest limits Running the same system does not make other people’s hardware yours. Someone with physical access and enough determination can attack a machine below the operating system, and proof of the booted image is only as strong as the hardware root it rests on. Where the hardware can encrypt the memory of running jobs, the system is designed to use it; where it cannot, the node should say so, and sensitive work should stay on your own devices. Anonymity is hard, and we do not claim it. It is a design goal that shapes what the system logs, what it links and what it forgets, and it will be worth exactly what can be checked once the network exists. Today it does not: KyberFusion and KyberLinux are both pre-launch. ## A test you can run today Pick the cloud service your assistant uses now and try to answer five questions in writing, with two columns: what you can verify, and what you are told. 1. Which operating system image runs my job, and can I see its definition? 2. Can I check, before my job runs, that the machine booted that image? 3. Who can read the memory of my job while it runs? 4. What is logged about my request, and for how long? 5. Is each job linked to my account, and to every other job I have sent? Count the answers in the “verified” column. For most services today it is zero, which is not a scandal but a design: they were built to be trusted, not checked. The ground under your assistant should be the other kind. - KyberFusion - cloud - attestation - privacy ## Keep reading - [How KyberLinux keeps a swarm in its cells](https://kyberlinux.com/blog/how-kyberlinux-keeps-a-swarm-in-cells) - [Why a system for SI should be keyboard-first and opinionated](https://kyberlinux.com/blog/keyboard-first-and-opinionated)