> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myme.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Hosted mode

> Multi-tenant deployments with user signup and tenant provisioning

`AUTH_MODE` selects how the server authenticates callers. Two values:

* **`keys`** (default) — every tenant exists because someone created its admin key. Tenant provisioning is a manual server-side operation; there is no public signup flow. Suitable for self-hosted single-tenant setups, internal multi-tenant deployments where admins provision tenants out-of-band, and development.
* **`hosted`** — a managed-service shape. `/auth/signup` is public, creates a user + tenant + admin key atomically, and returns the plaintext key in the response. Suitable for cloud deployments intended to serve end-users without operator involvement per signup.

API keys work the same way in both modes. The difference is whether a public endpoint provisions them.

## Enabling hosted mode

```bash theme={null}
export AUTH_MODE=hosted
```

At boot, the server mounts three additional routes under `/auth`:

* **`POST /auth/signup`** — creates a user record, a tenant, and an admin API key. No auth required.
* **`GET /auth/me`** — returns the authenticated key's user and tenant. Requires a valid bearer token.
* **Refresh / key rotation** — hosted mode also exposes key-rotation helpers for the authenticated user.

Hosted mode requires a storage backend that supports the `users` and `tenants` stores — both Postgres and SQLite do. The server refuses to start in hosted mode without them.

## Signup payload

```json theme={null}
POST /auth/signup
{
  "email": "user@example.com",
  "name": "Optional display name",
  "provider": "google",
  "provider_account_id": "<stable-id-from-provider>"
}
```

The `provider` + `provider_account_id` pair identifies the user across logins — typically sourced from an upstream identity provider (Google, GitHub, WorkOS, etc.). Signing in through the same provider identity a second time returns the existing tenant and a freshly-rotated admin key; there is no "login" in the traditional session sense, only key provisioning.

The response shape returns the user, tenant, and an admin API key for the new tenant.

## Tenant model

One tenant per signup. A single user always owns exactly one tenant in hosted mode; users who want separate personal and work spaces sign up twice with different provider identities.

Cross-tenant sharing is an explicit grant per scope, the same as in `keys` mode. See [Spaces](/concepts/spaces).

## Managing keys in hosted mode

The admin key returned at signup is the user's primary credential. Apps that need scoped access create further keys under the same tenant via the normal `POST /keys` endpoint using the admin key, or via OAuth's authorization-code flow if the deployment also registers OAuth clients.

Rotating the admin key is the user's responsibility; the SDK's `client.keys.*` surface is available to the user directly.

## Operating a hosted deployment

Beyond `AUTH_MODE=hosted`, the additional operational requirements are:

* **TLS everywhere.** Signup posts credentials; HTTPS is non-optional. Set `ENABLE_HSTS=true` behind a TLS terminator.
* **Durable Postgres.** SQLite is viable but multi-user contention quickly argues for Postgres. Configure `STORAGE_DIALECT=pg` and `DATABASE_URL`.
* **Rate limits on `/auth/token` and `/keys` are tight.** Signup traffic doesn't hit `/auth/token`, but tightening `/auth/signup` at the reverse proxy guards against enumeration.
* **Blob storage reachable from every instance.** Hosted deployments usually run behind a load balancer; use `BLOB_BACKEND=s3` rather than filesystem to avoid per-host divergence.

See [Configuration](/self-hosting/configuration) for the full variable set.