Scope and Audience

What this document covers

This documentation describes the technical properties of a Cloud Engine: a private, replicated computer running the Internet Computer Protocol, assembled by Swiss Subnet AG for a single client. It covers the architecture, the trust and security model, the interfaces, where data resides, how an engine is operated and upgraded, and where the platform does not fit.

Where a property comes from the underlying Internet Computer Protocol rather than from Swiss Subnet’s operation of it, that is stated and the primary source is linked. The distinction matters when assessing the platform: protocol properties are publicly documented and stable, whereas operational properties are Swiss Subnet’s own commitments.

Who it is written for

Engineers, architects and IT staff assessing whether the platform fits a specific workload.

Familiarity with distributed ledger technology, consensus protocols, canisters or confidential computing is not assumed. Every such term is explained on first use and listed in the Glossary.

What this document is not

Not a conformity statement. Statements of conformity with any regulation are out of scope: they require legal assessment and are handled separately. What follows describes technical properties only, and any regulatory conclusions drawn from them remain the client’s own.

Not a commercial proposal. No pricing, no client-facing service levels, no delivery timelines. Where an operational figure appears, it comes with how that figure is established — not with what is contractually owed to a client. Availability and response figures quoted in Swiss Subnet and Cloud Engines and Operations are Swiss Subnet’s obligations against its node providers, which is what makes them verifiable claims about the platform rather than commitments to any client.

Not a legal assessment. Questions that turn on law rather than on how the platform works — lawful access and compulsion against an operator among them — are handled separately and are not answered here.

Not a migration plan. Integration Patterns describes how systems connect in general terms. Planning a specific migration requires knowledge of the target environment and is done separately.

Not the API reference. Interfaces links to the authoritative protocol documentation rather than reproducing it, since a copy would drift out of date.

Not a roadmap. Capabilities that do not exist today are named as absent in Limitations. Planned work is listed there too, labelled as intention rather than commitment.

Reading the status markers

Not every property described here is in production today. Three markers distinguish what can be relied on now from what cannot:

Marker	Meaning
(no marker)	In production and verifiable today
Work in progress	Being implemented; not yet true of every engine
Planned	Intended; no implementation exists