Your machine should help only when you choose.
Crowdcomputing only works if people trust it. OmnibusCloud asks you to connect a machine you own and let it help computational projects — which raises an obvious question:
What exactly is allowed to run on my computer?
Trust can't be an afterthought; it's part of the design. OmnibusCloud is built around one principle: your machine, your rules — reviewed workloads, run only when you allow them.
You stay in control
Connecting a machine doesn't mean surrendering it. You choose which projects to support, which of your machines may help, and when. A desktop can support one project, a workstation another, a laptop none at all — participation is per machine.
And your machine helps only when it's free, not when you're using it: work runs when the machine is idle and within the rules you set, and you can pause it or leave a project at any time. Schedules & control → covers the specifics.
You're also not feeding an anonymous pool. Crowdcomputing is project-based: you browse visible projects, read the story, and choose what to support. You're not just providing compute — you're helping something get made.
Reviewed before it runs
OmnibusCloud doesn't treat arbitrary code as acceptable work. Workloads are organized through controllers — components that define how a type of computation is prepared, split, executed and validated — and every controller is reviewed before it can join the network. That review is deliberately strict: the code is read, sandbox-tested, and checked by a person before approval, the way a plugin is vetted for an app store. During the beta, controllers can't be added directly at all — only by working with the team, with published source and no commercial use. Open participation does not mean unreviewed execution. Communication between your machine and the platform is authenticated and protected, and work is assigned according to the project and machine rules you've set.
What runs stays in bounds
Approved controllers are self-contained: they bring everything they need — the rendering controller ships its own portable copy of Blender, for example — and run nothing outside themselves. The client runs as an ordinary application on your machine, and by design it doesn't read your files or start programs that aren't part of the controller. The only place it writes is a temp folder you choose — used for a task and cleared afterward. Don't want it writing anything at all? Turn local file use off, and your machine will only ever receive tasks that need no temporary files.
For creators: your project files
Trust runs in both directions. Contributors ask what runs on their machines; creators ask the mirror question: what happens to my files?
Here's how it works. A contributor's machine never receives your project wholesale — it receives a prepared task package: the piece of work assigned to it, together with the input data that piece needs. What that means depends on the workload — for a rendering project, a task carries the part of the scene and the assets required for its frames; other workloads may send no files at all. Every transfer runs over WitRPC, our open-source communication framework, encrypted at the message layer on top of transport security — your data never crosses the network in the clear. And protection doesn't stop at the platform's own layer: because controllers define how a workload is handled, a controller can add its own safeguards on top — encrypting task data with its own scheme, working with trusted keys, translating sources into an internal model so the original file never leaves your machine. On the contributor's side, task data lives in a temporary folder and is cleared when the task completes.
The honest baseline still applies: a public crowdcomputing project means your work is processed on the platform and on machines you don't own — much as any cloud service means your data lives on someone else's servers. Data too important to accept even a theoretical risk doesn't belong on crowd machines — but it doesn't have to miss out either: the same platform runs on-premise, turning your own office machines into a private cluster where nothing leaves your walls. That's the same rule this platform applies to every workload — in both directions.
Open to inspection
The first workload controllers are published as open source, so you don't have to guess what logic reaches your machine — anyone can read exactly what they do. Today, that openness is a real part of how trust works here.
But open code doesn't mean anyone can send arbitrary work to other people's machines. Openness and control go together: inspectable code on one side; controller review, approved workload packages, project-based participation and machine-level rules on the other.
Useful compute is verified compute
In a distributed network, results can't simply be assumed correct — machines fail, drivers differ, connections drop, and bad actors may try to submit invalid work. So validation is part of the model. Different workload types call for different validation strategies, but the principle holds: compute is only valuable if it can be verified.
Not everything belongs on crowd machines
Some computation should stay in datacenters — when data is too sensitive, workloads too tightly coupled, or jobs need specialized infrastructure and strict isolation. OmnibusCloud doesn't assume every workload belongs on crowd machines. It's built for work that can be split into tasks, spread across varied hardware, governed through controllers, validated afterward, and run without exposing sensitive data. The beta starts with rendering and creative work because it fits all of this naturally.
Your machine. Your rules.
Crowdcomputing asks a simple question: what if the machines we already own could help build projects we care about — safely, transparently, and under our control? That's what OmnibusCloud is building, and the public beta is where we prove it in practice.
Let's build the ultracomputer together!