Remote hosting

The default Ódinn gateway is a single-user loopback service. Never bind it directly to a public interface.

Remote deployments use the separate multi-user host. It terminates TLS, authenticates provisioned users, and routes each user to an independent loopback gateway, state directory, workspace, bearer token, OAuth store, audit ledger, browser profile, and quota boundary.

Provision a user

There is no public signup endpoint. Provisioning is an operator action:

ODINN_CONFIRM_IMPACT=true \
ODINN_HOST_STATE=/srv/odinn-host \
ODINN_USER_PASSWORD='use-a-password-manager-generated-secret' \
node apps/gateway/src/host.ts user-add \
  --id alice \
  --workspace /srv/odinn-workspaces/alice

Passwords are stored as scrypt-derived hashes in an owner-only user database.

Start the host

ODINN_CONFIRM_IMPACT=true \
ODINN_HOST_STATE=/srv/odinn-host \
ODINN_HOST=0.0.0.0 \
ODINN_PORT=18791 \
ODINN_PUBLIC_ORIGIN=https://odinn.example.com \
ODINN_TLS_CERT=/etc/letsencrypt/live/odinn.example.com/fullchain.pem \
ODINN_TLS_KEY=/etc/letsencrypt/live/odinn.example.com/privkey.pem \
node apps/gateway/src/host.ts

A non-loopback bind refuses to start without a certificate, private key, exact public origin, and impact confirmation.

Authentication behavior

Authentication is durably throttled per client address and user. Sessions use signed, secure, HttpOnly, SameSite cookies. Logout revokes the active session. Host restarts sign users out.

Isolation boundary

The host provides application-level tenant separation. It is not kernel containment and does not make mutually hostile local code safe.

For mutually untrusted users, deploy separate operating-system users, containers, or machines. Never share workspace roots between tenants.

Read Remote isolation and the threat model before production-like deployment.