Open Cloud on ICP
Create an engine
§ cloud engines · builder

Create frontier clouds and let your agents build

Provision Internet Computer cloud engines — a new kind of fully sovereign serverless cloud platform, where tamperproof execution, safe upgrades, and horizontal auto-scaling come built-in, and agents create apps using frontier backend software that unifies logic and data. Cloud engines empower agents, helping them create more sophistication from fewer tokens, while removing most security and systems administration oversight needs.

Create your first cloud engine Read the platform tour

Built for

Agents who build

The Motoko language orthogonally persists your app's data in variables — the program is now the database. This dramatically reduces complexity, delivering more sophistication from fewer tokens.

Built for

Founders who ship

Spin up a cloud engine in minutes, freeing your agents to build and update safely, without security and systems administration oversight. Install premade apps to move even faster.

Built for

Sovereign Enterprise

Choose who supplies compute capacity, where it resides, and the resilience and security level you need. Move your cloud across underlying compute infra without interrupting your apps.

§

Why cloud engines · 01 — 06

Six properties that change what you can ship.

A cloud engine is not a server, not a serverless runtime, and not a managed Kubernetes cluster. It is a virtual compute platform created by a network of nodes combined by a mathematically secure network protocol. The difference matters for every team that wants real software without a real systems team.

§ 01 infra

Tamperproof execution.

Cloud engines are serverless virtual execution environments hosted by mathematically secure networks. There's no vulnerable OS or servers, no firewall to maintain, just tamperproof software running on hackproof infrastructure.

§ 02 infra

Fault-tolerant operation.

Cloud engines symmetrically replicate computation and data across their underlying compute nodes. Redundancy, combined with protocol math, enables them to withstand everything from nodes going offline, to nodes being compromised.

§ 03 code

Orthogonal persistence.

If software ran forever, there would be no need for databases, as data could live inside software variables, records, and collections. This is the 'orthogonal persistence' of cloud engines, which massively simplifies backend software.

§ 04 code

Safe production upgrades.

The Motoko language's serverless framework can detect when an update to software would cause data loss, perhaps because the migration logic was lossy, and rejects the change. Your AI tries again. Your customers never notice.

§ 05 scale

Horizontal auto-scaling.

Scaling is another complexity that cloud engines help you address. Adding new nodes horizontally scales query workloads. Meanwhile, upgrading nodes scales-up data updating workloads, while splitting cloud engines can horizontally scale them.

§ 06 economics

No vendor lock-in, ever.

A cloud engine floats over its underlying compute nodes, which can be added and removed at will. For example, if a cloud engine runs over Big Tech cloud A, it can be moved to cloud B, or sovereign hardware, without interrupting hosted apps.

the network is the cloud

Your engine is a configuration, not a machine.

You choose the nodes. You choose who runs them, where they run, and what class of nodes to use. The Internet Computer's autonomous governance system, and Internet Computer Protocol do the rest — combining your nodes into a symmetric replicated execution environment that your agent-built applications run on.

Because the engine is a configuration, it can be changed without interrupting compute. Add new nodes, remove old ones, change operators or geographies — your apps do not notice the substrate moving beneath them.

How cloud engines work

independent node providers

Choose the hands on your hardware.

Every node provider is verified, auditable, and individually selectable. Pick by reputation, geography, hardware class, compliance posture, or any combination.

  • 412 nodes live

    Northgate Compute

    Enterprise-grade dedicated hardware for tamperproof workloads.

    Denver, CO ★ 4.8 SOC 2
  • 2,847 nodes live

    Helios Infrastructure

    Cloud-backed nodes across AWS and GCP — responsive provisioning.

    San Francisco ★ 4.6 SOC 2
  • 1,203 nodes live

    Meridian Cloud Services

    EU-resident, GDPR-aligned cloud-backed nodes on Azure and OVH.

    Amsterdam ★ 4.7 ISO 27001
  • 84 nodes live

    Prairie Systems

    Small-batch TDX hardware, hand-operated from Tulsa and Chicago.

    Tulsa, OK ★ 4.9 SOC 2
  • 156 nodes live

    Asahi Networks

    APAC-resident dedicated nodes — Tokyo, Osaka, Singapore.

    Tokyo ★ 4.7 SOC 2
  • 92 nodes live

    Verdant Compute

    100% renewable-powered nodes in Iceland and Norway.

    Reykjavík ★ 4.5 ISO 27001
Browse all node providers Are you a node operator? Apply to offer nodes →

safer production upgrades

Your AI cannot ship a lossy upgrade by accident.

A key challenge with apps built on traditional tech, is that when updates are made, the migration of data from old to new formats can result in loss. Traditionally, a systems administration team stands on hand to reverse updates in such situations. But agents want to build autonomously, and they can update production systems orders of magnitude faster than before (even at the speed of conversation).

That's where Motoko, a frontier backend language framework comes in. Motoko requires that software updates come supplied with migration logic that maps the existing structures to new (if there are any). The framework can detect when a migration is lossy, and automatically rejects the update — before any harm is done.

Now, an update that would result in data loss simply results in the agent retrying its coding, reducing the event to the level of a retry after a harmless syntax error was found at compilation time.

actor CRM {
  // v1 → v2 migration
  stable var contacts : [Contact] = [];

  system func preupgrade() {
    // migration logic verified by the
    // platform before the upgrade runs
  };

  system func postupgrade() {
    // new shape installed
  };
}

❯ icp deploy crm.v2.wasm
  verifying migration...
  ✗ upgrade rejected: field 'lastSeen'
    would be discarded in 4,281 records.
  no changes were applied.

the build loop

Work with your agents. Deploy changes.

  1. 01

    Work with your agent.

    Work with a builder like Claude Code providing natural language instructions to improve and extend draft copies apps you develop locally. Or use Caffeine.ai.

  2. 02

    Invoke the deployment skill.

    Your agent writes logic to transform the data in the memory of your production app, into a format required by the new version, which it packages into a .icp file.

  3. 03

    Upgrade is proposed.

    You upload the .icp package to your cloud engine. If the update might cause data loss, this is detected, and the update is rejected. Lossy deploys simply cannot happen.

  4. 04

    You ship.

    If the package is accepted, your update is applied atomically, with the underlying nodes transparently replicating the changes. No queue drain, no restart.

Host apps on frontier compute infrastructure designed for the AI era.

Use opencloud.org to create sovereign frontier cloud networks that are part of the Internet Computer network. Your apps. Your nodes. Your rules. Unleash your agents in a secure environment made safe by guardrails.

Create an engine Platform tour