Trust boundary

This page states the security properties of the deployment as they are. It is the same text the product’s claims document carries.

The data plane

A project’s Native process listens on loopback without authentication: the directories are not security-bootstrapped, so Native accepts any loopback request. The Cloud proxy is therefore the only authentication on the data plane, and it holds only for traffic that arrives through it. Any process on the same host — another container sharing the network namespace, a shell on the box, a compromised sidecar — can reach a project’s loopback port directly and bypass the Cloud entirely. GET /v0/projects/{id}/head even reports that port to the owner. This is an accepted, documented property of the single-host deployment, not a secret and not a claim of isolation; it ends when tenants are bootstrapped with Native keys and the proxy presents a per-tenant credential.

Functions

A function runs as the daemon’s OS user on the same host. It can read what that user can read, reach what the host can reach (under Node), burn CPU until the timeout, and observe the loopback ports of every project on the host. No container, VM, seccomp, cgroup or network boundary is claimed. On the AWS deploy the one thing taken from functions is the EC2 instance metadata service, so they cannot obtain the instance role’s credentials; nothing else is fenced.

The clients

The Studio, hcloud and @hyphae/cloud are clients: they hold only your credentials, call public routes, and cannot widen what the control plane accepts. Nothing they display is an authority over the engine.

TLS

The Cloud daemon does not terminate TLS. In production, CloudFront holds the certificate and is the only network source allowed to reach the host; the daemon speaks plain HTTP on loopback behind Caddy.

If you need a stronger property than any stated here, it is not provided yet. See what it is not.