VERIFIABLE INFRASTRUCTURE

TINYCLOUD, RUNNING IN A TEE

TinyCloud’s trust-sensitive services run inside Trusted Execution Environments so users don’t have to trust our ops team — they can verify the code. We get there using Phala Network’s open-source dstack SDK as the underlying substrate.

WHAT WE HAVE ON DSTACK

RUNNING IN THE ENCLAVE

The TinyCloud services where confidentiality and verifiability matter most live on dstack.

TinyCloud Node

Protocol node (tinycloud-node)

TinyCloud nodes hold user-delegated capabilities and manage user-space data. Running in a TEE means the operator — including us — cannot silently snoop on or mutate user data.

OpenKey

OAuth provider

Identity and session tokens are the highest-value secrets in our stack. Running OpenKey inside a TEE means even a compromised host cannot exfiltrate signing keys or session state.

OpenCredentials

Verifiable credentials issuance

The witness service signs credentials on behalf of users. Remote attestation gives users a way to verify the signer is running unmodified, audited code before they trust a credential it issued.

WHY WE DO THIS

VERIFIABLE, NOT TRUSTED

TinyCloud’s whole pitch is cryptographic verifiability. If a user has to trust us — the company, the operators, the cloud — then sovereignty is only as good as our intentions. That’s not good enough.

Running production services inside a TEE with remote attestation means any user can verify the service binary matches the source we published, without taking our word for it. Sensitive material — keys, credentials, delegations, user data — stays shielded from the host OS and the cloud provider. And because the substrate we use is open-source, we aren’t locked into a proprietary confidential-compute stack we can’t audit ourselves.

THE SUBSTRATE

HOW WE GET THERE: DSTACK

dstack is an open-source SDK from Phala Network for deploying containerized applications into Trusted Execution Environments on Intel TDX hardware. It bundles the pieces you need to run a confidential workload in production: reproducible image builds, enclave launch, and remote attestation.

The result is end-to-end confidentiality for services that would otherwise require users to trust whoever runs the box. Even the host operating system and the cloud provider cannot read memory or tamper with the running workload.

Verifiable Code

Remote attestation lets end-users prove the service they are talking to is running the exact binary we published — no need to trust our ops team.

Shielded Secrets

Signing keys, session state, and user data stay sealed inside the enclave — unreachable by the host OS, hypervisor, or cloud provider.

Open Substrate

dstack is open-source and built on commodity Intel TDX hardware, so our confidential-compute story does not depend on any one vendor lock-in.

HOW IT WORKS

FROM BUILD TO ATTESTATION

01

Build

Reproducible container build — the image hash is the identity of the service.

02

Attest

dstack launches the workload on Intel TDX and produces a remote attestation tying the running code to its measurement.

03

Verify

Clients check the attestation before trusting the service — no operator in the trust path.

BUILD ON A VERIFIABLE STACK

We run our most trust-sensitive services inside TEEs so you don’t have to take our word for anything.