How Hyphae Cloud works

Creating a project reserves a loopback port and a data directory. Waking it runs hyphae serve on that port with that directory — and nothing else. There is no shared engine, no tenant column, no identifier of yours inside the engine or its write-ahead log.

The orchestrator refuses any hyphae binary whose version --json does not report engine version 3.0.0. What the engine can do is what the engine documents; the Cloud never adds SQL grammar, structures, search features or isolation guarantees.

The owner plane — accounts, projects, keys, wake, sleep, snapshots, function deploys — uses a session token from signup or login. Sessions last 24 hours and live in the client that requested them.

The data plane — the engine's /v2 routes, storage objects, realtime, function invoke — uses a project key of the form hyp1_<id>_<secret>. The key is shown once; the Cloud keeps a hash. The proxy verifies it on every request, strips it, and forwards the request to the engine unchanged. A revoked key fails the very next request on any connection, and its live streams end.

Wake starts the engine and initializes the directory on first start; sleep terminates it gracefully and keeps the directory. Nothing runs for a sleeping project and nothing is lost by sleeping.

head is a probe, not a hash. For a running project it returns what the engine reports about itself — version fields, X-Hyphae headers, the capabilities envelope, decoded under the layout the official SDK implements and shown under the engine's field names. For a sleeping project it returns the engine's status from the directory, including visible_csn and root_digest.

A snapshot is a verified Native backup of a sleeping project: hyphae backup create makes it and independently verifies it. The Cloud stores the engine's own identifiers and adds an id, a label and timestamps. It never runs cp or tar over engine files and never computes a digest of its own.

Restore runs hyphae restore into a fresh directory — the engine verifies the backup, runs doctor and activates it — and the Cloud swaps that directory into place. The previous directory is moved aside and kept. Restore replaces the project's data; it is not a branch, a fork or a point-in-time view, and it leaves the project asleep.

Object storage keeps bytes in a blob backend — a local directory, or S3 over HTTPS — and a catalog of bucket, key, size, etag and content type in the control store. Uploads and downloads go through Cloud routes; no presigned URLs are issued. Nothing about storage enters a project's engine, its WAL or its proofs.

Realtime is an ephemeral, in-process fanout over Server-Sent Events: events exist while the daemon runs, for subscribers connected at publish time, plus a best-effort replay of the last 64 events per channel. It is not a Native stream and not durable.

An edge function is one JS or TS file, stored with its version and SHA-256, run per invocation as a separate time-boxed process on the host. Secrets are owner-set, readable by name only, encrypted under the daemon's process key and injected at invoke. A function is your own trusted code; no sandbox is claimed.

Every control-plane write records project, actor, action, time and a hash of its input. Control-plane bodies are capped at 64 KiB, data-plane bodies at 8 MiB, upstream calls at 30 s, engine start at 15 s. Over budget fails with a typed error and nothing partial is forwarded.

Errors carry a code from a fixed list; the Studio shows the code verbatim and adds an explanation that links to the reference.

The first deploy puts the unchanged process model on one EC2 instance: the daemon on loopback, one hyphae serve per project, Caddy on plain HTTP behind CloudFront, which holds the certificate and is the only thing allowed to reach the instance. Blob bytes go to one S3 bucket over HTTPS with a scoped key; the instance role is unreachable from the daemon and from functions.

It is single-host: no multi-AZ, no failover, no per-project infrastructure. Projects share that host's kernel, disk, CPU and network.