Remote isolation
Ódinn’s remote host separates tenants at the application layer. Each provisioned user receives an independent:
- state directory and SQLite ledger;
- workspace root;
- loopback gateway and bearer token;
- OAuth and audit store;
- browser profile and recovery journal;
- quota boundary.
The host terminates TLS, validates the configured public origin, signs sessions, throttles authentication, strips untrusted proxy headers, and routes each authenticated user to the correct tenant gateway.
What this protects against
Section titled “What this protects against”The boundary is designed to prevent ordinary tenant state, browser profiles, tokens, and workspaces from being mixed through the application.
The host also rejects overlapping workspace roots and can evict idle tenant gateways.
What this does not protect against
Section titled “What this does not protect against”Tenant tools and unconfined code still run on the host under the configured operating-system authority. Application separation is not kernel containment.
Do not place mutually hostile users in one host process under the same OS identity. Use:
- separate operating-system users;
- separately confined containers;
- separate virtual machines;
- separate physical machines
according to the risk.
Deployment rules
Section titled “Deployment rules”- Never expose the single-user gateway.
- Require TLS for every non-loopback bind.
- Set an exact public origin.
- Use password-manager-generated credentials.
- Keep tenant workspaces disjoint.
- Protect host state and TLS private keys.
- Back up tenant state separately.
- Test logout, restart, and disablement behavior before inviting users.
See Remote hosting for setup and Known limits for the public-beta boundary.