One platform, three layers
OmnibusCloud is a coordination layer for distributed computation — it turns many independent machines into one governed compute system. Beneath the product names and deployment options, there's a single model: a three-layer stack, where each layer is a self-contained product, and each builds on the one below.
The same core runs everywhere — in a single office, across a global enterprise, or on the open internet. What changes between them is not the engine, but how widely it reaches.
WitEngine — the execution core
WitEngine is the distributed-computing foundation. It defines units of work, distributes tasks across heterogeneous machines, balances load by capability, handles retries and failures, and manages the controllers that carry workload logic. It's agnostic to where it runs — the same engine operates identically behind a firewall or across the public network. It can be licensed independently.
This is the layer that makes many separate machines behave as one.
WitCloud — the deployable server
WitCloud is the server product. Install it on your own hardware, connect your machines, and you have a private distributed cluster. It manages client registration, controller distribution, health monitoring, capability-based matching, scheduling and result aggregation. This is what an organization deploys on-premise — its office machines become a governed compute pool, under its own policy, with nothing leaving its boundary.
OmnibusCloud — the public network
OmnibusCloud is WitCloud opened to the internet as a public platform. It adds the social layer — the portal, where projects are published and people join with their machines — and the multi-sided economy that coordinates owners, creators, developers and partners. The public layer launches as crowdcomputing — a permanent, community-driven mode — and grows into the wider ultracomputer around it, without leaving crowdcomputing behind. The ultracomputer →
Controllers: how the platform learns new work
OmnibusCloud isn't a single-purpose system. New kinds of computation are added through controllers — components that define how one type of work is prepared, split, executed and validated. Rendering is the first; simulation, asset processing and other safely distributable workloads can follow.
This is what makes the platform programmable rather than fixed. The first controllers are open source, and developers build and test new ones locally before submitting them — but open participation never means unreviewed execution: every controller is reviewed before it can run on contributors' machines, and stays self-contained when it does — bringing its own dependencies and touching nothing outside itself. Trust & safety →
Scripts: composing work across controllers
If controllers define individual capabilities, scripts are how those capabilities combine. A script describes a flow — activities wired together into one job — and those activities can come from different controllers, not just one.
This is what makes the platform compositional instead of siloed. A developer writing a script can use activities built by other developers: one team's rendering step, another's data-processing step, a third's encoding step — assembled into a single pipeline. A new controller doesn't just add an isolated capability; it becomes a building block everyone else can build on.
That's the difference between a collection of separate tools and an ecosystem. Each controller added to the network increases what every script can do — and that compounding is where the platform's long-term value lies.
This also lets developers engage at whatever level fits. The simplest is to use existing controllers and scripts — running work others have already defined. The next is to write your own scripts — composing existing controllers into new pipelines without building anything low-level. The fullest is to build new controllers — teaching the platform an entirely new kind of computation. Each step asks more than the last, so a developer can start by simply using the network and grow into extending it.
How work flows
A typical workload moves through the same lifecycle:
- A controller defines the work — what inputs it needs, how it splits, how results are validated.
- A job is defined by a script — composing activities from one or more controllers into a flow, as a public crowdcomputing project or an internal enterprise job.
- Machines are matched — by OS, CPU, GPU, memory, installed controller and availability.
- Work is divided — into frames, tiles, or whatever unit the controller defines.
- Tasks are scheduled — only to machines that are capable, idle, and allowed by their owner.
- Work runs and returns — outputs are collected through the approved controller path.
- Results are validated — useful compute must be verified compute.
- Progress becomes visible — in public projects, creators and contributors follow it on the portal.
Heterogeneous by capability
The network isn't made of identical servers — it's made of wildly different machines. OmnibusCloud measures what each can do and assigns work proportionally: a powerful GPU takes more, a modest laptop takes less, and both contribute. Tasks only reach machines that meet a controller's requirements, and only while a machine is idle and within its owner's rules. This capability-aware matching is what makes a heterogeneous network productive instead of chaotic.
Three deployment modes
The same stack runs at three scopes, and they map onto the layers above:
- On-premise — one office, one network, full IT control. The simplest trust model: nothing leaves the organization.
- Cross-organization — offices in different time zones contributing to one private network, so compute follows the sun across a company.
- Public network — the open OmnibusCloud, where anyone can join. This is crowdcomputing today, and the path toward the ultracomputer.
The go-to-market follows the same line: organizations can start behind their own firewall and scale outward as trust grows.
Built on trust boundaries
A distributed network can't treat every machine, workload or participant as automatically trusted. The architecture is organized around explicit boundaries — between the machine owner and the workload, between public projects and private data, between reviewed controllers and arbitrary code, between platform coordination and enterprise-controlled deployments. Those boundaries are what let the system stay open enough to grow and controlled enough to trust. Trust & safety → goes into how they work.
What the architecture is optimized for
OmnibusCloud is built for work that can be split across many machines and verified afterward — workloads that are parallel or batch-oriented, tolerant of machines coming and going, compatible with varied hardware, and safe to run without exposing sensitive data. Rendering fits all of this naturally, which is why it's first.
It is not built to replace tightly coupled supercomputers or confidential datacenter-only workflows. The architecture is ambitious, but not indiscriminate — it aims to be the best place for the workloads that fit its shape, not to run everything.
In one line
OmnibusCloud is a governed coordination layer that turns heterogeneous machine availability into validated distributed compute. It begins with crowdcomputing. It grows toward the ultracomputer.
Let's build the ultracomputer together!