Start here
Architecture
How the four Operayde components fit together — and what each refuses to do.
Last updated 18 Apr 2026
Operayde is four boxes and one simple rule:
Prompts and documents never leave the appliance. Only the metadata needed to run the fleet ever reaches the central plane.
The four boxes
| Component | Where it runs | What it sees | What it refuses |
|---|---|---|---|
| Appliance | Your building | Prompts, documents, audit bodies | Outbound beyond signed fleet endpoints |
| Gateway | On the appliance (edge process) | Request metadata, keys, policy, audit emits | Unscoped keys, unsigned policy bundles |
| Operator Portal | Next.js service (in EU or UAE region) | Tenant + fleet metadata | Prompt content, audit bodies |
| Central Plane | Go services behind apache2 | Signed heads, usage rollups, config, billing | Prompt content, secret material |
Trust boundaries
The enrolment ceremony mints three things:
- An appliance identity key — stored in the TPM, never exported.
- A fleet-signed certificate naming this specific appliance.
- A per-tenant session bootstrap used by your IdP integration.
Everything that flows between the appliance and the central plane is signed by the appliance identity key and verified by the fleet’s root. Anything that flows from the central plane back to the appliance is signed by our fleet key and verified on-appliance.
Failure modes we design for
- Central plane unreachable. The appliance keeps serving. Audit events buffer locally; heads are transmitted once connectivity returns.
- Appliance unreachable. The portal shows
Offlineand blocks mutating operations on it (new keys, policy pushes) until it checks back in. - Central plane compromised. The appliance refuses unsigned or expired fleet artefacts, so a compromised plane cannot push malicious policy or models to your hardware.
- Appliance compromised. Every request has a Merkle-signed audit head outside the appliance, so you can detect tampering even if the attacker controls the box.