PandoCloud runs websites and code on machines that people in your own community already own — an old laptop in a closet, a desktop in the back of a shop. The work happens nearby, the money stays nearby, and the machine serving this page has an address you could drive to.
PilotClosed cohortNo SLAThis page is the workload
Two things we would rather put at the top than the bottom. The sandbox around a workload protects the operator's machine from that workload; it does not protect the workload from the operator. And encryption here covers data at rest only. That is exactly why PandoCloud carries no personal data — including none of yours, on this page.
Every cloud has a physical location. The difference is whether anyone who benefits from it lives there.
Hosting is one of the few recurring business expenses that leaves a local economy completely and returns nothing to it. The monthly bill is a wire transfer out of the county. On PandoCloud the same bill pays the person whose machine did the work — someone who lives where you live and spends where you spend. Pando Labs keeps a published 15% and nothing else, and that number is one of the first things community governance gets to vote on.
A community that owns no compute rents all of it. That is a durable dependency: price, terms, and whether the service exists next year are all decided elsewhere, by people who will never meet you. Owning the machines is the version of internet sovereignty that doesn't require anybody's permission — and it turns out you can start with the hardware already in the building.
Hyperscale concentrates electricity and water demand into single enormous sites, and those sites sit in real places, on real grids, above real aquifers. Spreading the same work across machines that are already plugged in and mostly idle doesn't add a building, a substation, or a cooling loop.
Being precise about that, because the obvious rebuttal is correct: per unit of compute, a hyperscale hall wrings more work from a watt than a laptop in a closet ever will. Efficiency is their argument and they win it. This is a different one — that the work here runs on machines already built, already shipped, and already plugged in, so it adds no building, no substation, and no cooling loop to anyone's grid or aquifer; and that the electricity it does use is paid for honestly, where it is used. The price floor for compute is set at twice its measured energy cost, so no operator is quietly paid less than their power bill.
You point a domain at PandoCloud and your site is built into a standard OCI image. From there, three rules decide where it runs — two of them the opposite of what a normal scheduler does — and one more decides how.
A request for capacity is filtered first to machines inside your city's boundary. If none of them can do the job, the search widens to your watershed — the drainage basin you actually share with your neighbours, which is a truer unit of nearby than a metro area or a state line. If still none, the filter drops to latency and the nearest capable machine wins wherever it is.
Schedulers normally reach for the strongest available machine. We deliberately route the other way. If your site needs one core and half a gigabyte of memory, handing it the fastest machine on the network wastes that machine — it should stay free for work that genuinely needs it. So the smallest qualifying machine wins. Ordinary hardware gets ordinary work by design rather than by charity, and there is no weak tier for it to be demoted into.
Among the machines that qualify, one is drawn. Better machines hold more tickets: a higher reliability score means better odds, never a guarantee. The obvious alternative — always pick the best — quietly hands every assignment and every dollar to the one well-connected machine in each community, forever. A weighted draw spreads both across the people who actually showed up.
The draw isn't really random. Every machine on the network derives the same winner from the same published seed, so nobody has to be trusted to run the lottery — and anyone can check afterwards that the draw was the draw.
Workloads execute under gVisor, or inside a Firecracker microVM where the hardware supports it. Plain containers are never used. The floor is the same for every machine on the network, which is what makes it reasonable to run a stranger's code on your own computer — and it is also the boundary whose limits we describe below.
This is the part most easily mistaken for a charitable gesture. It isn't one — it's the architecture. If ordinary machines could only get the work nobody else wanted, the whole premise would collapse into a hobby.
A ten-year-old x86 laptop running Linux is close to ideal. It has hardware virtualization built in, needs no permission from a manufacturer to repurpose, draws a fraction of what a server does, and its battery is a built-in uninterruptible power supply. An Apple Silicon MacBook is also a full participant: it can't nest virtualization, so it runs the gVisor floor — and since that floor is where most work runs anyway, that is not a demotion.
Before you commit a machine, we will tell you roughly what it is likely to earn against what it costs to run. An operator quietly losing money on electricity is worse for this project than an operator who never joined.
At a residential rate of 16.54¢/kWh and roughly 15 W per busy core, a core-hour costs about a quarter of a cent in electricity. The price floor is set at twice that — ≈$0.005/vCPU-hour — and the ceiling we measure ourselves against is the equivalent hyperscaler rate, roughly ten times higher.
Run those numbers forward and they stay modest, so we will say it before you do the division: a two-core machine committed around the clock and kept busy the whole time grosses about $7 a month at the floor and around $70 at the ceiling, minus three or four dollars of electricity — and a pilot this size cannot keep anybody's machine busy the whole time, so early earnings sit at the bottom of that range or below it. Nobody should commit a machine this year for the income. The case is the direction the money moves, a reliability history that is yours from day one, and a share of a network that has to exist before it can pay anyone properly.
The sandbox around a workload is real, and it works in one direction.
It protects the operator's machine from the workload. Someone else's code cannot escape onto their computer.
It does not protect the workload from the operator. A node operator with root access on their own machine can read the memory of a workload running on it.
There is no hardware root of trust on ordinary consumer machines that would prevent this, and we are not going to manufacture one by requiring server silicon that almost nobody owns. That was the original plan. It was wrong, and dropping it is what makes the rest of this project honest.
Encryption covers data at rest only. A powered-down or stolen disk yields ciphertext. A running process holds plaintext in memory because it has to. Encryption at rest is not a confidentiality guarantee against the host, and describing it as one would be a lie of emphasis.
This is a permanent property of the current design, not a gap waiting on a patch. Two things follow from it, and we would rather you hear them here than discover them later.
No names, email addresses, phone numbers, postal addresses, payment details, or account identifiers — as a term of the customer agreement, not an internal preference. There is no coherent position that declines to protect a workload from its host and then accepts your customers' personal data.
Said as a product fact rather than a policy: what runs here today is public content — public sites, public functions. If your site needs customer accounts, a mailing list, or a checkout, it cannot run on PandoCloud yet, and we would rather lose that workload than host it under a promise physics doesn't back. The boundary moves when the architecture can actually protect a workload from its host, not before.
Not caution. Arithmetic. A contact form means a name and an email address sitting in the memory of a machine we have just finished telling you the operator can read. Anything that genuinely needs personal data lives off this network, on infrastructure that makes different promises — and we say so at the link rather than quietly proxying you through our own.
Node operators are contractually prohibited from looking at what runs on their machines. We are pointing out that this is a promise rather than a wall, because those are different things and only one of them is enforced by physics. There is a direction that would close the gap without special silicon — secure multi-party computation, whose no-collusion assumption is far more credible across independently owned machines in different communities than it ever is inside one company's datacenter. It is a future class of workload, not a fix for this one, and nothing on this page depends on it arriving.
A pilot, and specific about which parts are running. Everything above is either live or specified; this is the line between the two.
This page. It is built into an OCI image, pulled by a node agent, unpacked into a bundle, executed under gVisor with no container runtime shim anywhere in the path, and served to you through the PandoCloud gateway. That is the real stack, end to end, on one machine.
Liveness is a plain endpoint. The gateway asks for it every five seconds and the answer is the whole story:
$ curl https://pandocloud.example/healthz
{
"status": "ok",
"uptime_s": 51840,
"workload": "site",
"requests": 12043
}No visitor addresses in the logs, no analytics, no cookies. The server records the path and the status code of a request, never who asked for it.
A few always-on machines we operate ourselves keep the network reachable. They are deliberately sited in regions we are not starting in, so the community filter demotes them by its own logic rather than by our good manners.
And the consequence of a fleet this small, stated rather than rounded off: with a handful of machines, the search in Fig. 2 will often widen all the way to tier three, and the machine that serves a request may be one of ours, in another state. That is the cascade working, not the promise fulfilled — the promise only becomes the common case as machines join. It is exactly why /api/where exists: so you can check which machine served you instead of taking the pitch's word for it.
Three small functions, run on the same network as everything else, each reading the network's own state and collecting nothing about you. Until they exist, the paths answer 501 rather than pretending.
These matter more than they look. A hosted site is one long-lived placement, so the weighted lottery would be invisible with the site alone. Function calls are frequent, short, and placed independently — that is where the earnings actually spread across operators, and where you'll be able to watch it happen.
The pilot cohort is invited rather than signed up, on both sides: a small number of people with a machine to contribute, and a small number of businesses willing to put something real on it. If that is you, the door is one link away — and the link leaves PandoCloud on purpose.
That form is hosted by Google, not by us, and it is the only place we ask for anything about you. It sits off this network deliberately: it collects a name and an email address, and those are exactly the things PandoCloud has told you it cannot protect from the operator of the machine running a workload. So it lives somewhere that makes different promises. Google's terms apply there, not ours.