One Host. A clean Relay Cell for every customer.

Yes. Create a separate managed Relay Cell for each customer. A Cell is a complete Relay instance with its own database, files, identity, secrets, settings, logs, limits, authenticated browser access, backups and recovery lineage. It is more than a customer record or folder inside a shared Relay application.

Give the Cell a dedicated HTTPS address, such as customer-name.relay.example.com, or an equivalently isolated path configured by the Host administrator. The public route must map only to that Cell’s loopback-only service port through an authenticated TLS ingress. Cell ports, Docker, databases and model-runtime ports must not be exposed directly.

The current DigitalOcean guided beta leaves hostname, DNS, TLS, firewall and reverse-proxy configuration with the Host operator. Relay does not ask for your provider token or create those resources for you.

The Host operator generates a single-use bootstrap credential for that Cell. It is valid for 15 minutes and should be transferred to the intended customer through a separate trusted channel. The customer opens the Cell’s HTTPS address, enters the credential, creates the first administrator password and saves the eight recovery codes shown once.

Relay stores digests rather than the clear bootstrap credential, password, session tokens or recovery codes.

No. A customer using a managed Cell normally opens it in a web browser. The Relay Host operator installs, updates, monitors, backs up and recovers the Host and its resident Cells.

The current access model has one built-in administrator credential per Cell. That administrator can sign in from multiple named browser sessions. Sessions last 12 hours, are independently visible and can be revoked.

Relay does not yet provide separate named users, role-based permissions, customer invitations, SSO or organization membership inside one Cell. Multiple browser sessions are not multiple user accounts.

Not through Relay’s normal application or ingress routing. Each managed Cell has its own application state, data root, secret root, private network, loopback port, identity, authentication store and recovery chain. Relay also rejects browser-supplied customer, Cell, session and forwarded-identity headers; a caller cannot select another Cell by changing a header or URL.

This is operational isolation, not protection from the Host administrator or the shared machine’s failure boundary.

Yes. The Host administrator remains trusted. They control the machine and runtime, can inspect resident Cell storage, create the initial first-administrator bootstrap credential before access is configured and operate infrastructure recovery. Containers do not make the Host administrator unable to access customer data. Relay refuses a second bootstrap after the Cell administrator has been configured.

Make this trust relationship clear before onboarding a customer. Relay Host is customer-owned managed infrastructure, not a hostile-tenant SaaS boundary.

Use a separate Host, VM or customer-controlled server when the customer:

• must not trust your Host administrator;
• requires a separate infrastructure or legal-administration boundary;
• cannot share the physical failure domain with another customer; or
• needs a security or compliance promise beyond the supported same-Host model.

Changing folders, ports or container labels does not solve an administrator-trust requirement. Change the Host boundary.

Not yet. In the guided beta, onboarding is a guided manual setup. The Host operator:

• creates and starts the managed Cell;
• assigns a stable HTTPS hostname or path;
• configures the TLS reverse proxy to map that route only to the Cell’s loopback port;
• generates the Cell’s short-lived first-administrator credential;
• hands the credential to the customer through a trusted channel; and
• confirms login, recovery-code custody, session visibility and backup policy.

Relay’s current Settings and Host Supervisor manage Cell lifecycle and capacity, but they do not yet automate DNS, TLS routes, invitation delivery or the complete customer-access handoff.

The customer can use one of the Cell’s recovery codes. Recovery changes the password, rotates all remaining recovery codes and revokes every existing browser session. If the customer loses every recovery code, Relay does not allow the Host administrator to issue another first-administrator bootstrap credential over the configured account. Recovery must instead use the customer-owned encrypted Cell recovery material or a separately supported operator recovery procedure; do not delete or edit the authentication database to bypass this boundary.

Browser recovery codes are not Cell disaster-recovery keys. The operator must separately configure encrypted Cell backup and Host-loss recovery.

Stopping or retaining a managed Cell does not release its licensed capacity. Before ending service, create and verify an encrypted recovery export. Then either:

• export and release the Cell, preserving the verified recovery artifact and freeing the managed-Cell slot; or
• permanently purge the Cell after explicit confirmation when retention is no longer required.

Existing Cells and recovery remain available if a Host license lapses, but the operator cannot create additional managed Cells without valid capacity.

The launch Relay Host entitlement covers one Host with up to ten managed Cells. Running, stopped and retained managed Cells count toward that limit. Exported-and-released and permanently purged Cells do not. A Cell should map to one customer organization unless that organization intentionally shares one administrator and operational boundary.

No. Relay Host runs on infrastructure owned or controlled by you or your customer. You own the server account, infrastructure bill, DNS, TLS, firewall, model credentials, backups, recovery keys and administration. Orionfold supplies Relay software, the signed Cell image, the licensed managed-Host authority, updates and support within the documented topology.

Use the guide that matches your installed Relay release. For the current guided-beta release, use these version-matched Relay 0.44.9 guides. Do not substitute an unversioned or third-party routing recipe for the release-matched trust and ingress contract.