> ## Documentation Index
> Fetch the complete documentation index at: https://mux-mike-server-self-update.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Server Access

> Configure authentication and session controls for xum server/browser mode

`xum server` can be accessed from browsers, mobile devices, and other machines on your network. This page covers how access control works, including the GitHub owner login allowlist.

## Authentication modes

By default, server access is protected by a bearer token.

Token resolution order:

1. `--no-auth` (disables auth entirely)
2. `--auth-token <token>`
3. `XUM_SERVER_AUTH_TOKEN`
4. Auto-generated token at startup

<Warning>
  `--no-auth` makes the server open to anyone who can reach it. Use only on trusted/private
  networks.
</Warning>

## Configure GitHub owner login

Xum can optionally allow GitHub Device Flow login for exactly one GitHub account.

Set the allowed account with either:

* Environment variable: `XUM_SERVER_AUTH_GITHUB_OWNER`
* Config file key: `serverAuthGithubOwner` in `~/.xum/config.json`

There is currently no UI control for this setting; configure it via env/config.

Example:

```json theme={null}
{
  "serverAuthGithubOwner": "octocat"
}
```

If both are set, `XUM_SERVER_AUTH_GITHUB_OWNER` takes precedence.

When enabled, the auth modal shows **Login with GitHub**. Xum verifies the GitHub `login` value against the configured owner (case-insensitive). Non-matching users are rejected.

<Note>
  This allowlist currently supports a single GitHub username. It does not support multiple users or
  GitHub organization membership rules.
</Note>

## Server Access settings page

Open **Settings → Server Access** to manage browser sessions.

You can:

* Refresh active sessions
* Revoke a specific session
* Log out the current session
* Revoke all other sessions

This page manages cookie-backed browser sessions. Token-based access remains valid until you rotate/change the server token.

## Network exposure and bind settings

To expose Xum beyond localhost and configure bind host/port in the UI:

1. Open **Settings → Experiments**
2. Enable **Expose API server on LAN/VPN**
3. Configure bind host, port, and **Serve xum web UI**
4. Click **Apply**

Equivalent CLI options:

* `--host <host>`
* `--port <port>`
* `--ssh-host <host>`
* `--add-project <path>`

## Updating the server

Open **About** to check for updates, download, then choose **Install & restart**. The server uses the saved update channel, or infers Nightly from an installed `-next.` version when no channel is saved. Stable follows the npm `latest` tag; Nightly follows `next`. Switching channels can install an older version. Checks and restarts are manual. The registry must be reachable over HTTPS without credentials (`XUM_UPDATE_REGISTRY_URL` or `npm_config_registry` override the default); registries that require authentication for metadata report the registry error at check time.

Self-update requires a supervisor that restarts the server after it exits, an external launcher symlink pointing to an installed `@coder/xum` CLI with a bun, npm, or pnpm lockfile, and a stable auth token (`MUX_SERVER_AUTH_TOKEN`, `--auth-token`, or `--no-auth`). A generated token dies with the process, so the relaunched server would lock every browser session out. Set `XUM_BINARY` to that symlink and `XUM_SERVER_SUPERVISED=true` only when a supervisor is configured. The `coder/mux` registry module with `restart_on_kill=true` already declares these through its launcher environment. Unsupported installations show a reason instead of offering an update.

Downloads install an exact package version in a sibling staging directory without changing the running installation. Restart is blocked by active streams, pending turns, workspaces still initializing or being archived, removed, forked, or staged, queued messages, pending auto-retries, open or starting terminals, and running background processes. Finish or stop that work, then retry. There is no automatic restart-when-idle in this version.

After activation, the server exits gracefully and the supervisor relaunches it. Browser clients reconnect and reload when the server build changes. If reconnection takes longer than about 45 seconds, use **Retry**.

<Warning>
  The registry module counts self-updates toward `max_restart_attempts`, just like other exits. The
  server cannot read the remaining restart budget. Ensure the supervisor has restarts available, or
  configure unlimited restarts (`max_restart_attempts=0`) before relying on self-update.
</Warning>

## Related

* [CLI reference](/reference/cli)