One Native per project

A project is one Hyphae Native engine (hyphae serve, pinned to version 3.0.0) listening on a loopback port of the Cloud host, with its own data directory. There is no shared database kernel and no tenant identifier inside the engine or its write-ahead log: the boundary between two projects is the boundary between two processes and two directories.

What the Cloud adds in front of that process:

• Authentication and routing. /v2/* requests carrying a live project key are forwarded verbatim to that project’s engine; the key never reaches the engine. Method, path, query, headers (minus Authorization) and body go through unchanged, and the engine’s status, headers and body come back unchanged.
• Limits. Control-plane bodies are capped at 64 KiB, data-plane request and response bodies at 8 MiB, upstream calls at 30 s, engine start at 15 s. Over budget fails with a typed error; nothing partial is forwarded.
• Lifecycle. Wake starts the process (initialising the directory on first start); sleep terminates it gracefully and keeps the directory. → Lifecycle
• Receipts. Every control-plane write records project, actor, action, time and a hash of its input.

What the Cloud does not do: it stores no project data, computes no digest of it, and adds no SQL grammar, structures or isolation guarantees on top of Native. /v2/sql speaks only Native’s binary request envelope, which is why neither the Studio nor the CLI offers a SQL editor.

The pinned engine

The daemon refuses a hyphae binary whose version --json does not report engine_version 3.0.0. head shows exactly those fields.

One host

All of a deployment’s projects run on one host today. They share its kernel, CPU, disk and network; the Cloud claims no isolation beyond separate processes and directories, and a project’s engine port is reachable by any process on that host. Read the trust boundary before treating two projects as isolated from each other.