What is a cloud engine?

A cloud engine is a group of independent computers that behave like one serverless platform.

Each computer, or node, runs the same application code and keeps the same application state. The nodes use the Internet Computer Protocol to agree on every change.

No single node decides what the correct result is. If a node goes offline, the others can keep the engine running within the fault tolerance the customer selected.

Applications run as canisters. A canister combines WebAssembly code with persistent data, so many applications do not need a separate application server and database.

The engine is also a configuration, not one machine. Customers choose the node providers, hardware, and locations that form it. They can later add or replace nodes without moving their applications.

That is where the sovereign part becomes practical. Customers can decide who supplies their compute capacity and where their data resides.

Why I find the idea exciting

Traditional cloud services make it easy to rent infrastructure. They also ask teams to assemble and operate many layers around their applications.

A cloud engine includes several properties that teams usually build separately.

Computation and data are replicated across nodes. The protocol handles consensus. Canisters keep their data with their code. The engine can continue running when some nodes fail.

The customer still controls the important infrastructure decisions. They can choose providers, geographies, hardware classes, and the level of failure tolerance they need.

I like that combination. It reduces routine systems work without asking the customer to give one cloud provider complete control.

It also creates a useful platform for agents. An agent can focus on building an application instead of first assembling servers, databases, deployment pipelines, and recovery systems.

The product challenge

The same properties that make cloud engines interesting also make them difficult to explain.

Most customers already understand a server, a virtual machine, or a managed database. A cloud engine does not fit those familiar models.

Creating one introduces unfamiliar decisions. How many nodes do you need? Should those nodes use different providers? Where should they run? What happens to the price and resilience when one choice changes?

The underlying process is also asynchronous. A payment must complete. Nodes may need provisioning. The protocol must form the engine. The customer needs an honest status throughout that process.

The interface needs to explain the consequences without turning every customer into a protocol expert.

Building Open Cloud

Earlier this year, I joined the team building Open Cloud, a marketplace and control panel for cloud engines on the Internet Computer.

My focus has been the customer-facing product across discovery, purchase, deployment, and management. The work belongs to a broader team across frontend, backend, protocol engineering, design, and operations.

We built a public introduction to the model and a marketplace for the available nodes. Customers can browse by provider, geography, hardware, and other properties.

The guided setup starts with questions people can answer. It asks about workload, data location, privacy needs, and failure tolerance. It then turns those answers into a proposed engine.

The full node catalogue remains available for customers who want direct control. Both paths show the effect of each choice on price, provider diversity, and resilience.

Checkout funds the engine through Stripe. The launch flow follows payment, node provisioning, and engine creation. Lifecycle emails keep the customer informed when they are no longer watching the page.

Once the engine is live, the console brings the operational work into one place. Customers can see node health, usage, and applications. They can manage billing, scale the engine, deploy canisters, configure domains, and give team members access.

The codebase reflects the range of the product. The frontend uses SvelteKit and TypeScript. A Rust backend coordinates authentication, payments, registry data, and engine lifecycle operations. Supporting services provision new nodes, while canisters handle operations that belong on the Internet Computer.

Operating the product

The customer journey does not end when the engine becomes live.

I monitor production errors through Sentry, emails through Resend, payments through Stripe, and product use through Plausible. I built an internal dashboard that brings these signals together.

I also built a human-reviewed incident workflow around Sentry. An agent can investigate the codebase, prepare a diagnosis, and propose a fix. I review the work before any change reaches production.

One real-user error exposed a WebKit compatibility issue that we had not anticipated. The agent investigated the browser behaviour and proposed a fix for review.

When we can reproduce a failure, we add a regression test. When we cannot, we improve monitoring so the next occurrence gives us better evidence.

What the work has reinforced

The difficult part of a new infrastructure model is not only making it work.

Customers need a clear path from curiosity to a running application. They need enough information to make good choices, without carrying every implementation detail.

That is the part of Open Cloud I find most interesting. The system is technically deep, but the product should make that depth useful instead of passing it on to the customer.