Security & data sovereignty
What Relote can and cannot see, how least-privilege operations work, and the break-glass model.
Relote Cloud is designed around a single promise: you can operate a customer's Context Engine without being able to read its contents. Here's how that holds up.
Isolation
Every Context Engine runs in its own container with its own database. Engines on the same server can't see each other, and each is single-tenant — one engine, one customer.
Least-privilege operations
Setting a server up needs deep access for a few minutes during provisioning. After that, Relote operates through a restricted account that can only run a fixed allow-list of infrastructure commands — start/stop services, deploy a release, take a sealed backup, check health. None of those commands can read engine data. There's no standing ability for Relote to open a database or read a file inside an engine.
Operator-opaque backups
Backups are sealed on the server with the engine's own key before they're sent anywhere. Relote forwards encrypted blobs it can't decrypt (see Backups & recovery).
Break-glass, when it's truly needed
For genuine emergencies — say, a broken engine that can only be fixed by getting inside — there's a deliberate break-glass path: access has to be explicitly authorized, it's time-boxed, the session is recorded, and it auto-revokes afterward. It's the exception, it's auditable, and it's never the default.
What this means for your customers
You can tell a customer, truthfully:
- Their engine is isolated and single-tenant.
- Routine operations can't read their data.
- Backups are encrypted before they leave their server.
- Any exceptional access is authorized, logged, and temporary.
Your responsibilities
Relote secures the platform, but a few things are on you: keep your provider tokens and recovery keys safe, use strong accounts and remove members who no longer need access, and only point Relote at servers dedicated to this purpose.