diff --git a/.env.example b/.env.example
index d80007943..8379d84b9 100644
--- a/.env.example
+++ b/.env.example
@@ -1,7 +1,5 @@
 # Server-side Vite development proxy target. This value is never exposed to
 # browser JavaScript.
-# Retired AGENTS_API_PROXY_* and AGENTS_CORE_WEB_* settings are rejected; use
-# OAC_WEB_DEV_PROXY_* and OAC_WEB_* below, including in existing .env files.
 OAC_WEB_DEV_PROXY_TARGET=http://127.0.0.1:8091
 
 # Legacy development proxy only. The console never calls /v1; the Vite server
@@ -9,13 +7,9 @@ OAC_WEB_DEV_PROXY_TARGET=http://127.0.0.1:8091
 # scripts/core-doctor.mjs (see docs/web/roadmap.md). Plaintext bearer file read
 # only by the local Vite server; if unset, it checks this conventional path.
 OAC_WEB_DEV_PROXY_TOKEN_FILE=~/.oac/dev/web-token
-# Optional server-only OTLP/HTTP Runtime history exporter configuration.
-# When unset, current observations and the Dashboard require no telemetry backend.
-# Runtime history uses the Core PostgreSQL database with 30-second periodic sampling.
-# Optional sampling/OTLP export overrides: services/agents-api/runtime-history/README.md
-# OAC_HISTORY_SETTINGS_FILE=/absolute/path/runtime-history.json
-# Set sample_interval_seconds (5..300) in that server-only file to change the
-# sampling interval; omitted or zero keeps 30 seconds.
+
+# Core reads its own environment, not this file. Core settings, including
+# Runtime history sampling and export, are in docs/configuration.md.
 
 # Alternative server-side value for the legacy /v1 development proxy. Never use a
 # VITE_ prefix, and do not set this together with OAC_WEB_DEV_PROXY_TOKEN_FILE.
diff --git a/AGENTS.md b/AGENTS.md
index f357f109b..151e790de 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -47,7 +47,7 @@ Most boundaries still span several files; the listed file or directory is the en
 - Each setting and each piece of data is written in one place and read from that place, with no second copy, no environment-variable or file fallback and no alias.
 - Configuration files are grouped by category, never scattered. A new setting joins its category and lives beside its peers.
 
-The categories are [process settings](docs/configuration.md#process-settings-configjson), [derived files](docs/configuration.md#how-oac-apply-works), [secrets](docs/configuration.md#secrets-and-identity), and Core's database for [runtime settings](docs/configuration.md#runtime-settings-web) and execution data. [Configuration](docs/configuration.md) owns the installation layout and the settings themselves.
+The categories are [process settings](docs/configuration.md#process-settings-configjson), [derived files](docs/configuration.md#how-oac-apply-works), [secrets](docs/configuration.md#installation-directory), and Core's database for [runtime settings](docs/configuration.md#runtime-settings-web) and execution data. [Configuration](docs/configuration.md) owns the installation layout and the settings themselves.
 
 ### Pre-release: no compatibility layers
 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index df21e9d58..ff36aacd9 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -20,7 +20,7 @@ This guide owns how to work in the repository: documentation ownership, the repo
 | Harness qualification and acceptance | [Harness integration](contracts/agents-api/harnesses.md) |
 | Harness selection and Agent defaults | [Harness selection](contracts/agents-api/harness-selection.md) |
 | Provider selection, sandbox deployment and E2B setup | [Sandbox deployment](contracts/agents-api/sandbox-deployment.md) |
-| Hosted sandbox nodes | [Hosted sandbox manager](services/agents-api/HOSTED-SANDBOX-MANAGER.md) |
+| Hosted sandbox nodes | [Nodes guide](docs/getting-started/nodes.md) and [sandbox deployment contract](contracts/agents-api/sandbox-deployment.md) |
 | Claude private bridge and Runtime artifact | [Claude SDK adapter](packages/claude-sdk-adapter/README.md) |
 | MiniMax Code and Claude Runtime adapter rules | [MiniMax Code Runtime](services/agents-api/deploy/mcode/README.md), [Claude Runtime](services/agents-api/deploy/claude/README.md) |
 | CI, distribution builds, installer lifecycle and managed HTTPS, release publication | [Maintainer guide](docs/maintainers.md) |
@@ -150,7 +150,7 @@ Native adapter changes require their build/check targets and live provider accep
 
 Provider bootstrap, Runtime images and Harness adapters must agree on these names. Daemon startup rejects renamed settings before any subcommand and reports replacements without values; the separate Parsar product integration settings remain unchanged. No old label is accepted as a fallback.
 
-Historical Runtime and project-version upgrades are not supported. Do not ship retired installer conversion implementations; preserve rejection guards under the [installer lifecycle contract](deploy/install/README.md#versions-and-the-lock). Preserve older installations, Runtime files, provider resources and Session history; install the current release separately. Startup never verifies and rebinds historical allocations or accepts node deployments without a valid specification. Keep the original Core responsible for unresolved resources; see the [operator boundary](services/agents-api/HOSTED-SANDBOX-MANAGER.md#historical-installations). Use this release's template builder for new E2B templates. Ordinary current-version database initialization uses the migration runner.
+Historical Runtime and project-version upgrades are not supported. Do not ship retired installer conversion implementations; preserve rejection guards under the [installer lifecycle contract](deploy/install/README.md#versions-and-the-lock). Preserve older installations, Runtime files, provider resources and Session history; install the current release separately. Startup never verifies and rebinds historical allocations or accepts node deployments without a valid specification. Keep the original Core responsible for unresolved resources; see the [installation version policy](docs/getting-started/operations.md#installation-version-policy). Use this release's template builder for new E2B templates. Ordinary current-version database initialization uses the migration runner.
 
 The dormant Pi adapter keeps its `parsar` provider slug because the separate Parsar product pins model selections to that identity. This is a product boundary exception for the name guard, like the skill-upload integration.
 
diff --git a/apps/docs/content/docs/admin-api.mdx b/apps/docs/content/docs/admin-api.mdx
index 1bdef28a1..b64a0de5b 100644
--- a/apps/docs/content/docs/admin-api.mdx
+++ b/apps/docs/content/docs/admin-api.mdx
@@ -102,7 +102,7 @@ it is operational attribution, not per-key billing.
 ## Sandbox administration
 
 The [deployment configuration contract](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md),
-[nodes and sandbox backends reference](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md)
+[nodes guide](/hosted-providers)
 and [generated OpenAPI](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/core.openapi.yaml)
 define deployment and node operations:
 
diff --git a/apps/docs/content/docs/configure.mdx b/apps/docs/content/docs/configure.mdx
index 464faf819..0a5d41982 100644
--- a/apps/docs/content/docs/configure.mdx
+++ b/apps/docs/content/docs/configure.mdx
@@ -8,21 +8,13 @@ Every setting of a Core installation has exactly one home. There are two kinds:
 | Kind | Examples | Home | Change it with | Takes effect |
 | --- | --- | --- | --- | --- |
 | [Process settings](#process-settings-configjson) | Public URL, ports, logging, harnesses, execution concurrency, audit retention, OAuth origins, database pool, Runtime history export | `config.json` in the installation directory (default `~/.oac/core`) | Web domain setup or `oac domain` for managed HTTPS; otherwise edit the file, then run `oac apply` | `oac apply` restarts the services that read the changed settings |
-| [Runtime settings](#runtime-settings-web) | Sandbox backend and size, nodes, Projects and keys, default models, executor credentials | Core's PostgreSQL database | Web, or the Core API (`/core/v1`) with the Core key | Saved without a Core restart; node Runtime changes prepare asynchronously |
+| [Runtime settings](#runtime-settings-web) | Sandbox backend and size, nodes, Projects and keys, default models, executor credentials | Core's PostgreSQL database | Web, or the Core API (`/core/v1`) with the Core key | Saved without a Core restart; nodes prepare Runtime changes asynchronously |
 
-Web's **System** page shows both: the installation's addresses, the process settings
-read-only under **Startup settings**, and managed HTTPS under **Domain and HTTPS** with the path of `config.json` and the apply
-command, the default models, and the sandbox configuration. Secrets live in
-[`secrets/`](#secrets-and-identity), one copy each. Each setting is set in one place;
-the files in `generated/` are only derived from `config.json`. No configuration file
-defines Projects or API keys.
+Web's **System** page shows the installation's addresses, the default models, the sandbox configuration and, under **Startup settings**, the process settings read-only with the path of `config.json` and the apply command. Secrets live in [`secrets/`](#installation-directory), one copy each. The files in `generated/` are derived from `config.json`. No configuration file defines Projects or API keys.
 
 ## Process settings: config.json
 
-The installer writes every setting that applies to the installation's
-[mode](/install#modes), so the file shows each value. Installer flags
-listed in [Installation options](/install-options) only seed it. To change a
-setting, edit the file and apply it:
+The installer writes every setting that applies to the installation's [mode](/install-options#modes), so the file shows each value. Installer flags listed in [installation options](/install-options) only seed it. To change a setting, edit the file and apply it:
 
 ```sh
 ~/.oac/core/oac apply --dry-run   # show the changed settings, files and restarts
@@ -31,59 +23,29 @@ setting, edit the file and apply it:
 
 ### How oac apply works
 
-1. It validates `config.json` and changes nothing if a value is invalid. `mode` and
-   `native_core` and `ingress` are fixed after installation; to change them, install into a new
-   directory.
-2. It writes the files Core, Web and Compose read into `generated/`: `compose.json`,
-   `core.env`, `core-key-digests.json`, `settings.json` and, when used,
-   `runtime-history.json`, the managed `Caddyfile` and the native Core unit. Don't edit them. A generated file
-   edited by hand stops `apply` until you move the change into `config.json` and run
-   `oac apply --discard-edits`, which keeps the edited copy as
-   `generated/<file>.edited-<time>`.
-3. It compares what it wrote with what actually runs. Each container carries a digest
-   of its inputs (the `io.oac.inputs` label; native Core carries `OAC_INPUTS`),
-   and `apply` recreates or restarts exactly the services whose inputs differ: Core
-   first, then Web. The **Restarts** column below says which services a setting
-   affects. Restarting Web signs everyone out of the console.
-4. While any service runs, `apply` also starts the stopped ones. After `oac stop`,
-   it only writes the files and the installation stays stopped.
-5. If Core refuses a value at startup, `apply` prints Core's startup error. If every
-   service was running with the previous files, it restores them and starts the
-   services again; otherwise it reports the failure, and the next `apply` finishes
-   the work.
-
-`oac status` reports changes to `config.json` that are not applied yet and
-generated files edited by hand.
+1. It validates `config.json` and changes nothing if a value is invalid. `mode`, `native_core` and `ingress` are fixed after installation; to change them, install into a new directory.
+2. It writes the files Core, Web and Compose read into `generated/`: `compose.json`, `core.env`, `core-key-digests.json`, `settings.json` and, when used, `runtime-history.json`, the managed `Caddyfile` and the native Core unit. Don't edit them. A generated file edited by hand stops `apply` until you move the change into `config.json` and run `oac apply --discard-edits`, which keeps the edited copy as `generated/<file>.edited-<time>`.
+3. It compares what it wrote with what actually runs. Each container carries a digest of its inputs (the `io.oac.inputs` label; native Core carries `OAC_INPUTS`), and `apply` recreates or restarts exactly the services whose inputs differ: Core first, then Web. The **Restarts** column below says which services a setting affects; see [stop and restart](/troubleshooting#stop-and-restart) for what a restart interrupts.
+4. While any service runs, `apply` also starts the stopped ones. After `oac stop`, it only writes the files and the installation stays stopped.
+5. If Core refuses a value at startup, `apply` prints Core's startup error. If every service was running with the previous files, it restores them and starts the services again; otherwise it reports the failure, and the next `apply` finishes the work.
+
+`oac status` reports changes to `config.json` that are not applied yet and generated files edited by hand.
 
 ### Changing the public URL
 
-`public_url` is the one origin that applications, nodes, sandboxes and self-hosted
-executors use; Core derives the daemon WebSocket URL, the self-hosted `remote_url` and
-each sandbox's connection address from it. With `null`, Core uses
-the configured loopback Core origin. The default managed installation still exposes
-Web by IP for setup; that initial HTTP endpoint does not expose the machine API.
-
-For managed ingress, use **System → Domain and HTTPS** or `oac domain HOSTNAME`.
-Both use the installation lock and the same `config.json`/`oac apply` operation.
-The installer verifies the certificate before switching addresses. External ingress
-uses a separately configured proxy and `oac apply`. When nodes, hosted
-sandboxes or self-hosted executors are bound to the current address, `apply` lists
-them and asks you to type the new URL (`--confirm-public-url-change URL` when not
-interactive). Afterwards, nodes on the old address get no new sandboxes: remove them
-in Web and add them again. Existing sandboxes and executors keep working only while
-the old address still reaches this Core, and `apply` warns that self-hosted executors
-must restart with the new `remote_url`. Their installer refuses to reuse an
-installation made for the old address, and moving an executor isn't supported yet:
-create new self-hosted Sessions and connect their hosts again. Update your reverse
-proxy first when using external ingress. A managed domain change replaces the
-previous domain route; reconnect clients and executors that still use it.
+`public_url` is the one origin that applications, nodes, sandboxes and self-hosted executors use. Core derives the daemon WebSocket URL, the self-hosted `remote_url` and each sandbox's connection address from it. With `null`, Core uses its loopback origin. Until `public_url` is set, a managed installation serves only Web, over HTTP on the host's IP address at `ports.web`; afterwards that address redirects to `public_url`.
+
+With managed ingress, change it in Web (**System** → **Configure domain and HTTPS**) or with `oac domain HOSTNAME`. Both take the installation lock, verify the new certificate and address, then write `config.json` and apply it. With external ingress, update your reverse proxy first, then edit `public_url` and run `oac apply`.
+
+When nodes, hosted sandboxes or self-hosted executors are bound to the current address, `apply` lists them and asks you to type the new URL (`--confirm-public-url-change URL` without a terminal). Afterwards:
+
+- Nodes on the old address get no new sandboxes: remove them in Web and add them again.
+- Existing sandboxes and executors keep working only while the old address still reaches this Core. A managed domain change replaces the previous domain route.
+- Self-hosted executors must restart with the new `remote_url`, and their installer refuses an installation made for the old address: create new self-hosted Sessions and connect their hosts again.
 
 ### Settings
 
-`core.runtime_history.headers` may hold export credentials. They stay in the
-`0600` `config.json` and the generated file Core reads, and never appear in `oac`
-output or in Core's settings snapshot. Model providers are not process settings; see
-[Default models](#default-models).
+`core.runtime_history.headers` may hold export credentials. They stay in the `0600` `config.json` and the generated file Core reads, and never appear in `oac` output or in Core's settings snapshot. Model providers are not process settings; see [Default models](#default-models).
 
 
 | Key | Type | Default | Modes | Change | Restarts | Meaning |
@@ -112,139 +74,90 @@ output or in Core's settings snapshot. Model providers are not process settings;
 | `core.database_pool.max_conn_idle_time` | string or null (Go duration) | `null` | `all`, `core-only` | `oac apply` | core | Go duration. null keeps the driver default, 30m. |
 | `core.database_pool.health_check_period` | string or null (Go duration) | `null` | `all`, `core-only` | `oac apply` | core | Go duration. null keeps the driver default, 1m. |
 | `core.runtime_history` | object or null | `null` | `all`, `core-only` | `oac apply` | core | Runtime history collection and OTLP export. null keeps local collection with Core's defaults. Core checks the values at startup. |
-| `core.runtime_history.transport` | string | none | `all`, `core-only` | `oac apply` | core | OTLP export transport. |
-| `core.runtime_history.endpoint` | string | none | `all`, `core-only` | `oac apply` | core | OTLP collector endpoint. Omit it to keep history local. |
-| `core.runtime_history.insecure` | boolean | none | `all`, `core-only` | `oac apply` | core | Export without TLS. |
-| `core.runtime_history.headers` | object of string values | none | `all`, `core-only` | `oac apply` | core | Headers sent with each export, such as credentials. Never shown by oac or Core. Sensitive. |
-| `core.runtime_history.queue_capacity` | integer | none | `all`, `core-only` | `oac apply` | core | Export queue capacity. |
-| `core.runtime_history.timeout_seconds` | integer | none | `all`, `core-only` | `oac apply` | core | Export and query timeout in seconds. |
-| `core.runtime_history.sample_interval_seconds` | integer | none | `all`, `core-only` | `oac apply` | core | Periodic sampling interval in seconds. |
+| `core.runtime_history.transport` | string | none | `all`, `core-only` | `oac apply` | core | OTLP export transport: `otlp_http`. Required with endpoint. |
+| `core.runtime_history.endpoint` | string | none | `all`, `core-only` | `oac apply` | core | OTLP/HTTP metrics URL: a canonical absolute URL with a path and no credentials, query or fragment; HTTPS, or HTTP with insecure. Omit it to keep history local; transport, insecure and headers then must be absent. |
+| `core.runtime_history.insecure` | boolean | none | `all`, `core-only` | `oac apply` | core | Export without TLS. Required for an HTTP endpoint and refused for HTTPS. |
+| `core.runtime_history.headers` | object of string values | none | `all`, `core-only` | `oac apply` | core | Headers sent with each export, such as credentials. Host, Content-Length, Content-Type and Content-Encoding are refused. Never shown by oac or Core. Sensitive. |
+| `core.runtime_history.queue_capacity` | integer | none | `all`, `core-only` | `oac apply` | core | Capacity of the history write queue and of the export queue, up to 4096. Omitted or 0 selects 256. |
+| `core.runtime_history.timeout_seconds` | integer | none | `all`, `core-only` | `oac apply` | core | History write, export and query timeout in seconds, up to 30. Omitted or 0 selects 2. |
+| `core.runtime_history.sample_interval_seconds` | integer | none | `all`, `core-only` | `oac apply` | core | Periodic sampling interval in seconds, 5 to 300. Omitted or 0 selects 30. |
 | `ingress` | `"managed"` \| `"external"` | `"external"` | all | fixed | none | managed provides automatic HTTPS and Web domain setup for a combined Docker installation; install.sh selects it by default. external uses your existing proxy. Fixed after installation. |
 
 
-The schema is
-[`deploy/install/config.schema.json`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/deploy/install/config.schema.json); each
-installation keeps a copy in `generated/config.schema.json` for editors. Core serves
-the non-secret settings snapshot, with the path of `config.json` and the apply
-command, at `GET /core/v1/installation`.
+The schema is [`deploy/install/config.schema.json`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/deploy/install/config.schema.json); each installation keeps a copy in `generated/config.schema.json` for editors. Core serves the non-secret settings snapshot, with the path of `config.json` and the apply command, at `GET /core/v1/installation`. How Core collects and keeps Runtime history is in [retained history](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/runtime-observability.md#retained-history-and-optional-export).
 
 ## Runtime settings: Web
 
-Runtime settings live in Core's database. Change them in Web; scripts use the same
-Core API with the Core key.
+Runtime settings live in Core's database. Change them in Web; scripts use the same Core API with the Core key.
 
 | Setting | Where in Web | Core API | Notes |
 | --- | --- | --- | --- |
-| Sandbox backend: Docker, microsandbox or E2B | **System** → **Sandbox backend**: the setup wizard, ending with **Save configuration** | `/core/v1/sandbox/deployment` | One backend per deployment. `install.sh --sandbox` saves the first choice. Changing backend requires explicit reset and a new setup at the resulting generation |
-| Sandbox size and Runtime release | **System** → **Sandbox backend**: **Change resources** | `/core/v1/sandbox/deployment` | New targets use the saved size; retained generations keep their original specification. See [Sandbox deployment](#sandbox-deployment) |
-| E2B API key and template build | **System** → **Sandbox backend**: the setup wizard's **E2B cloud** | `/core/v1/sandbox/deployment` | The key is write-only and encrypted |
-| Nodes and their capacity | **Nodes**: **Add node**, **Edit node**, **Remove node** on a node's page (**Remove** in its list row) | `/core/v1/sandbox/enrollment-tokens`, `/core/v1/sandbox/nodes` | See [Node capacity](#node-capacity) and the [nodes guide](/hosted-providers) |
+| Sandbox backend: Docker, microsandbox or E2B | **System** → **Manage sandbox configuration**: the setup wizard, ending with **Save configuration** | `/core/v1/sandbox/deployment` | One backend per installation. `install.sh --sandbox` saves the first choice. Another backend needs **Reset deployment** first; see [change the sandbox configuration](/hosted-providers#change-the-sandbox-configuration) |
+| Sandbox size, Runtime release, E2B key and template build | **System** → **Manage sandbox configuration** → **Change resources** | `/core/v1/sandbox/deployment` | Web proposes the sizes in [`standard-sizes.json`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/apps/web/src/features/sandbox/standard-sizes.json). Existing sandboxes keep their size and release. The E2B key is write-only and encrypted |
+| Nodes and their capacity | **Nodes**: **Add node**; **Edit node** and **Remove node** on a node's page | `/core/v1/sandbox/enrollment-tokens`, `/core/v1/sandbox/nodes` | See [Node capacity](#node-capacity) and the [nodes guide](/hosted-providers) |
 | Projects and API keys | **Projects and keys**: **Create project**, **Rename**, **Issue key**, **Revoke**, **Archive** | `/core/v1/projects` | Keys are shown once; Core stores digests |
-| Default model per harness | **System**: **Default model** | `/core/v1/harnesses/{harness}/model-configuration` | See [Default models](#default-models) |
-| Executor credentials of a self-hosted Session | **Session log**, the Session's page: **Executor credentials** | `/core/v1/projects/{project_id}/environments/{environment_id}/executor-credentials` | See [self-hosted executors](/self-hosted-execution) |
-
-Which harnesses are enabled, and the default one, are process settings
-(`core.harnesses`, `core.default_harness`); System shows them read-only. The
-[API index](/public-api#core-api) lists every Core API route.
-
-### Sandbox deployment
+| Default model per harness | **System** → **Default model configuration**: **Set** | `/core/v1/harnesses/{harness}/model-configuration` | See [Default models](#default-models) |
+| Executor credentials of a self-hosted Session | **Session log**, then the **Session** page: **Executor credentials** | `/core/v1/projects/{project_id}/environments/{environment_id}/executor-credentials` | See [self-hosted executors](/self-hosted-execution) |
 
-Configure the backend and sandbox size in **System** → **Sandbox backend**.
-**Change resources** edits the deployment target; **Nodes** manages enrolled
-machines and their readiness.
-
-The [deployment contract](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md) owns
-provider-specific fields, limits, Runtime identity and online change/reset rules.
-The [node protocol](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/node-generation-protocol.md) owns
-generation preparation and wire compatibility. This page does not maintain
-another version table or set of provider rules.
-
-Web proposes sizes from
-[`standard-sizes.json`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/apps/web/src/features/sandbox/standard-sizes.json);
-the installer uses the bundle's copy of that source. For operator steps, see
-[changing the sandbox backend or size](/hosted-providers#change-the-sandbox-backend-or-size).
+Which harnesses are enabled, and the default one, are process settings (`core.harnesses`, `core.default_harness`); System shows them read-only. The [API index](/public-api#core-api) lists every Core API route, and the [deployment contract](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md) defines the sandbox fields, limits and change rules.
 
 ### Node capacity
 
-Core approves a node's capacity when you generate its Add node command: **Sandboxes at
-once** (`max_active`, default 2) and, for microsandbox only, **Retained sandboxes**
-(`max_retained`, default 8), with `max_retained >= max_active >= 1`. Docker never
-suspends sandboxes, so Web doesn't ask for it and Core keeps `max_retained` equal to
-`max_active`. Change them later with **Edit node**. Reservations and cleanup that is
-not confirmed count against capacity; lowering a limit stops no running sandbox. A
-node's own files can't change its capacity, size or Runtime.
+Core approves a node's capacity when you generate its Add node command: **Sandboxes at once** (`max_active`, default 2) and, for microsandbox only, **Retained sandboxes** (`max_retained`, default 8), with `max_retained >= max_active >= 1`. Docker never suspends sandboxes, so Web doesn't ask for it and Core keeps `max_retained` equal to `max_active`. Change them later with **Edit node**. Reservations and cleanup that is not confirmed count against capacity; lowering a limit stops no running sandbox. A node's own files can't change its capacity, size or Runtime.
 
 `core.execution_concurrency` is unrelated: it limits concurrent execution work in Core.
 
 ### Default models
 
-Set a default in **System** → **Default model**, or use
-`PUT /core/v1/harnesses/{harness}/model-configuration`. Core encrypts provider keys
-with `secrets/credential.key` and does not return them.
+Set a default in **System** → **Default model configuration**, or use `PUT /core/v1/harnesses/{harness}/model-configuration`. Core encrypts provider keys with `secrets/credential.key` and never returns them. [Model execution](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/model-execution.md#deployment-defaults) owns the request fields and replacement rules, and [precedence](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/model-execution.md#saved-defaults-and-precedence) says which Sessions use a default.
 
-[Model execution](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/model-execution.md#deployment-defaults)
-owns the request fields, replacement rules and applicable sources. The
-[user guide](/user-guide#which-model-provider-a-session-uses) explains how to
-choose a source for a Session.
+## Installation directory
 
-## Secrets and identity
+The installer creates the installation directory, `~/.oac/core` by default, with mode `0700`; the files in `secrets/` are `0600`.
 
-| File | Content | Changed by |
+| Path | Content | Changed by |
 | --- | --- | --- |
+| `config.json` | [Process settings](#process-settings-configjson). The only file you edit | You, then `oac apply`; managed domain setup for `public_url` |
+| `oac` | The [management command](/troubleshooting#the-oac-command) | The installer |
+| `state.json` | Installation ID, Compose project name, image IDs, source commit and the digests of generated files | The tools only |
 | `secrets/core.key` | The [Core key](/troubleshooting#core-key) | `oac rotate-core-key` |
 | `secrets/credential.key` | Encryption key for what Core stores sealed in the database: model providers, the E2B key, Vault credentials, Skills, initial files and environment setup | Nothing. Keep it with the database; `oac apply` refuses a changed file |
 | `secrets/database.password` | PostgreSQL password | Nothing. PostgreSQL reads it only when the database is created; `oac apply` refuses a changed file |
-| `state.json` | Installation ID, Compose project, image IDs, source commit and the digests of generated files | The tools only |
+| `generated/` | Files derived from `config.json` | `oac apply` |
+| `node-payload/` | The node installer and node files that Web serves at `/node-install/`, one directory per release | The installer |
+| `native-installers/` | Self-hosted daemon installers for each platform, with their catalog, when the bundle carries them | The installer |
+| `state/e2b/` | Private E2B receipts | Core |
+| `ingress/` | Managed HTTPS: certificates and gateway state, domain setup status and the control sockets | The `gateway` and `installation` services |
+| `native/` | Core binaries, with native Core | The installer |
+| `.oac.lock` | The installation lock | The installer and mutating `oac` commands |
+
+A Web-only installation has only `secrets/core.key`, a copy of its Core's key, and no `state/` or `native-installers/`. A Core-only installation has no `node-payload/`. Only managed ingress has `ingress/`. With native Core, the installation directory and the bundle must be canonical absolute paths without control characters, quotes, backslashes or wildcards.
 
-A Web-only installation has only `secrets/core.key`, a copy of its Core's key.
+In Docker, the Compose project is named `oac-<10 hex digits>` (`project` in `state.json`). Its services are `database`, `migrate`, `core` and `web`, plus `gateway` and `installation` with managed ingress. `gateway` publishes `ports.web`, 80 and 443 and routes to Core and Web; `installation` applies domain changes from Web and uses the Docker socket to do so. The volume `<project>_database` holds all data. Native Core runs Core as the systemd user unit `<project>-core.service` instead of a container. Apart from Docker's storage, nothing is written outside your home directory.
 
 ## Appendix: Core environment without the installer
 
-Core reads only its environment. The installer renders `generated/core.env` from
-`config.json`; if you run Core yourself (see
-[Maintainers and advanced deployments](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/maintainers.md)), set these variables. Compose
-loads the file with `env_file` and systemd with `EnvironmentFile`, so Compose must be
-2.26.0 or newer.
+Core reads only its environment. The installer renders `generated/core.env` from `config.json`; if you run Core yourself (see [Maintainers and advanced deployments](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/maintainers.md)), set these variables. Compose loads the file with `env_file` and systemd with `EnvironmentFile`, so Compose must be 2.26.0 or newer.
 
 | Variable | Set from |
 | --- | --- |
-| `OAC_PUBLIC_URL` | `public_url`, or Core's loopback origin. Core derives the daemon WebSocket URL, the self-hosted `remote_url`, the hosted sandbox address and the deployment's read-only `core_url` from it. Required with `OAC_INSTALLATION_ID` |
-| `OAC_ADDR` | `ports.core` (native Core) or the container port |
+| `OAC_PUBLIC_URL` | `public_url`, or Core's loopback origin. Core derives the daemon WebSocket URL, the self-hosted `remote_url`, the hosted sandbox address and the deployment's read-only `core_url` from it, never from request headers. Without it, Core runs no Runtime gateway and executes no Sessions |
+| `OAC_ADDR` | `ports.core` (native Core) or `:8091` in the container |
 | `OAC_DATABASE_URL` | The installation's PostgreSQL without a password, plus `core.database_pool` as `pool_*` query parameters |
 | `OAC_DATABASE_PASSWORD_FILE` | `secrets/database.password`. The URL must then carry no password; migrations and the maintenance commands read the file too |
 | `OAC_CREDENTIAL_KEY_FILE` | `secrets/credential.key` |
 | `OAC_CORE_KEY_DIGESTS_FILE` | `generated/core-key-digests.json`: a JSON array with the SHA-256 of the Core key |
-| `OAC_INSTALLATION_ID` | `state.json`; pinned to the database |
+| `OAC_INSTALLATION_ID` | The installation ID from `state.json`, a canonical UUID. It enables the sandbox deployment and node routes and requires `OAC_PUBLIC_URL` and `OAC_CORE_KEY_DIGESTS_FILE`. Core refuses an ID other than the one its database recorded, so keep the two together |
 | `OAC_SETTINGS_FILE` | `generated/settings.json`, the snapshot Core serves at `GET /core/v1/installation`; Core does not act on it |
 | `OAC_EXECUTION_CONCURRENCY`, `OAC_DEFAULT_HARNESS`, `OAC_HARNESSES`, `OAC_WRITE_AUDIT_RETENTION`, `OAC_OAUTH_TRUSTED_ORIGINS` | The matching `core.*` settings |
-| `OAC_HISTORY_SETTINGS_FILE` | `generated/runtime-history.json` when `core.runtime_history` is set; see the [history contract](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/runtime-history-api.md) |
+| `OAC_HISTORY_SETTINGS_FILE` | `generated/runtime-history.json`: the [`core.runtime_history`](#settings) object, when it is set |
 | `OAC_LOG_LEVEL`, `OAC_LOG_FORMAT`, `OAC_LOG_ADD_SOURCE` | `log.*`; Web reads the same three |
-| `OAC_E2B_STATE_DIR`, `OAC_E2B_PROVIDER_BIN` | The E2B receipt directory and, for native Core, the bundled helper. The E2B key and template live in the database |
-
-A Web you run without the installer reads the variables in
-[Connecting the administrator console to Core](/bootstrap-projects-keys#server-configuration-and-login),
-plus `OAC_WEB_NODE_PAYLOAD_DIR`: the absolute path of the matched distribution's
-node payload (the installer's `node-payload/`). Without it, Add node is
-unavailable. Native self-hosted installation uses its separate platform bundle.
-
-Core fails at startup, naming the replacement, while a retired variable is set:
-`AGENTS_API_DAEMON_WS_URL` (use `OAC_PUBLIC_URL`), `AGENTS_API_CONFIG_FILE` (no
-replacement), `AGENTS_API_EXECUTION_OPTIONS_FILE` (use
-[default models](#default-models)), `AGENTS_API_SANDBOX_ADMIN_DIGESTS_FILE` (use
-`OAC_CORE_KEY_DIGESTS_FILE`), and `AGENTS_API_MANAGED_RUNTIMES_FILE`,
-`AGENTS_API_SANDBOX_NODE_STATE_DIR` and `AGENTS_API_SANDBOX_NODE_CORE_URL` (the
-sandbox deployment lives in the database and nodes enroll separately). Core logs the
-file paths it loads, never environment values or file contents. Native installation
-paths must be canonical absolute paths without control characters, quotes, backslashes
-or wildcards. Keep the installation ID and the database together; Core refuses a
-missing installation ID when its database already has a deployment.
-
-### Native daemon distributions
-
-Release Core images include matched self-hosted installers. A standalone Core
-process can set `OAC_NATIVE_INSTALLER_DIR` to the release's `native-installers`
-directory. Core checks the catalog's source revision, Runtime protocol and archive
-checksums before serving it. This setting supplies installation artifacts only;
-it does not change Runtime preparation, permissions or execution.
+| `OAC_E2B_STATE_DIR` | `state/e2b/`: an absolute directory owned by Core's user, with no group or other access. Back it up with the database and `credential.key`; don't mount it into Web or a Runtime |
+| `OAC_E2B_PROVIDER_BIN` | The E2B helper: `/opt/oac/e2b/oac-e2b-provider` in the Core image, `native/e2b/oac-e2b-provider` for native Core. The E2B key and template live in the database |
+| `OAC_NATIVE_INSTALLER_DIR` | `native-installers/`, served to self-hosted machines; the Core image has a copy at `/opt/oac/native-installers`, used when this is unset. Core checks the catalog against its own release before serving it |
+
+Core logs the file paths it loads, never environment values or file contents.
+
+A Web you run without the installer reads the variables in [Connecting the administrator console to Core](/bootstrap-projects-keys#server-configuration-and-login), plus `OAC_WEB_NODE_PAYLOAD_DIR`: the absolute path of the matched distribution's node payload (the installer's `node-payload/`). Without it, Add node is unavailable.
 
 [Repository source](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/configuration.md)
diff --git a/apps/docs/content/docs/environments-and-files.mdx b/apps/docs/content/docs/environments-and-files.mdx
index 9325b68f9..47f18b741 100644
--- a/apps/docs/content/docs/environments-and-files.mdx
+++ b/apps/docs/content/docs/environments-and-files.mdx
@@ -11,7 +11,7 @@ Session may instead select its exact canonical physical directory. The
 [recorded deployment qualification](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/user-managed-runtime-v1.md) retains its historical
 source, paths and tested capability scope.
 For hosted compute, the deployment selects E2B, Docker or microsandbox through
-[Hosted Sandbox Manager](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md).
+[sandbox deployment](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md).
 For the separate caller-managed E2B path, the user owns allocation, renewal and
 cleanup through the official SDK and [Runtime packaging](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/deploy/e2b/README.md).
 [Templates](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/environment-templates.md) provide reusable preparation; the Core extension also applies their execution configuration to user-managed machines;
diff --git a/apps/docs/content/docs/hosted-providers.mdx b/apps/docs/content/docs/hosted-providers.mdx
index 5ffe56091..5b52c7152 100644
--- a/apps/docs/content/docs/hosted-providers.mdx
+++ b/apps/docs/content/docs/hosted-providers.mdx
@@ -3,87 +3,31 @@ title: "Nodes and hosted providers"
 description: "Add and remove Docker or microsandbox nodes; diagnose connection and readiness."
 ---
 
-A node is a Linux machine that runs sandboxes for Core-hosted Sessions when the
-sandbox backend is Docker or microsandbox. Core places each new Session on a node with
-free capacity; the node creates the sandbox, and the sandbox connects back to Core.
-With E2B you need no nodes. Self-hosted executors, which applications run for their
-own Sessions, are a different thing; see [Self-hosted executors](/self-hosted-execution).
+A node is a Linux host that runs sandboxes for Core-hosted Sessions when the sandbox backend is Docker or microsandbox. Core places each new Session on a node with free capacity; the node creates the sandbox, and the sandbox connects back to Core. E2B needs no nodes. Machines that applications connect for their own Sessions are [self-hosted executors](/self-hosted-execution), not nodes.
 
-You add a node by generating a command in Web and pasting it on the host. The
-[operator reference](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md) covers the
-node protocol, manual registration, placement and failure handling.
+You add a node by generating a command in Web and running it on the host. The [sandbox deployment contract](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md) defines the sandbox settings and their change rules, and the [node protocol](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/node-generation-protocol.md) defines how nodes prepare and keep Runtime generations.
 
 ## Before you add a node
 
-- **Core has an HTTPS public URL** that the host and its sandboxes can reach: each
-  sandbox calls Core at `public_url`. A loopback installation can't have nodes, and
-  Web says so at Add node. See
-  [HTTPS and the reverse proxy](/install#https-and-the-reverse-proxy).
-- **Nodes can download their execution files.** Web supplies the release metadata.
-  With the default online installation, nodes follow HTTPS redirects to download
-  their matching Runtime and provider files directly from the release, verifying
-  sizes and SHA-256 checksums before use. Core and Web do not download these files.
-  For nodes without release access, use the [offline bundle](/install#installer-options)
-  on the Web host so it serves the files locally. Verified local files are reused.
-- **A sandbox backend is chosen.** The installer selects microsandbox unless you chose
-  otherwise. After `--sandbox none`, the **Nodes** page first asks you to choose
-  **Own machines**, then microsandbox (preselected as recommended) or Docker, which it
-  asks you to confirm, and a sandbox size, then **Save configuration**. Every node of a
-  deployment uses that provider.
+- **Core has an HTTPS public URL** that the host and its sandboxes can reach. Nodes download from Core's console and connect to Core at `public_url`. Until it is set, Add node says *Configure a domain and HTTPS in System before adding nodes*; see [Configure the domain and HTTPS](/install#configure-the-domain-and-https), or with external ingress [change the public URL](/configure#changing-the-public-url).
+- **The sandbox configuration is saved.** The installer saves microsandbox at the Standard size unless you passed another `--sandbox`. After `--sandbox none`, open **System** → **Manage sandbox configuration**, choose **Own machines**, then microsandbox (recommended) or Docker and a sandbox size, and **Save configuration**. Every node of an installation uses that backend.
+- **The console can serve the node files.** Nodes download their Runtime and provider files from the console, which redirects to the release for files it does not hold, and check each file's size and SHA-256 against the release manifest. For hosts without access to the release, install Core from the [offline bundle](/install-options#offline-hosts) so the console holds every file. Without the files, Add node says *This console has no node files for …*.
+
+The Core host joins like any other host: to run sandboxes on it, add it as a node.
 
 ## Add a node
 
-1. In Web, open **Nodes** and select **Add node**.
-2. Set **Sandboxes at once** (default 2): how many sandboxes Core may run on this node.
-   With microsandbox, also set **Retained sandboxes** (default 8): how many it may keep,
-   suspended ones included. With Docker, Core keeps retained equal to at once. You can
-   change them later with **Edit node**.
-3. Select **Generate command** and copy the command. It registers one node, once, and
-   only if it runs within 10 minutes; Web counts down and offers
-   **Generate new command** when it expires.
+1. In Web, open **Nodes** and choose **Add node**.
+2. Set **Sandboxes at once** and, with microsandbox, **Retained sandboxes**: the node's [capacity](/configure#node-capacity). You can change them later with **Edit node**.
+3. Choose **Generate command** and copy the command. It registers one node, once, and only if it runs within 10 minutes; Web counts down and offers **Generate new command** when it expires.
 4. Run it on the host. Web follows the node from registered to connected to ready.
 
-The command downloads the node installer from your console, checks its SHA-256, and
-runs it with a one-time enrollment token. The installer downloads the node files from
-the same console and checks each against the release manifest, imports the Runtime
-image, registers the node, starts its service and waits until Core reports the node
-connected and ready. It never installs software, and it stops with a one-line hint
-before changing anything when a prerequisite is missing.
-
-Node installation and removal require root. Web's command uses `sudo` unless the
-shell is already root. The installer creates an `oac-node` service user and a
-system service; the node runs as that service user, not as root. Direct execution
-as an ordinary user is rejected before reading the enrollment token or changing
-the host. This requirement applies to Sandbox Provider nodes, not the native
-self-hosted daemon installer.
-
-### Download through a proxy
-
-Export standard `http_proxy` / `https_proxy` and `no_proxy` variables before
-running the generated command. Uppercase `HTTP_PROXY`, `HTTPS_PROXY` and
-`NO_PROXY` work too; lowercase takes precedence when both are set (including an
-empty lowercase value). Use an HTTP proxy URL, optionally with URL-encoded
-credentials, and comma-separated host exclusions in `no_proxy`. A proxy for
-HTTPS downloads must support CONNECT.
-
-The command requests sudo preservation of only these six names and keeps them
-when dropping to `oac-node`. If sudo policy denies preservation, ask the host
-administrator to permit those names or run from a root shell with the variables
-exported there. A manually added outer `sudo` can discard them before the
-command starts. Do not put credentials in command arguments or share shell traces.
+The command downloads the node installer from your console, checks its SHA-256 and runs it with a one-time enrollment token. The installer downloads the node files and checks each against the release manifest, imports the Runtime image, registers the node, starts its service and waits until Core reports the node connected and ready. It never installs software, and it stops with a one-line hint before changing anything when a prerequisite is missing.
 
-These settings apply only to installation requests. They are not saved in node
-configuration or the systemd unit; the running node still needs its own network
-access to Core. Without proxy variables, downloads use the existing direct path.
+Node installation and removal require root. Web's command uses `sudo` unless the shell is already root. The installer creates an `oac-node` service user and a system service; the node runs as that user, not as root. Running the installer as an ordinary user fails before it reads the enrollment token or changes the host.
 
 ### The command
 
-The command shows each installation phase as it runs. After Core confirms the
-connection and the Sandbox Provider is ready, it prints a grouped summary with
-status and log commands. Terminal colors are optional (`export NO_COLOR=1` disables them; the generated
-command passes this preference through sudo with `--no-color`);
-redirected output stays plain. Registration tokens are never printed.
-
 This is the command Web generates, with this installation's values:
 
 ```sh
@@ -95,29 +39,29 @@ printf '%s  %s\n' '<installer-sha256>' "$d/node-install.pyz" | sha256sum -c --st
 printf '%s\n' '<enrollment-token>' | $s python3 "$d/node-install.pyz" ${NO_COLOR+--no-color} --enrollment-token-stdin --source-url 'https://core.example' --core-url 'https://core.example' --provider 'docker' --installation-id '<installation-id>')
 ```
 
-- It downloads the installer into a private temporary directory, checks its SHA-256,
-  and runs it with `sudo`, or directly in a root shell.
-- The token reaches the installer on standard input, so it never appears in a process
-  argument, an environment variable or sudo's log.
-- The leading space keeps the command out of the shell history where `HISTCONTROL`
-  ignores such lines (the Debian and Ubuntu default).
-- If the command is interrupted or the download stalls, run the same command again:
-  the download resumes.
+- It downloads the installer into a private temporary directory, checks its SHA-256, and runs it with `sudo`, or directly in a root shell.
+- The token reaches the installer on standard input, so it never appears in a process argument, an environment variable or sudo's log.
+- The leading space keeps the command out of the shell history where `HISTCONTROL` ignores such lines (the Debian and Ubuntu default).
+
+The installer shows each phase as it runs and, once Core confirms the node, a summary with status and log commands. `export NO_COLOR=1` disables colors; the command passes this through sudo as `--no-color`. It never prints tokens.
 
-The host needs:
+### Host requirements
 
 - Linux amd64 with systemd; Python 3.9+, `curl` and `sha256sum`; root or sudo.
-- SELinux not enforcing. Hosts with enforcing SELinux are unsupported by this installer.
-- One Core per host: a host already running a sudo-mode node for another Core is
-  refused.
-- Docker: rootful Docker Engine running, its socket `/var/run/docker.sock` owned by the
-  `docker` group with mode `0660`, enforcing CPU and memory limits (cgroup v2).
-- microsandbox: `/dev/kvm` in the `kvm` group (hardware or nested virtualization), and
-  the libraries microsandbox links (glibc).
-- CPUs and memory for at least one sandbox of the deployment's size, and about 2 GB of
-  disk for the Runtime image.
+- SELinux not enforcing. The installer does not support hosts with enforcing SELinux.
+- Docker: rootful Docker Engine running, its socket `/var/run/docker.sock` owned by the `docker` group with mode `0660`, enforcing CPU and memory limits (cgroup v2).
+- microsandbox: `/dev/kvm` in the `kvm` group (hardware or nested virtualization), and the libraries microsandbox links (glibc).
+- CPUs and memory for at least one sandbox of the installation's size, and about 2 GB of disk for the Runtime image.
 - HTTPS access to the console and Core at the public URL; sandboxes reach Core too.
 
+### Download through a proxy
+
+Export `http_proxy`, `https_proxy` and `no_proxy` before running the generated command. Uppercase `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` work too; lowercase takes precedence when both are set, even when empty. Use an HTTP proxy URL, optionally with URL-encoded credentials, and comma-separated host exclusions in `no_proxy`. A proxy for HTTPS downloads must support CONNECT.
+
+The command asks sudo to preserve only these six names, and the installer keeps them when it drops to `oac-node`. If sudo policy refuses, ask the host administrator to permit those names, or run from a root shell with the variables exported there. An outer `sudo` you add yourself can discard them. Don't put credentials in command arguments or share shell traces.
+
+The proxy applies only to installation downloads. It is not saved in the node's configuration or service, so the running node needs its own network access to Core.
+
 ## What the installer sets up
 
 | Item | Detail |
@@ -128,65 +72,45 @@ The host needs:
 | Node state | `/var/lib/oac-node/.oac/nodes/<installation-id>/`: identity, configuration, node files. microsandbox keeps its images and sandboxes under `/var/lib/oac-node/.oac/m/` |
 | Records | `/etc/oac-node/`: what the installer created or changed, used by reruns and uninstall |
 | Docker | The Runtime image, imported once, and a network `oac-node-<installation-id>` |
+| microsandbox network policy | Sandboxes may reach Core, DNS on the host and public addresses, and nothing else: no inbound connections and no private networks. A private model or MCP endpoint needs a policy change on the node |
+
+Root only prepares the account, the group and the unit; everything else, the Docker network included, runs as `oac-node`, in its own session without a terminal. The installer never installs Docker, KVM or packages, never starts Docker, never changes device permissions, sudoers, firewall or SELinux settings, and never touches other accounts.
 
-Root only prepares the account, the group and the unit; everything else, the Docker
-network included, runs as `oac-node`, in its own session without a terminal. The
-installer never installs Docker, KVM or packages, never starts Docker, never changes
-device permissions, sudoers, firewall or SELinux settings, and never touches other
-accounts.
+**Docker mode is root-equivalent.** Membership in the `docker` group lets `oac-node`, and so anything that controls the node, act as root on the host. Containers also share the host kernel, so a container escape reaches the host. Add Docker nodes only on hosts dedicated to sandboxes. microsandbox nodes need only the `kvm` group and run each sandbox in its own microVM.
 
-**Docker mode is root-equivalent.** Membership in the `docker` group lets
-`oac-node`, and so anything that controls the node, act as root on the host. This
-is inherent to running sandboxes on Docker. Add Docker
-nodes only on hosts dedicated to sandboxes. microsandbox nodes need only the `kvm`
-group.
+**One Core per host.** Nodes share the `oac-node` account, so a host serves one Core; a command from a second Core is refused.
 
-**One Core per host.** Nodes share the `oac-node` account, so a host serves one
-Core; a command from a second Core is refused.
+**One release.** A node runs the program of the console that added it and is never upgraded in place; see the [installation version policy](/troubleshooting#installation-version-policy).
 
-**The token.** It is single-use, expires after 10 minutes and only registers the node.
-The installer takes it only on standard input and refuses it in the environment,
-where `sudo VAR=… python3` would record it in sudo's log. A sudoers policy with
-`log_input` records standard input, and so the token.
+**The token.** It is single-use, expires after 10 minutes and only registers the node. The installer takes it only on standard input and refuses it in the environment, where `sudo VAR=… python3` would record it in sudo's log. A sudoers policy with `log_input` records standard input, and so the token.
 
 ## Rerun, expiry and slow links
 
-- Rerunning the same command is safe. Once the node is registered, a rerun uses the
-  node's own credential, changes nothing that already matches and needs no token.
-- A command that already expired, or was used on another host, fails at once with
-  `Core rejected the node configuration read (HTTP 401)`: generate a new command and
-  run it within 10 minutes.
-- If the command expires during a slow download, registration fails with
-  `The enrollment command expired or was already used`. The downloaded files are kept:
-  generate a new command in Web and run it.
-- Downloads resume where they stopped. A download that brings less than 64 KiB in a
-  minute stops, keeping what it has; run the command again.
-- The Docker Runtime image is about 500 MB. On a slow link, load it first: copy the
-  release's `oac-<commit>-linux-amd64-runtime.tar.gz` asset to the host and run
-  `sudo docker load -i` on it. The installer then finds the exact image and skips the
-  download.
-- Interrupting the installer, or closing its terminal, stops it; run the command again
-  to continue.
+- Rerunning the same command is safe. Once the node is registered, a rerun uses the node's own credential, changes nothing that already matches and needs no token. It refuses, without changing anything, when the node's retained identity belongs to another Core address or installation.
+- A command that already expired, or was used on another host, fails at once with `Core rejected the node configuration read (HTTP 401)`: generate a new command and run it within 10 minutes.
+- If the command expires during a slow download, registration fails with `The enrollment command expired or was already used`. The downloaded files are kept: generate a new command in Web and run it.
+- Downloads resume where they stopped. A download that brings less than 64 KiB in a minute stops, keeping what it has; run the command again.
+- The Docker Runtime image is about 500 MB. On a slow link, load it first: copy the release's `oac-<commit>-linux-amd64-runtime.tar.gz` asset to the host and run `sudo docker load -i` on it. The installer then finds the exact image and skips the download.
+- Interrupting the installer, or closing its terminal, stops it; run the command again to continue.
 
 ## Logs
 
-The installer prints the node's log command (`Logs: …`) when it finishes. The Add node
-dialog shows it too when something needs attention: when the node reports a problem, or
-when it hasn't become connected and ready about a minute after registering.
+The installer prints the node's log command (`Logs: …`) when it finishes. The Add node dialog shows it too when something needs attention: when the node reports a problem, or when it hasn't become connected and ready about a minute after registering.
+
+Run `sudo journalctl -u oac-node-<installation-id>.service`. In a root shell, omit `sudo`. The installation ID is in the command (`--installation-id`) and on the **System** page.
+
+## Change the sandbox configuration
 
-Run `sudo journalctl -u oac-node-<installation-id>.service`. In a root shell, omit
-`sudo`; the installer's summary already does this.
+Sandbox settings apply to the whole installation; nodes follow them.
 
-The installation ID is in the command (`--installation-id`) and on the **System** page.
+- **Size, Runtime release, E2B key or template build.** Open **System** → **Manage sandbox configuration** → **Change resources**, edit and save. Existing sandboxes keep their configuration. Each node prepares the new one while it keeps serving the old one, and **Nodes** shows its progress: **Preparing target**, **Ready for target** or **Preparation failed** with the [reason](#readiness-codes). Core places new Sessions on nodes ready for the new configuration first, and on nodes still serving an older one when those have no room. E2B changes apply at once.
+- **Backend.** On the same page, choose **Reset deployment**. Auto reset archives idle hosted Sessions at once and lets running work finish until the deadline you set; force cancels it now. Offline nodes must come back so Core can confirm their cleanup. When the reset completes, Core has retired every node and unused command: set up the new backend, then add nodes again. **Cancel reset** stops the remaining work; archived Sessions stay archived.
+
+The [reset contract](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md#generation-ownership-and-rollout) describes what reset archives and keeps. To archive a single hosted Session, use the [Core API](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/admin-api.md#administrative-session-archive).
 
 ## Remove a node
 
-1. In Web, open **Nodes** and choose **Remove node** on the node's page, or
-   **Remove** in its list row, then **Confirm removal**. Core refuses while the node
-   still holds sandboxes, snapshots or pending cleanup; let them finish, or
-   [archive their Sessions](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md#removal-and-reset)
-   through the Core API. Removal is permanent: the host can come back only as a new
-   node.
+1. In Web, open **Nodes** and choose **Remove node** on the node's page, or **Remove** in its list row, then **Confirm removal**. Core refuses while the node still holds sandboxes, snapshots or pending cleanup; let them finish, or archive their Sessions. Removal is permanent: the host can come back only as a new node. Removing every node keeps the sandbox configuration.
 2. Web then shows **Clean up the host** with the uninstall command. Run it on the host:
 
    ```sh
@@ -198,49 +122,67 @@ The installation ID is in the command (`--installation-id`) and on the **System*
    $s python3 "$d/node-install.pyz" ${NO_COLOR+--no-color} --uninstall --installation-id '<installation-id>')
    ```
 
-Uninstall first asks Core, at the address the node enrolled with, whether the node was
-removed, and refuses while Core still lists it. When the node enrolled with an address
-other than the current public URL, the dialog also shows **Old Core address gone?**:
-if that address no longer responds, it gives the command with `--force`, which skips
-the check; remove the node on the Nodes page first. Without the dialog, take the
-installer's SHA-256 from the `node-install.pyz` line of
-`https://core.example/node-install/SHA256SUMS`. Uninstall
-stops and removes the service, the node state, the records and the Docker network. It
-deletes the `oac-node` account only if the installer created it and no node remains;
-an adopted account only loses the groups the installer added.
-
-It never deletes sandboxes, volumes or images. It keeps the Runtime image and prints
-the `docker image rm` command. For microsandbox it keeps the store under
-`/var/lib/oac-node/.oac/m/`, prints how to delete it
-(`sudo -u oac-node rm -rf <store>`), and keeps a created account until the store is
-gone; rerun uninstall afterwards. With `--force`, microVMs may still use the store, so
-check `pgrep -u oac-node` first. Uninstall can be rerun until it completes.
+Uninstall first asks Core, at the address the node enrolled with, whether the node was removed, and refuses while Core still lists it. When the node enrolled with an address other than the current public URL, the dialog also shows **Old Core address gone?**: if that address no longer responds, it gives the command with `--force`, which skips the check; remove the node on the Nodes page first. Without the dialog, take the installer's SHA-256 from the `node-install.pyz` line of `https://core.example/node-install/SHA256SUMS`. Uninstall stops and removes the service, the node state, the records and the Docker network. It deletes the `oac-node` account only if the installer created it and no node remains; an adopted account only loses the groups the installer added.
+
+It never deletes sandboxes, volumes or images. It keeps the Runtime image and prints the `docker image rm` command. For microsandbox it keeps the store under `/var/lib/oac-node/.oac/m/`, prints how to delete it (`sudo -u oac-node rm -rf <store>`), and keeps a created account until the store is gone; rerun uninstall afterwards. With `--force`, microVMs may still use the store, so check `pgrep -u oac-node` first. Uninstall can be rerun until it completes.
+
+## Register a node manually
+
+Use manual registration when you manage the node's files and service yourself instead of running Web's command. A manually registered node serves only the configuration it registered with: after a size or Runtime change, **Nodes** shows it as **Node software incompatible**, and it keeps serving the old configuration until you remove it and register the host again.
+
+1. Take `oac-node` from the same release as Core.
+2. Get an enrollment token: the token in a command from **Add node**, or `POST /core/v1/sandbox/enrollment-tokens` with the Core key. It is single-use and carries the node's approved capacity; the response's `expires_at` says when it expires. Save it in a `0600` file on the host.
+3. Read the node configuration with the token, which does not consume it: `GET /api/v1/sandbox-node/configuration` with `Authorization: Bearer <token>`.
+4. Write a private provider file. Copy `provider`, `installation_id`, `core_url`, `generation` and `specification` from the response, and add one adapter object for the host:
+   - `docker`: `host` (an explicit Unix socket), `image` (the locally imported Runtime image of the approved release), `network`, `extra_hosts`, an absolute `seccomp_file` and `nested_sandbox`.
+   - `microsandbox`: absolute `helper_path`, `runtime_path` and `firmware_path` with their `runtime_sha256` and `firmware_sha256`, `image`, the sandbox `cpus`, `memory_mib`, `root_disk_mib` and `environment_disk_mib`, a `network` policy, and `runtime_home`: a private directory, which the helper creates with mode `0700` when it is missing. microsandbox places Unix sockets under it, so keep its path within 48 bytes; the installer refuses a longer one for its own nodes.
+5. Register, then run the node under the host's service supervisor, with real absolute paths:
+
+   ```sh
+   oac-node register \
+     --config /var/lib/oac/provider.json \
+     --state-dir /var/lib/oac/node \
+     --core-url https://core.example \
+     --name worker-1 \
+     --enrollment-token-file /var/lib/oac/enrollment-token
+   oac-node run \
+     --config /var/lib/oac/provider.json \
+     --state-dir /var/lib/oac/node
+   ```
+
+`oac-node run` exits with status 78 once Core rejects its credential, after the node is removed; configure the supervisor not to restart it then (systemd: `RestartPreventExitStatus=78`).
+
+The node connects out to Core; Core needs no SSH or Docker TCP access to the host. Registration writes the node's identity to the state directory before contacting Core, so a lost response can be retried under the same identity. Keep the state directory on persistent storage, private to the node's account and used by one process at a time. Never copy it to another directory or host: Core refuses a second connection for a node while the first is open. The provider file can't change the node's capacity or sandbox configuration. Core compares its digest at registration and on every connection, and a node whose file differs takes no work until the approved configuration is restored.
+
+## When a node host fails
+
+A restarted node service keeps its identity and finds its existing sandboxes again. Core never replaces a missing sandbox by itself, and never moves a Session to another node: the Session's resources show as **Node disconnected** or **Sandbox resource missing** until the original host and its storage are back, or you archive the Session. A lost node state directory is a recovery incident: restore it from its [backup](/troubleshooting#back-up) together with the database and the provider storage, rather than registering the host again over existing resources.
 
 ## Troubleshooting
 
 ### Readiness codes
 
-When a node is online but its provider is not ready, **Nodes** shows its status as
-**Provider unavailable**, with the reason in a help tip; **Overview** counts it as a
-**Provider issue**. The API reports the reason as a fixed code, the `diagnostic` field
-of `GET /core/v1/sandbox/nodes`. A node reports only its first failed check, and the
-next heartbeat, about ten seconds after a fix, clears or replaces it. The node's log has
-the local error behind the code.
+When a node is online but its sandbox provider is not ready, **Nodes** and **Overview** show it as **Provider not ready**. Where the reason appears depends on how the node was added:
+
+- **Nodes added with Web's command** report a failed check of the current sandbox configuration as **Preparation failed** in the node's target status, with the reason in a help tip (`rollout.diagnostic` in `GET /core/v1/sandbox/nodes`). The tip beside **Provider not ready** only says *Sandbox provider unavailable*.
+- **Manually registered nodes** show the reason in the help tip beside **Provider not ready** (`diagnostic`).
+
+The node's log has the local error behind the code.
 
-| Code | Web shows | Cause | Fix |
+A node reports only its first failed check, in this order: the Docker daemon or KVM, Docker's limit support, host capacity, then the installed Runtime files. An unreachable Docker daemon therefore hides a missing image. The next heartbeat, about ten seconds after a fix, clears or replaces the code. An offline node keeps its last code, which Web hides until the node reconnects.
+
+| Code | Help tip | Cause | Fix |
 | --- | --- | --- | --- |
 | `docker_unavailable` | Docker unavailable | The Docker socket is unreachable or not accessible, or Docker fails its info or image request | Start Docker and give the node's user access to `/var/run/docker.sock` |
 | `docker_limits_unsupported` | Docker limits unsupported | Docker reports no CPU quota or memory limit support | Use a host whose cgroups enforce CPU and memory limits (cgroup v2) |
-| `runtime_image_unavailable` | Runtime image missing | Docker does not have the pinned Runtime image | Rerun the add command, or load the image from the matching release |
-| `kvm_unavailable` | KVM unavailable | The node can't open `/dev/kvm` for reading and writing | Enable hardware virtualization and give the node's user KVM access, through the `kvm` group |
-| `microsandbox_artifacts_unavailable` | microsandbox components missing | The Runtime or firmware is missing or fails its SHA-256 check, or the helper is missing | Rerun the add command |
 | `capacity_insufficient` | Host too small | The host has fewer CPUs or less memory than one sandbox | Use a larger host, or change the sandbox size |
-| `provider_unavailable` | Sandbox provider unavailable | Any other failure, and every failure an older node reports | Read the node's log |
+| `runtime_image_unavailable` | Runtime image missing | Docker does not have the pinned Runtime image | A node added with Web's command downloads it again by itself; otherwise load the image from the matching release |
+| `kvm_unavailable` | KVM unavailable | The node can't open `/dev/kvm` for reading and writing | Enable hardware virtualization and give the node's user KVM access, through the `kvm` group |
+| `microsandbox_artifacts_unavailable` | microsandbox components missing | The Runtime or firmware is missing or fails its SHA-256 check, or the helper is missing | A node added with Web's command downloads the missing files by itself; otherwise restore them from the matching release |
+| `runtime_download_failed` | Runtime download failed | While preparing a new configuration, the node could not download or verify the Runtime files | Check the node's HTTPS access to the console and the release. The node retries with growing delays, up to 30 minutes apart |
+| `provider_unavailable` | Sandbox provider unavailable | Any other failure | Read the node's log |
 
-A new group membership applies only to a new process. Restart the node service:
-`sudo systemctl restart oac-node-<installation-id>.service`. A node that is registered
-but never connects usually can't reach Core at the public URL, or its `/api/v1`
-WebSocket doesn't pass the reverse proxy.
+A new group membership applies only to a new process. Restart the node service: `sudo systemctl restart oac-node-<installation-id>.service`. A node that is registered but never connects usually can't reach Core at the public URL, or its `/api/v1` WebSocket doesn't pass the reverse proxy.
 
 ### Installer messages
 
@@ -254,43 +196,9 @@ WebSocket doesn't pass the reverse proxy.
 | KVM is unavailable, or `/dev/kvm` must be group-accessible | Enable virtualization; your distribution's KVM package sets `root:kvm 0660` |
 | This host has N CPUs and M MiB of memory; each sandbox needs … | Use a larger host, or change the sandbox size |
 | SELinux is enforcing on this host | Use a host supported by the installer; it does not change SELinux settings |
-| This host already runs a sudo-mode node for another Core | One host serves one Core in sudo mode. Remove that node and uninstall it first |
+| This host already runs a sudo-mode node for another Core | Remove that node and uninstall it first |
 | Node installation and removal require root | Run Web's command with sudo, or from a root shell |
 | Core still lists this node | Remove it on the Nodes page first |
-
-## Change the sandbox backend or size
-
-Change the backend or sandbox size in Web under **System** → **Sandbox backend**.
-What each change does, and when it needs a reset, is in
-[Sandbox deployment](/configure#sandbox-deployment). This section covers
-only what happens on the nodes.
-
-Node program version updates are not supported. `--update` refuses without changing
-node state. Preserve an older installation and its Runtime data; provision a fresh
-node separately through **Add node**. Current Runtime generation operations below
-are independent of program version upgrades.
-
-Fresh v2 preparation keeps a private recovery plan until the actual provider image
-identity is resolved and its final configuration is published. Restart does not
-serve a pending or partly collected generation. Generation lock identity is durable:
-if a lease or its identity record is missing or replaced, preserve the installation
-for inspection. Do not delete records, recreate lock files or re-enroll to bypass
-that refusal; a process restart does not prove that older helpers have stopped.
-
-Automatic Docker generation GC removes only installation-owned generation/release
-files. Shared daemon images remain; a host administrator may remove them only after
-confirming no installation still needs them. Microsandbox image cleanup remains
-scoped to the installation's private native store and verified ownership receipts.
-
-The [operator reference](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md#removal-and-reset)
-describes reset and API behavior. Same-team E2B edits have a separate online Core
-API path and do not involve node installation.
-
-
-## Installation scope
-
-Nodes and Core must come from the same distribution. Provision nodes through
-**Add node**; the installer never adopts or removes another installation's
-resources. See the [installation version policy](/troubleshooting#installation-version-policy).
+| Core no longer accepts this node | It was removed, or a reset retired it. Uninstall it, then add the host with a new command |
 
 [Repository source](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/getting-started/nodes.md)
diff --git a/apps/docs/content/docs/index.mdx b/apps/docs/content/docs/index.mdx
index 22db7d8f2..ad10cbf9d 100644
--- a/apps/docs/content/docs/index.mdx
+++ b/apps/docs/content/docs/index.mdx
@@ -3,40 +3,34 @@ title: "OpenAgentCore documentation"
 description: "Install Core and Web, create a Project API key, and add execution capacity."
 ---
 
-OpenAgentCore runs AI agents on your own infrastructure behind the OpenAI Agents
-API. Pick the path that matches your role. New here? Read the
-[architecture overview](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/architecture.md) first.
+OpenAgentCore runs AI agents on your own infrastructure behind the OpenAI Agents API. The [architecture overview](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/architecture.md) explains its parts. Pick the guides for your role.
 
-## Operators: install and run
+## Operators
 
-1. [Install Core and Web](/install) and sign in.
-2. Add execution capacity: [managed nodes or E2B](/hosted-providers), or
-   [your own machine](/self-hosted-execution).
-3. Issue a Project API key and hand it to the application developer.
+Operators install Core and Web, add sandbox capacity and issue Project API keys.
 
 | Guide | Covers |
 | --- | --- |
-| [Installation](/install) | Prerequisites, HTTPS, first sign-in, advanced options |
-| [Configuration](/configure) | `config.json`, default models, sandbox deployment |
-| [Nodes](/hosted-providers) | Adding, checking and removing managed nodes |
-| [Self-hosted execution](/self-hosted-execution) | Connecting your own machine to a Session |
-| [Operations](/troubleshooting) | Services, backups, keys, repair and troubleshooting |
+| [Install Core and Web](/install) | The default installation, from an empty host to the first Project API key |
+| [Installation options](/install-options) | Installer flags, existing reverse proxies, split and native deployments, offline hosts |
+| [Nodes](/hosted-providers) | Adding, changing, removing and troubleshooting sandbox nodes |
+| [Operations](/troubleshooting) | The `oac` command, the Core key, backups, upgrades and troubleshooting |
+| [Configuration reference](/configure) | Every setting, file and environment variable |
 | [Web console](/console) | What the console shows and manages |
 
-## Application developers: build on the API
+## Application developers
+
+Application developers call the API with a Project API key, and can run Sessions on machines they own.
 
 | Guide | Covers |
 | --- | --- |
 | [Quickstart](/quickstart) | From a Project API key to a finished Session |
 | [User guide](/user-guide) | Common tasks: harness and model choice, follow-ups, capabilities, files, cancel |
 | [Agents API guide](/sessions) | Every resource, with SDK and HTTP examples |
+| [Self-hosted execution](/self-hosted-execution) | Running a Session on your own machine |
 | [Examples](/examples) | Complete applications built on the API |
 | [API index](/public-api) | All three namespaces and their credentials |
 
-## Contributors: extend Core
-
-Start with the [developer guide](/development): repository map, local setup,
-and how to add a Sandbox Provider, a harness or a Runtime feature. Repository rules
-are in [CONTRIBUTING.md](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/CONTRIBUTING.md).
+Contributors start with the [developer guide](/development) and [CONTRIBUTING.md](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/CONTRIBUTING.md).
 
 [Repository source](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/getting-started/README.md)
diff --git a/apps/docs/content/docs/install-options.mdx b/apps/docs/content/docs/install-options.mdx
index 3b29c6d31..29db5c30f 100644
--- a/apps/docs/content/docs/install-options.mdx
+++ b/apps/docs/content/docs/install-options.mdx
@@ -1,24 +1,23 @@
 ---
-title: "Installation options"
-description: "Listener addresses, ports and initial installation choices."
+title: "Installation options and advanced deployments"
+description: "Installer flags, sandbox backends, listeners, reverse proxies, split and native deployments and offline hosts."
 ---
 
+The [default installation](/install) needs no options. Use this page to choose the sandbox backend at install time, run behind an existing reverse proxy, split Core and Web across hosts, run Core natively or install without internet access.
+
 Pass options to the downloaded script:
 
 ```sh
-./install.sh --host 127.0.0.1 --port 8088
+./install.sh --sandbox docker
 ```
 
-With the Quick start pipeline, append `-s --` and the options after `bash`.
-The release downloader also accepts `--version TAG` to select a published release;
-otherwise it selects the latest stable release.
+With the one-line command, append them after `bash -s --`. The release downloader also accepts `--version TAG` to select a published release; otherwise it selects the latest stable release. It verifies the bundle's SHA-256 before extracting it and keeps the verified bundle for [repair](/troubleshooting#installation-version-policy).
+
+The installer prints each stage, then a summary of addresses, sign-in details and next steps. Set `NO_COLOR=1` to disable colors. A failed step stops installation without a success message.
 
 ## Process settings
 
-These flags seed the installation's `config.json` once. Their defaults, valid values
-and restart behavior are defined in the [configuration reference](/configure#settings).
-After installation, edit that file and run `oac apply`; rerunning the installer
-repairs the same version and accepts only `--install-dir`.
+These flags seed the installation's `config.json` once. Their defaults, valid values and restart behavior are defined in the [configuration reference](/configure#settings). After installation, edit that file and run `oac apply`; rerunning the installer only [repairs](/troubleshooting#installation-version-policy) the installation.
 
 
 | Flag | config.json field |
@@ -33,40 +32,16 @@ repairs the same version and accepts only `--install-dir`.
 | `--ingress` | `ingress` |
 
 
-`--config FILE` seeds `config.json` from a JSON file instead of these setting flags;
-they cannot be combined. There is no precedence between two configuration sources.
-Generated Compose and environment files are derived outputs, not editable settings.
-
-## Listeners and access
-
-The default combined Docker installation selects `--ingress managed` and
-`--host 0.0.0.0`. The gateway publishes Web on `--port` (8080 by default), and
-reserves ports 80 and 443 for automatic HTTPS. Core's `--core-port` remains on
-loopback; PostgreSQL remains private. `--host` accepts IPv4 or IPv6, without a
-port, scheme or zone. Use a concrete server IP in the browser, not a wildcard.
-
-`--ingress external` keeps the existing proxy arrangement. It is the default for
-Core-only, Web-only and native Core; these modes do not support managed ingress.
-Their Core/Web listeners default to loopback. External non-loopback listeners
-require an HTTPS `public_url` and your own
-[reverse proxy configuration](/install#https-and-the-reverse-proxy).
-
-`--public-url` can seed a DNS-based HTTPS origin for unattended managed setup;
-certificate and connectivity checks must pass. Without it, open Web by IP first
-and use **System → Domain and HTTPS**. An explicit `--config` document follows the
-schema defaults; set `ingress: "managed"` and `host: "0.0.0.0"` to choose that flow.
-The ingress mode is fixed for an installation. Managed ingress needs a local
-Docker Unix socket and Docker's ability to publish ports 80 and 443.
+`--config FILE` seeds `config.json` from a JSON file instead of these setting flags; they cannot be combined. A `--config` document follows the schema defaults, so set `ingress: "managed"` and `host: "0.0.0.0"` in it for managed HTTPS.
 
 ## Installation actions
 
-These options choose an installation location or perform initial setup. They do not
-create another process configuration file.
+These options choose an installation location or perform initial setup; they are not saved in `config.json`.
 
 | Option | Purpose |
 | --- | --- |
 | `--install-dir DIR` | Absolute installation directory; defaults to `~/.oac/core`. A new installation requires an empty or missing directory |
-| `--sandbox docker\|microsandbox\|e2b\|none` | Select the initial [sandbox backend](/install#sandbox-backend), saved in Core's database; change it later in Web |
+| `--sandbox docker\|microsandbox\|e2b\|none` | Select the initial [sandbox backend](#sandbox-backend), saved in Core's database; change it later in Web |
 | `--accept-docker-risks` | Accept Docker's weaker isolation without an interactive prompt |
 | `--e2b-api-key-file FILE` | With E2B: absolute path to a private key file, no group/other access and at most 4 KiB |
 | `--e2b-template ID:BUILD` | With E2B: ready template build as `template-id:build-uuid` |
@@ -74,10 +49,261 @@ create another process configuration file.
 | `--e2b-domain DOMAIN` | With E2B: sandbox data-plane DNS suffix; use together with `--e2b-api-url` |
 | `--core-key-file FILE` | With Web-only: absolute path to a private file containing the existing Core key, at least 32 characters |
 
-See [deployment modes](/install#modes), [native Core](/install#native-core) and
-[sandbox setup](/install#sandbox-backend) for their prerequisites.
-Several installations can share a machine when they use distinct installation
-directories and ports. Only one managed gateway can own ports 80 and 443 on a
-particular IP; use distinct IPs or an external shared proxy for additional installations. Each has its own database, Core key and node registrations.
+Several installations can share a machine when they use distinct installation directories and ports. Only one managed gateway can own ports 80 and 443 on an IP address; use distinct IP addresses or an external shared proxy for more. Each installation has its own database, Core key and nodes.
+
+## Sandbox backend
+
+An installation runs its sandboxes on exactly one backend:
+
+| `--sandbox` | Sandboxes run on | You then |
+| --- | --- | --- |
+| `microsandbox` (default) | microVMs on your nodes, which need KVM | [Add nodes](/hosted-providers) in Web |
+| `docker` | Docker containers on your nodes; weaker isolation | [Add nodes](/hosted-providers) in Web |
+| `e2b` | E2B's cloud, sized by your template build | Nothing: E2B needs no nodes |
+| `none` | Nothing yet | Choose in Web under **System** → **Manage sandbox configuration** |
+
+Docker and microsandbox start at the Standard size in Web's [`standard-sizes.json`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/apps/web/src/features/sandbox/standard-sizes.json). If Core refuses the choice, for example because E2B rejects the key, the installer prints Core's message and exits; the services keep running and you choose the backend in Web. To change the backend or size later, see [change the sandbox configuration](/hosted-providers#change-the-sandbox-configuration).
+
+**Docker** shares each node's kernel with its sandboxes, and its node service account is [root-equivalent](/hosted-providers#what-the-installer-sets-up). Choose it only for trusted workloads or hosts without KVM. The installer asks for confirmation (default No); without a terminal, pass `--accept-docker-risks`.
+
+**E2B** needs a public HTTPS URL that is not loopback, because E2B's sandboxes call Core from E2B's cloud, so pass `--public-url`. Prepare the template build with the [E2B guide](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/deploy/e2b/README.md), then:
+
+```sh
+./install.sh --public-url https://core.example --sandbox e2b \
+  --e2b-api-key-file "$HOME/.oac/e2b-api-key" --e2b-template '<template-id>:<build-uuid>'
+```
+
+## Listeners and access
+
+The default combined Docker installation selects `--ingress managed` and `--host 0.0.0.0`. Its gateway publishes Web on `--port` (8080 by default) and uses ports 80 and 443 for automatic HTTPS. Core's `--core-port` stays on loopback and PostgreSQL stays private. `--host` accepts IPv4 or IPv6, without a port, scheme or zone. Use a concrete server IP in the browser, not a wildcard. Managed ingress needs a local Docker Unix socket and Docker's ability to publish ports 80 and 443.
+
+`--ingress external` uses your own reverse proxy instead. It is the only choice for Core-only, Web-only and native Core installations, and their default. Core and Web then listen on `--host`, loopback by default. External non-loopback listeners require an HTTPS `public_url` and a [reverse proxy](#https-and-the-reverse-proxy), and Web's domain setup is unavailable: set `public_url` in `config.json` and run `oac apply`.
+
+`--public-url` seeds a DNS-based HTTPS origin for unattended setup; with managed ingress, the certificate and connectivity checks must pass. The ingress mode is fixed for an installation.
+
+## HTTPS and the reverse proxy
+
+With external ingress, Core and Web share one public origin. Your reverse proxy terminates TLS and routes by path:
+
+| Path | Goes to | Callers |
+| --- | --- | --- |
+| `/v1`, `/v1/*` | Core, `127.0.0.1:8091` by default | Applications, with a Project API key |
+| `/api/v1/*` | Core, `127.0.0.1:8091` | Nodes, sandboxes and self-hosted machines. Uses WebSockets |
+| Everything else | Web, `127.0.0.1:8080` by default | Browsers, and node installers at `/node-install/*` |
+
+The proxy must:
+
+- **Preserve Host.** Web accepts only the host of its public URL.
+- **Pass WebSocket upgrades** on `/api/v1`.
+- **Not buffer or time out streams.** `/v1` streams Session events.
+- **Accept large uploads.** Source files may reach 512 MiB; Core enforces the limits.
+
+Run the proxy on the Core host while Core and Web listen on loopback, the default. `oac status` prints these routes with your addresses and ports.
+
+**Caddy** obtains the certificate itself and passes Host and WebSockets by default:
+
+```text
+core.example {
+	@core path /v1 /v1/* /api/v1/*
+	handle @core {
+		reverse_proxy 127.0.0.1:8091
+	}
+	handle {
+		reverse_proxy 127.0.0.1:8080
+	}
+}
+```
+
+**nginx**, for example in `/etc/nginx/conf.d/oac.conf` inside the `http` block:
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 80;
+    server_name core.example;
+    return 301 https://$host$request_uri;
+}
+
+server {
+    listen 443 ssl;
+    server_name core.example;
+    ssl_certificate     /etc/letsencrypt/live/core.example/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/core.example/privkey.pem;
+
+    client_max_body_size 0;          # Core enforces its own upload limits
+    proxy_http_version 1.1;
+    proxy_set_header Host $http_host;
+    proxy_set_header Upgrade $http_upgrade;
+    proxy_set_header Connection $connection_upgrade;
+    proxy_buffering off;             # server-sent events on /v1
+    proxy_request_buffering off;
+    proxy_read_timeout 1h;           # long-lived WebSockets and streams
+    proxy_send_timeout 1h;
+
+    location = /v1    { proxy_pass http://127.0.0.1:8091; }
+    location /v1/     { proxy_pass http://127.0.0.1:8091; }
+    location /api/v1/ { proxy_pass http://127.0.0.1:8091; }
+    location /        { proxy_pass http://127.0.0.1:8080; }
+}
+```
+
+Then set `public_url` in `~/.oac/core/config.json` and run `~/.oac/core/oac apply`. Check the routing:
+
+```sh
+curl -s -o /dev/null -w '%{http_code}\n' -H 'OpenAI-Beta: agents=v1' https://core.example/v1/agents
+```
+
+`401` means `/v1` reached Core, which asks for a key. `404` means it reached Web: fix the proxy, or application calls and every node connection will fail.
+
+TLS verification stays on everywhere. With a private certificate authority, node hosts, self-hosted machines and the Runtime image must trust it.
+
+### Try it locally with a quick tunnel
+
+A [Cloudflare quick tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/do-more-with-tunnels/trycloudflare/) gives a trial installation with external ingress a temporary public HTTPS address. It forwards to one port, so put a local proxy with the same routes in front:
+
+```text
+http://:8443 {
+	bind 127.0.0.1
+	@core path /v1 /v1/* /api/v1/*
+	handle @core {
+		reverse_proxy 127.0.0.1:8091
+	}
+	handle {
+		reverse_proxy 127.0.0.1:8080
+	}
+}
+```
+
+1. Start the proxy: `caddy run --config Caddyfile`.
+2. Start the tunnel: `cloudflared tunnel --url http://127.0.0.1:8443`. It prints an address such as `https://random-words.trycloudflare.com`.
+3. Set that address as `public_url` in `~/.oac/core/config.json` and run `~/.oac/core/oac apply`.
+
+The address changes whenever `cloudflared` restarts; nodes bound to the old address must then be added again. Throughput is low, so a node's first Runtime download (about 500 MB) can be slow; see [slow links](/hosted-providers#rerun-expiry-and-slow-links).
+
+## Modes
+
+| Mode | Runs | Use it for |
+| --- | --- | --- |
+| all (default) | PostgreSQL, Core and Web | Most installations |
+| `--core-only` | PostgreSQL and Core | A Core whose Web runs elsewhere, or scripts only. No Add node command |
+| `--web-only` | Web | A second host for the console, paired with an existing Core |
+
+The mode and native Core are fixed once installed; to change them, install into a new directory.
+
+A Web-only console forwards signed-in `/core/v1` requests to its Core with the Core key, so `--core-url` must reach Core's `/core/v1` directly. The public URL doesn't, because the proxy sends `/core/v1` to Web:
+
+- **Web on the Core host:** use `--core-url http://127.0.0.1:8091`.
+- **Web on another host:** give Core a second HTTPS name that sends every path to Core, such as `https://core-api.example`, and allow only the Web host's address.
+
+### Split deployment
+
+| Host | Install | Reverse proxy |
+| --- | --- | --- |
+| Core | `./install.sh --core-only --public-url https://core.example` | `core.example`: `/v1`, `/v1/*` and `/api/v1/*` to Core; `/node-install/*` to the Web host with Host rewritten to `console.example`; nothing else. `core-api.example`: every path to Core, for the Web host's address only |
+| Web | `./install.sh --web-only …`, below | `console.example`: every path to Web |
+
+```sh
+./install.sh --web-only --install-dir "$HOME/.oac/web" \
+  --public-url https://console.example \
+  --core-url https://core-api.example \
+  --core-key-file "$HOME/core.key"
+```
+
+Browsers and node installers use `console.example`. Applications, nodes, sandboxes and self-hosted machines call Core at `core.example`; self-hosted machines also download their installer there, which is why `core.example` forwards `/node-install/*` to Web. Missing node files redirect to the release; for disconnected nodes, install Web from the [offline bundle](#offline-hosts).
+
+Caddy on the Core host, where `203.0.113.10` is the Web host's address:
+
+```text
+core.example {
+	@core path /v1 /v1/* /api/v1/*
+	handle @core {
+		reverse_proxy 127.0.0.1:8091
+	}
+	handle /node-install/* {
+		reverse_proxy https://console.example {
+			header_up Host console.example
+		}
+	}
+	handle {
+		respond 404
+	}
+}
+
+core-api.example {
+	@web remote_ip 203.0.113.10
+	handle @web {
+		reverse_proxy 127.0.0.1:8091
+	}
+	handle {
+		respond 403
+	}
+}
+```
+
+nginx on the Core host, with the `map` from the [main example](#https-and-the-reverse-proxy):
+
+```nginx
+server {
+    listen 443 ssl;
+    server_name core.example;
+    ssl_certificate     /etc/letsencrypt/live/core.example/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/core.example/privkey.pem;
+
+    client_max_body_size 0;
+    proxy_http_version 1.1;
+    proxy_set_header Host $http_host;
+    proxy_set_header Upgrade $http_upgrade;
+    proxy_set_header Connection $connection_upgrade;
+    proxy_buffering off;
+    proxy_request_buffering off;
+    proxy_read_timeout 1h;
+    proxy_send_timeout 1h;
+
+    location = /v1    { proxy_pass http://127.0.0.1:8091; }
+    location /v1/     { proxy_pass http://127.0.0.1:8091; }
+    location /api/v1/ { proxy_pass http://127.0.0.1:8091; }
+    location /node-install/ {
+        proxy_pass https://console.example;
+        proxy_set_header Host console.example;   # Web serves node files only for its own name
+        proxy_ssl_server_name on;
+        proxy_ssl_name console.example;
+        proxy_ssl_verify on;
+        proxy_ssl_verify_depth 2;
+        proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
+    }
+    location / { return 404; }
+}
+
+server {
+    listen 443 ssl;
+    server_name core-api.example;
+    ssl_certificate     /etc/letsencrypt/live/core-api.example/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/core-api.example/privkey.pem;
+
+    allow 203.0.113.10;                        # the Web host
+    deny all;
+    client_max_body_size 0;
+    proxy_http_version 1.1;
+    proxy_buffering off;
+    proxy_read_timeout 1h;
+    location / { proxy_pass http://127.0.0.1:8091; }
+}
+```
+
+The Web host's proxy sends every path to Web, for example `console.example { reverse_proxy 127.0.0.1:8080 }` in Caddy.
+
+Copy `secrets/core.key` from the Core host with mode `0600`, then delete `$HOME/core.key`; the installer keeps its own copy. After a [Core key rotation](/troubleshooting#rotate-the-core-key), copy it again. A Web-only install selects no sandbox backend.
+
+## Native Core
+
+`--native-core` runs Core as a systemd user service; PostgreSQL and Web stay in containers. It needs a running systemd user manager with lingering, which the host administrator enables with `sudo loginctl enable-linger "$USER"`, and the bundle's native binaries must load on the host. PostgreSQL then listens on a loopback port the installer picks (`ports.database`). Native Core is unrelated to the sandbox backend.
+
+## Offline hosts
+
+Transfer the release's `*-linux-amd64-offline.tar.gz` and its `.sha256` file, verify and extract them, then run the bundled `./install.sh`. The offline bundle also carries the node and Runtime files, so Web serves them to nodes without release access.
 
 [Repository source](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/getting-started/install-options.md)
diff --git a/apps/docs/content/docs/install.mdx b/apps/docs/content/docs/install.mdx
index 60d3c791b..e4713293e 100644
--- a/apps/docs/content/docs/install.mdx
+++ b/apps/docs/content/docs/install.mdx
@@ -1,42 +1,29 @@
 ---
 title: "Install Core and Web"
-description: "Current distribution, host prerequisites, HTTPS, first sign-in and installation options."
+description: "Host prerequisites, installation, HTTPS, first sign-in, a default model and the first Project API key."
 ---
 
-One command installs Core, the Web console and PostgreSQL on a Linux host. Web is
-the administrator console: you sign in with the Core key, issue Project API keys
-and add nodes. Applications then call Core's API with those keys.
-
-The default path has five steps:
+One command installs Core, the Web console and PostgreSQL on a Linux host. Web is the administrator console: you sign in with the Core key, give the installation a domain, set a default model and issue Project API keys. Applications then call Core's API with those keys, and their Sessions run in sandboxes on nodes you add, or on E2B.
 
 1. [Check the prerequisites](#prerequisites).
 2. [Run the installer](#install).
-3. Open the printed `http://SERVER_IP:8080` address and [sign in to Web](#sign-in-to-web).
-4. [Configure HTTPS in Web](#make-core-reachable), set a default model and issue a key.
-5. [Add execution capacity](#next-steps): a node, E2B or your own machine.
+3. [Sign in to Web](#sign-in-to-web).
+4. [Configure the domain and HTTPS](#configure-the-domain-and-https).
+5. [Set a default model](#set-a-default-model).
+6. [Issue a Project API key](#issue-a-project-api-key).
+7. [Add sandbox capacity](#add-sandbox-capacity).
 
-Every flag, listener addresses and ports are in
-[installation options](/install-options). Offline hosts, other sandbox backends
-and split deployments are in [Advanced installation](#advanced-installation).
+This page follows the default path. Every flag, existing reverse proxies, split and native deployments and offline hosts are in [installation options](/install-options).
 
 ## Prerequisites
 
-**The Core host**
-
-- Linux amd64 with Python 3.9 or newer.
+- Linux amd64 with Python 3.9 or newer, and curl. No GitHub account or CLI is needed.
 - Docker Engine with Docker Compose 2.26.0 or newer (`docker compose version`).
-- An account that can run `docker` and write to its home directory. Ordinary users
-  and root both work; the installer never calls sudo.
-- Free ports 8080 (initial Web access), 80 and 443 (HTTPS gateway), and loopback
-  port 8091 (Core). Docker must be able to publish these ports; the installer
-  does not elevate privileges or change host policy.
-- curl. No GitHub CLI or login is needed.
+- An account that can run `docker` and write to its home directory. Ordinary users and root both work; the installer never calls sudo.
+- Free ports 8080 (initial Web access), 80 and 443 (HTTPS), and 8091 (Core, on loopback). Docker must be able to publish them; the installer does not change host policy.
+- A DNS hostname that points to this host, before you connect applications, nodes, E2B or self-hosted machines. You can install and sign in first.
 
-The Core host needs no KVM.
-
-A DNS hostname is needed when you connect applications, nodes, E2B or self-hosted
-machines. You can install and open Web before configuring it; the managed gateway
-obtains and renews the certificate automatically.
+The Core host needs no KVM; nodes that run microsandbox do.
 
 ## Install
 
@@ -44,428 +31,65 @@ obtains and renews the certificate automatically.
 curl -fsSL https://github.com/MiniMax-AI/parsar-core/releases/latest/download/install.sh | bash
 ```
 
-For noninteractive setup with DNS already pointing at the server, pass the public address:
+If DNS already points to this host, pass the address to set up HTTPS during installation instead of in step 4:
 
 ```sh
 curl -fsSL https://github.com/MiniMax-AI/parsar-core/releases/latest/download/install.sh | bash -s -- --public-url https://core.example
 ```
 
-The script picks the latest stable release, verifies its checksum and runs the
-bundled installer, which:
-
-1. checks the host and loads the Core, Web, PostgreSQL and installation gateway images;
-2. creates `~/.oac/core` (mode `0700`) with the Core key, `config.json` and the
-   `oac` management command;
-3. starts the services with Docker Compose. Web is reachable through the gateway
-   on `0.0.0.0:8080`; Core stays on loopback and PostgreSQL stays private;
-4. selects the microsandbox backend at the Standard size. It adds no node.
-
-It creates no Project or key and makes no model request. It ends by printing the
-console address, the API base URL and the next steps.
-
-Open the printed Web address. If the server is behind NAT, use the IP address
-reachable from your browser. The initial HTTP endpoint serves Web; machine API
-connections require the HTTPS address configured next.
-
-## Make Core reachable
-
-In Web, open **System → Domain and HTTPS** and enter a DNS hostname, such as
-`core.example.com`. Its A/AAAA records must point to this server, and ports 80 and
-443 must be reachable from the internet. Choose **Configure HTTPS**.
-
-The installer requests a certificate and verifies that the trusted HTTPS endpoint
-reaches this installation before switching Core and Web. On success, open the
-HTTPS address and sign in again; the initial HTTP Web address redirects there.
-Certificate renewal is automatic. DNS or certificate failures leave the previous
-address available; correct the reported problem and retry. An interrupted switch
-can be retried with the same hostname, or inspected with `oac status` and completed
-with `oac apply`. Installation data and execution workspaces are retained.
-
-The equivalent terminal operation uses the same preparation and apply flow:
-
-```sh
-~/.oac/core/oac domain core.example.com
-```
-
-Core derives every machine connection address from the resulting `public_url`.
-[Changing the public URL](/configure#changing-the-public-url) explains
-existing connection bindings and confirmation.
-
-### External proxy deployments
-
-Select `--ingress external` to use an existing proxy or a quick tunnel instead.
-Core-only, Web-only and native Core installations select external ingress by
-default. Their listeners remain loopback by default. Configure the proxy below,
-then set `public_url` in `config.json` and run `oac apply`; automatic domain setup in
-Web is unavailable for these installations.
-
-### HTTPS and the reverse proxy
-
-Core and Web share one public origin. Your reverse proxy terminates TLS and routes
-by path:
-
-| Path | Goes to | Callers |
-| --- | --- | --- |
-| `/v1`, `/v1/*` | Core, `127.0.0.1:8091` by default | Applications, with a Project API key |
-| `/api/v1/*` | Core, `127.0.0.1:8091` | Nodes, sandboxes and self-hosted machines. Uses WebSockets |
-| Everything else | Web, `127.0.0.1:8080` by default | Browsers, and node installers at `/node-install/*` |
-
-The proxy must:
-
-- **Preserve Host.** Web accepts only the host of its public URL.
-- **Pass WebSocket upgrades** on `/api/v1`.
-- **Not buffer or time out streams.** `/v1` streams Session events.
-- **Accept large uploads.** Source files may reach 512 MiB; Core enforces the limits.
-
-Run the proxy on the Core host when Core and Web listen on loopback (the default).
-`oac status` prints these routes with your addresses and ports.
-
-**Caddy** obtains the certificate itself and passes Host and WebSockets by default:
-
-```text
-core.example {
-	@core path /v1 /v1/* /api/v1/*
-	handle @core {
-		reverse_proxy 127.0.0.1:8091
-	}
-	handle {
-		reverse_proxy 127.0.0.1:8080
-	}
-}
-```
-
-**nginx**, for example in `/etc/nginx/conf.d/oac.conf` inside the `http` block:
-
-```nginx
-map $http_upgrade $connection_upgrade {
-    default upgrade;
-    ''      close;
-}
-
-server {
-    listen 80;
-    server_name core.example;
-    return 301 https://$host$request_uri;
-}
-
-server {
-    listen 443 ssl;
-    server_name core.example;
-    ssl_certificate     /etc/letsencrypt/live/core.example/fullchain.pem;
-    ssl_certificate_key /etc/letsencrypt/live/core.example/privkey.pem;
-
-    client_max_body_size 0;          # Core enforces its own upload limits
-    proxy_http_version 1.1;
-    proxy_set_header Host $http_host;
-    proxy_set_header Upgrade $http_upgrade;
-    proxy_set_header Connection $connection_upgrade;
-    proxy_buffering off;             # server-sent events on /v1
-    proxy_request_buffering off;
-    proxy_read_timeout 1h;           # long-lived WebSockets and streams
-    proxy_send_timeout 1h;
-
-    location = /v1    { proxy_pass http://127.0.0.1:8091; }
-    location /v1/     { proxy_pass http://127.0.0.1:8091; }
-    location /api/v1/ { proxy_pass http://127.0.0.1:8091; }
-    location /        { proxy_pass http://127.0.0.1:8080; }
-}
-```
-
-Check the routing:
+The script picks the latest stable release, verifies its checksum and runs the bundled installer, which:
 
-```sh
-curl -s -o /dev/null -w '%{http_code}\n' -H 'OpenAI-Beta: agents=v1' https://core.example/v1/agents
-```
-
-`401` means `/v1` reached Core, which asks for a key. `404` means it reached Web:
-fix the proxy, or application calls and every node connection will fail.
-
-TLS verification stays on everywhere. With a private certificate authority, node
-hosts, self-hosted machines and the Runtime image must trust it.
-
-### Try it locally with a quick tunnel
-
-A [Cloudflare quick tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/do-more-with-tunnels/trycloudflare/)
-gives a trial installation a temporary public HTTPS address. It forwards to one
-port, so put a local proxy with the same routes in front:
-
-```text
-http://:8443 {
-	bind 127.0.0.1
-	@core path /v1 /v1/* /api/v1/*
-	handle @core {
-		reverse_proxy 127.0.0.1:8091
-	}
-	handle {
-		reverse_proxy 127.0.0.1:8080
-	}
-}
-```
+1. checks the host and loads the Core, Web, PostgreSQL and HTTPS gateway images;
+2. creates the [installation directory](/configure#installation-directory), `~/.oac/core`, with the Core key, `config.json` and the `oac` management command;
+3. starts the services with Docker Compose. The gateway serves Web on port 8080 of all IPv4 interfaces; Core stays on loopback and PostgreSQL stays private;
+4. selects the microsandbox sandbox backend at the Standard size. It adds no node.
 
-1. Start the proxy: `caddy run --config Caddyfile`.
-2. Start the tunnel: `cloudflared tunnel --url http://127.0.0.1:8443`. It prints an
-   address such as `https://random-words.trycloudflare.com`.
-3. Set that address as `public_url` in `~/.oac/core/config.json` and run
-   `~/.oac/core/oac apply`.
-
-The address changes whenever `cloudflared` restarts; nodes bound to the old address
-must then be added again. Throughput is low, so a node's first Runtime download
-(about 500 MB) can be slow; see [slow links](/hosted-providers#rerun-expiry-and-slow-links).
+It creates no Project or key and makes no model request. It ends by printing the console address, the API base URL and the next steps.
 
 ## Sign in to Web
 
-1. **Open the console** at the address the installer printed: your public URL, or
-   `http://127.0.0.1:8080` on the Core host by default. Web refuses other host names.
-   For a remote host without a public URL, forward the port over SSH first, for
-   example `ssh -L 8080:127.0.0.1:8080 <core-host>`.
-2. **Sign in with the Core key**, the installation's administrator credential. Web has
-   no user accounts. See [Core key](/troubleshooting#core-key).
+1. Open the console address the installer printed: `http://SERVER_IP:8080`, or your public URL if you passed one. Behind NAT, use the IP address your browser reaches. Until a domain is set, Web accepts IP addresses only, not host names.
+2. Sign in with the [Core key](/troubleshooting#core-key), the installation's administrator credential. Web has no user accounts.
 
    ```sh
    cat ~/.oac/core/secrets/core.key
    ```
 
-3. **Set a default model.** On **System**, find **Default model**. On the card marked
-   **Default** (Codex unless you changed it), choose **Set** and enter the model and
-   its provider's base URL and API key. MiniMax Code also needs the context window
-   and max output tokens. See [Default models](/configure#default-models).
-4. **Create a project and issue a key.** On **Projects and keys**, choose
-   **Create project**, then **Issue key**. The dialog shows the key once: copy it and
-   keep it safe. Its **How to call** card shows the API base URL and sample requests.
-5. **Hand over** the key and the API base URL to the application developer. They continue with the [quickstart](/quickstart).
-
-Web's **Overview** tracks these steps in a **Getting started** checklist.
-
-## Next steps
-
-| Goal | Guide |
-| --- | --- |
-| Run Sessions in managed sandboxes | [Add a node](/hosted-providers), or use [E2B](#sandbox-backend) |
-| Run your first Session | [Quickstart](/quickstart) |
-| Run Sessions on your own machine | [Self-hosted execution](/self-hosted-execution) |
-| Operate the installation | [Operations](/troubleshooting) and [configuration](/configure) |
-
-## Advanced installation
+## Configure the domain and HTTPS
 
-### Installer options
+Applications, nodes and sandboxes reach Core at one HTTPS address, the public URL. The initial HTTP address serves only Web.
 
-Every flag, with the `config.json` field it seeds, is in
-[installation options](/install-options). Pass them after `bash -s --`, or
-download `install.sh` from the Release page and run it directly. The script
-verifies the bundle's SHA-256 before extracting it and keeps the verified bundle
-under `~/.oac/releases/` for repair. It never upgrades an existing installation.
+1. Point the hostname's A/AAAA records to this host, and allow inbound ports 80 and 443 from the internet.
+2. In Web, open **System**, choose **Configure domain and HTTPS**, enter the hostname, such as `core.example.com`, and choose **Apply**.
 
-**Offline hosts.** Transfer the Release's `*-linux-amd64-offline.tar.gz` and its
-`.sha256` file, verify and extract them, then run the bundled `./install.sh`. The
-offline bundle also carries the node and Runtime files, so Web can serve them to
-nodes without release access.
+The installation requests a certificate and checks that the HTTPS address reaches this installation before switching Core and Web to it. Then open the HTTPS address and sign in again; the initial HTTP address redirects there. Certificates renew automatically. If DNS or the certificate fails, the previous address stays in use: correct the reported problem and retry. Retry an interrupted switch with the same hostname, or check it with `oac status` and finish it with `oac apply`.
 
-**Output.** The installer prints each stage, then a summary of addresses, sign-in
-details and next steps. Set `NO_COLOR=1` to disable colors. A failed step stops
-installation without a success message.
-
-### Sandbox backend
-
-A deployment runs its sandboxes on exactly one backend:
-
-| `--sandbox` | Sandboxes run on | You then |
-| --- | --- | --- |
-| `microsandbox` (default) | microVMs on your nodes (KVM): 2 CPUs, 4 GiB memory and two 8 GiB disks each | [Add nodes](/hosted-providers) in Web |
-| `docker` | Docker on your nodes: 2 CPUs and 2 GiB each; weaker isolation | [Add nodes](/hosted-providers) in Web |
-| `e2b` | E2B's cloud, sized by your template build | Nothing: E2B needs no nodes |
-| `none` | Nothing yet | Choose on the **Nodes** page in Web |
-
-The Standard sizes come from Web's
-[`standard-sizes.json`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/apps/web/src/features/sandbox/standard-sizes.json). If
-Core refuses the choice, for example because E2B rejects the key, the installer
-prints Core's message and exits; the services keep running and you choose the
-backend in Web. To change the backend or size later, see
-[Sandbox deployment](/configure#sandbox-deployment).
-
-**Docker's risks.** Containers share the host kernel, so a container escape reaches
-the node host; microsandbox gives each sandbox its own microVM. The node's service
-account in the `docker` group is root-equivalent. Choose Docker only for trusted
-workloads or hosts without KVM. The installer asks for confirmation (default No);
-without a terminal, pass `--accept-docker-risks`.
-
-**E2B** needs a public HTTPS URL that is not loopback, because E2B's sandboxes call
-Core from E2B's cloud. Prepare the template build with the
-[E2B guide](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/deploy/e2b/README.md), then:
+The same operation from a terminal:
 
 ```sh
-./install.sh --public-url https://core.example --sandbox e2b \
-  --e2b-api-key-file "$HOME/.oac/e2b-api-key" --e2b-template '<template-id>:<build-uuid>'
+~/.oac/core/oac domain core.example.com
 ```
 
-### Modes
+To change the address later, see [changing the public URL](/configure#changing-the-public-url).
 
-| Mode | Runs | Use it for |
-| --- | --- | --- |
-| all (default) | PostgreSQL, Core and Web | Most installations |
-| `--core-only` | PostgreSQL and Core | A Core whose Web runs elsewhere, or scripts only. No Add node command |
-| `--web-only` | Web | A second host for the console, paired with an existing Core |
+## Set a default model
 
-The mode and native Core are fixed once installed; to change them, install into a
-new directory.
+Core-hosted Sessions without their own model provider use their harness's default model. On **System**, under **Default model configuration**, find the harness marked **Default** (Codex unless you changed `core.default_harness`) and choose **Set**. Enter the model ID, the protocol, and the provider's base URL and API key. MiniMax Code also needs the context window and max output tokens. See [default models](/configure#default-models).
 
-A Web-only console forwards signed-in `/core/v1` requests to its Core with the Core
-key, so `--core-url` must reach Core's `/core/v1` directly. The public URL doesn't,
-because the default proxy sends `/core/v1` to Web:
+## Issue a Project API key
 
-- **Web on the Core host:** use `--core-url http://127.0.0.1:8091`.
-- **Web on another host:** give Core a second HTTPS name that sends every path to
-  Core, such as `https://core-api.example`, and allow only the Web host's address.
+1. On **Projects and keys**, choose **Create project**, then **Issue key**. The dialog shows the key once: copy it and keep it safe. Its **How to call** card shows the API base URL and sample requests.
+2. Give the key and the API base URL to the application developer. They continue with the [quickstart](/quickstart).
 
-#### Split deployment
-
-| Host | Install | Reverse proxy |
-| --- | --- | --- |
-| Core | `./install.sh --core-only --public-url https://core.example` | `core.example`: `/v1`, `/v1/*` and `/api/v1/*` to Core; `/node-install/*` to the Web host with Host rewritten to `console.example`; nothing else. `core-api.example`: every path to Core, for the Web host's address only |
-| Web | `./install.sh --web-only …`, below | `console.example`: every path to Web |
+Web's **Overview** tracks these steps in a **Getting started** checklist.
 
-```sh
-./install.sh --web-only --install-dir "$HOME/.oac/web" \
-  --public-url https://console.example \
-  --core-url https://core-api.example \
-  --core-key-file "$HOME/core.key"
-```
+## Add sandbox capacity
 
-Browsers and node installers use `console.example`. Applications, nodes, sandboxes
-and self-hosted machines call Core at `core.example`; self-hosted machines also
-download their installer there, which is why `core.example` forwards
-`/node-install/*` to Web. Missing node artifacts redirect to the release; for
-disconnected nodes, install Web from the offline bundle.
-
-Caddy on the Core host, where `203.0.113.10` is the Web host's address:
-
-```text
-core.example {
-	@core path /v1 /v1/* /api/v1/*
-	handle @core {
-		reverse_proxy 127.0.0.1:8091
-	}
-	handle /node-install/* {
-		reverse_proxy https://console.example {
-			header_up Host console.example
-		}
-	}
-	handle {
-		respond 404
-	}
-}
-
-core-api.example {
-	@web remote_ip 203.0.113.10
-	handle @web {
-		reverse_proxy 127.0.0.1:8091
-	}
-	handle {
-		respond 403
-	}
-}
-```
+Sessions need somewhere to run:
 
-nginx on the Core host, with the `map` from the
-[main example](#https-and-the-reverse-proxy):
-
-```nginx
-server {
-    listen 443 ssl;
-    server_name core.example;
-    ssl_certificate     /etc/letsencrypt/live/core.example/fullchain.pem;
-    ssl_certificate_key /etc/letsencrypt/live/core.example/privkey.pem;
-
-    client_max_body_size 0;
-    proxy_http_version 1.1;
-    proxy_set_header Host $http_host;
-    proxy_set_header Upgrade $http_upgrade;
-    proxy_set_header Connection $connection_upgrade;
-    proxy_buffering off;
-    proxy_request_buffering off;
-    proxy_read_timeout 1h;
-    proxy_send_timeout 1h;
-
-    location = /v1    { proxy_pass http://127.0.0.1:8091; }
-    location /v1/     { proxy_pass http://127.0.0.1:8091; }
-    location /api/v1/ { proxy_pass http://127.0.0.1:8091; }
-    location /node-install/ {
-        proxy_pass https://console.example;
-        proxy_set_header Host console.example;   # Web serves node files only for its own name
-        proxy_ssl_server_name on;
-        proxy_ssl_name console.example;
-        proxy_ssl_verify on;
-        proxy_ssl_verify_depth 2;
-        proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
-    }
-    location / { return 404; }
-}
-
-server {
-    listen 443 ssl;
-    server_name core-api.example;
-    ssl_certificate     /etc/letsencrypt/live/core-api.example/fullchain.pem;
-    ssl_certificate_key /etc/letsencrypt/live/core-api.example/privkey.pem;
-
-    allow 203.0.113.10;                        # the Web host
-    deny all;
-    client_max_body_size 0;
-    proxy_http_version 1.1;
-    proxy_buffering off;
-    proxy_read_timeout 1h;
-    location / { proxy_pass http://127.0.0.1:8091; }
-}
-```
+- **Nodes** run the microsandbox backend the installer selected: [add a node](/hosted-providers) from Web's **Nodes** page. Docker nodes need `--sandbox docker` at installation, or a [reset](/hosted-providers#change-the-sandbox-configuration) to change the backend.
+- **E2B**, which needs no nodes: [change the sandbox configuration](/hosted-providers#change-the-sandbox-configuration) in Web, or [choose it during installation](/install-options#sandbox-backend).
 
-The Web host's proxy sends every path to Web, for example
-`console.example { reverse_proxy 127.0.0.1:8080 }` in Caddy.
-
-Copy `secrets/core.key` from the Core host with mode `0600`, then delete
-`$HOME/core.key`; the installer keeps its own copy. After a
-[Core key rotation](/troubleshooting#rotate-the-core-key), copy it again. A Web-only
-install selects no sandbox backend.
-
-### Native Core
-
-`--native-core` runs Core as a systemd user service; PostgreSQL and Web stay in
-containers. It needs a running systemd user manager with lingering
-(`sudo loginctl enable-linger "$USER"`), and the bundle's native binaries must load
-on the host. PostgreSQL then listens on a loopback port the installer picks
-(`ports.database`). Native Core is unrelated to the sandbox backend.
-
-### What the installer creates
-
-The installation directory, `~/.oac/core` by default, mode `0700`:
-
-| Path | Content |
-| --- | --- |
-| `config.json` | Process settings. The only file you edit; see the [configuration reference](/configure) |
-| `oac` | The [management command](/troubleshooting#the-oac-command) |
-| `secrets/core.key` | The Core key |
-| `secrets/credential.key` | Encryption key for credentials stored in the database. Back it up with the database; never replace it |
-| `secrets/database.password` | PostgreSQL password |
-| `state.json` | Installation ID, Compose project name, image IDs and source commit. Written by the tools only |
-| `generated/` | Files derived from `config.json`. `oac apply` rewrites them; don't edit them |
-| `node-payload/` | The node installer and files that Web serves at `/node-install/` |
-| `state/e2b/` | Private E2B receipts |
-| `native/` | Core binaries, with `--native-core` only |
-
-Web-only installations have only `secrets/core.key` among the secrets. Core-only
-installations have no `node-payload/`.
-
-In Docker, the Compose project is named `oac-<10 hex digits>` (`project` in
-`state.json`), with the containers `database`, `migrate`, `core` and `web` and the
-volume `<project>_database` that holds all data. Apart from Docker's storage,
-nothing is written outside your home directory. Native Core adds a systemd user
-unit.
-
-### Rerun the installer
-
-Rerunning `./install.sh` from the same bundle repairs an installation: it reloads
-missing images, restores the `oac` command, applies `config.json` and starts the
-services. It accepts only `--install-dir` and refuses a bundle from another
-release; see [installation version policy](/troubleshooting#installation-version-policy).
-
-An installation from before the rename, at `~/.parsar/core`, blocks a new default
-install. Keep it and choose another `--install-dir`.
+Day-to-day operation, backups and upgrades are in [Operations](/troubleshooting).
 
 [Repository source](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/getting-started/install.md)
diff --git a/apps/docs/content/docs/public-api.mdx b/apps/docs/content/docs/public-api.mdx
index a33e83b6b..92fd66085 100644
--- a/apps/docs/content/docs/public-api.mdx
+++ b/apps/docs/content/docs/public-api.mdx
@@ -11,14 +11,14 @@ public release content.
 | --- | --- | --- | --- | --- |
 | `/v1` | Applications (business systems, SDKs) | Project API key | Exactly the pinned official Agents API routes. Core-only fields live only in `x_agents_core` (`harness`, `model_provider`, `harness_config`, Session `installation`) | [Agents API guide](/sessions) |
 | `/core/v1` | Core Web's server and operator scripts | [Core key](/troubleshooting#core-key) | Installation facts, Projects and keys, resource reads and deletion, Session archive, credential issuance, metrics, audit, sandbox deployment and nodes, deployment model providers | [Core API](#core-api), [Web API](/admin-api), [Core OpenAPI](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/core.openapi.yaml) |
-| `/api/v1` | Nodes, Runtime daemons, self-hosted executors | Machine credentials: short-lived Session installation grants, node enrollment tokens and executor credentials issued through `/core/v1` or claimed by installation, node credentials registered with an enrollment token, and daemon credentials Core issues for hosted sandboxes | Machine bootstrap and connections: `/api/v1/sandbox-node/*` and `/api/v1/agent-daemon/*`, including WebSockets; each credential works only on its own routes | [Node operations](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md#register-a-host), [executor credentials](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/environment-executor-credentials.md), [machine OpenAPI](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/runtime.openapi.yaml) |
+| `/api/v1` | Nodes, Runtime daemons, self-hosted executors | Machine credentials: short-lived Session installation grants, node enrollment tokens and executor credentials issued through `/core/v1` or claimed by installation, node credentials registered with an enrollment token, and daemon credentials Core issues for hosted sandboxes | Machine bootstrap and connections: `/api/v1/sandbox-node/*` and `/api/v1/agent-daemon/*`, including WebSockets; each credential works only on its own routes | [Node routes](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md#authority-and-routes), [executor credentials](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/environment-executor-credentials.md), [machine OpenAPI](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/runtime.openapi.yaml) |
 
 A credential used in another namespace gets 401: a Project API key on `/core/v1` or
 `/api/v1`, the Core key on `/v1` or `/api/v1`. How Projects and keys behave is in
 [Projects own assets](/concepts#projects-own-assets).
 
 **Routing.** The reverse proxy sends `/v1` and `/api/v1` to Core and everything else
-to Web ([proxy setup](/install#https-and-the-reverse-proxy)).
+to Web ([proxy setup](/install-options#https-and-the-reverse-proxy)).
 Browsers reach `/core/v1` only through Web's server, which adds the Core key after
 sign-in; Web returns 404 for `/v1` and `/api/v1`. Operator scripts call `/core/v1`
 on Core's loopback port. Details: [Web and Core](/admin-api).
@@ -77,7 +77,7 @@ Errors use the [Core error envelope](https://github.com/MiniMax-AI/parsar-core/b
 | `projects/{project_id}/environments/{environment_id}/executor-credentials[/{key_id}]` | Executor credentials for a self-hosted Environment | [Executor credentials](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/environment-executor-credentials.md) |
 | `installation` | Public URL, API base URL, source commit, the installer's process settings and what is bound to the public URL; available before any deployment | [Installation](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/installation.md) |
 | `metrics` | Core's own process metrics | [Core metrics](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/core-metrics.md) |
-| `sandbox/deployment[/reset]`, `sandbox/e2b/templates[/{template_id}/builds]`, `sandbox/enrollment-tokens`, `sandbox/nodes[/{node_id}[/allocations]]` | Sandbox deployment, read-only E2B template discovery, node enrollment tokens and nodes | [Sandbox deployment](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md), [node operations](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md), [node host history](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/node-host-history.md) |
+| `sandbox/deployment[/reset]`, `sandbox/e2b/templates[/{template_id}/builds]`, `sandbox/enrollment-tokens`, `sandbox/nodes[/{node_id}[/allocations]]` | Sandbox deployment, read-only E2B template discovery, node enrollment tokens and nodes | [Sandbox deployment](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md), [nodes guide](/hosted-providers), [node host history](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/node-host-history.md) |
 | `harnesses`, `harnesses/{harness}/model-configuration` | Supported harnesses and each harness's deployment default model configuration (write-only provider key) | [Model execution](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/model-execution.md#deployment-defaults) |
 
 ## Machine connection API
@@ -87,9 +87,9 @@ the Core key or a Project API key.
 
 | Routes | Caller | Credential | Contract |
 | --- | --- | --- | --- |
-| `POST sandbox-node/enroll` | Node installer | One-use enrollment token from `POST /core/v1/sandbox/enrollment-tokens` | [Node operations](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md#register-a-host), [machine OpenAPI](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/runtime.openapi.yaml) |
+| `POST sandbox-node/enroll` | Node installer | One-use enrollment token from `POST /core/v1/sandbox/enrollment-tokens` | [Node routes](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md#authority-and-routes), [machine OpenAPI](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/runtime.openapi.yaml) |
 | `GET sandbox-node/configuration` | Node installer and node | Enrollment token, or node credential with `X-OAC-Node-ID` | [Sandbox deployment](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md), [machine OpenAPI](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/runtime.openapi.yaml) |
-| `GET sandbox-node/identity`, WebSocket `GET sandbox-node/connect` | Node | Node credential registered at enrollment | [Node operations](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md#register-a-host) |
+| `GET sandbox-node/identity`, WebSocket `GET sandbox-node/connect` | Node | Node credential registered at enrollment | [Node routes](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/sandbox-deployment.md#authority-and-routes) |
 | `POST agent-daemon/enroll`, `GET agent-daemon/connection` | Self-hosted executor and its installer | Executor credential from `/core/v1/projects/{project_id}/environments/{environment_id}/executor-credentials` | [Executor credentials](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/environment-executor-credentials.md) |
 | WebSocket `GET agent-daemon/ws`, `POST agent-daemon/bootstrap`, `GET agent-daemon/device-status` | Runtime daemons | Daemon credential: Core writes one into each hosted sandbox it prepares; a self-hosted executor uses its executor credential | [Runtime enrollment](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/README.md#user-managed-runtime-enrollment) |
 
diff --git a/apps/docs/content/docs/quickstart.mdx b/apps/docs/content/docs/quickstart.mdx
index 3f35b7707..a75d47b12 100644
--- a/apps/docs/content/docs/quickstart.mdx
+++ b/apps/docs/content/docs/quickstart.mdx
@@ -3,25 +3,18 @@ title: "Call the Agent API"
 description: "From a Project API key to a finished Session in three steps."
 ---
 
-This walkthrough takes you from a Project API key to an agent that has created a file
-and reported back. You need:
+This walkthrough takes you from a Project API key to an agent that has created a file and reported back. You need:
 
-- a Project API key and the API base URL, from your administrator
-  ([Sign in to Web](/install#sign-in-to-web));
-- a ready node or E2B backend, so Core has somewhere to run the agent
-  ([Nodes](/hosted-providers));
+- a Project API key and the API base URL, from your administrator ([Issue a Project API key](/install#issue-a-project-api-key));
+- a ready node or E2B backend, so Core has somewhere to run the agent ([Nodes](/hosted-providers));
 - Python 3.9 or newer;
-- a model: either the installation's default model, set by your administrator, or
-  your own provider's model ID, base URL and API key.
+- a model: the installation's default model, or your own provider's model ID, base URL and API key. [Model execution](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/model-execution.md#saved-defaults-and-precedence) says which one a Session uses and which protocols each harness speaks.
 
-The example uses Codex, which needs a provider that speaks the OpenAI Responses API.
-Other harnesses and protocols are in the
-[user guide](/user-guide#choose-a-harness-and-a-model).
+The example uses Codex, whose model provider must speak the OpenAI Responses API.
 
 ## 1. Connect
 
-Core serves the OpenAI Agents API, so the official OpenAI SDK works unchanged. It
-reads two environment variables:
+Core serves the OpenAI Agents API, so the official OpenAI SDK works unchanged. It reads two environment variables:
 
 | Variable | Value |
 | --- | --- |
@@ -54,9 +47,7 @@ curl "$OPENAI_BASE_URL/agents" -H "OpenAI-Beta: agents=v1" \
 
 ## 2. Start a Session
 
-A Session is one agent conversation with its own workspace. With
-`openai_hosted`, Core creates a sandbox for it on a node or E2B and starts the harness
-inside.
+A Session is one agent conversation with its own workspace. With `openai_hosted`, Core creates a sandbox for it on a node or E2B and starts the harness inside.
 
 With the installation's default model, skip this. To use your own provider:
 
@@ -88,15 +79,12 @@ print(session.id)
 
 This makes a real model request and may incur charges.
 
-- `x_agents_core` holds Core's additions to the OpenAI API; see
-  [Core extensions](/sessions#core-extensions-x_agents_core).
-- Keep the whole `agent` object in `extra_body`. SDK 3.13.0 replaces a body field with
-  the matching `extra_body` field instead of merging them.
+- `x_agents_core` holds Core's additions to the OpenAI API; see [Core extensions](/sessions#core-extensions-x_agents_core).
+- Keep the whole `agent` object in `extra_body`. SDK 3.13.0 replaces a body field with the matching `extra_body` field instead of merging them.
 
 ## 3. Wait for the result
 
-A Session ID confirms creation, not success. Poll durable state; never resubmit to
-"retry":
+A Session ID confirms creation, not success. Poll durable state; never resubmit to "retry":
 
 ```python
 import time
@@ -115,8 +103,7 @@ else:
     raise TimeoutError(f"Session {session.id} is still running; inspect it before retrying")
 ```
 
-Success is a `completed` Turn whose Items describe the new file. A timeout neither
-cancels the work nor proves it failed.
+Success is a `completed` Turn whose Items describe the new file. A timeout neither cancels the work nor proves it failed.
 
 ## Next steps
 
diff --git a/apps/docs/content/docs/sandbox-provider.mdx b/apps/docs/content/docs/sandbox-provider.mdx
index c36582f5e..c704602f4 100644
--- a/apps/docs/content/docs/sandbox-provider.mdx
+++ b/apps/docs/content/docs/sandbox-provider.mdx
@@ -316,7 +316,7 @@ Environment provides isolation.
 
 | Kind | Adapter | Helper | Operator guide |
 | --- | --- | --- | --- |
-| Docker (node) | [`sandbox/docker`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/internal/sandbox/docker) | Node proxy in [`sandbox/node`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/internal/sandbox/node) | [Hosted sandbox manager](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/HOSTED-SANDBOX-MANAGER.md) |
+| Docker (node) | [`sandbox/docker`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/internal/sandbox/docker) | Node proxy in [`sandbox/node`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/internal/sandbox/node) | [Nodes](/hosted-providers) |
 | microsandbox (node) | [`sandbox/microsandbox`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/internal/sandbox/microsandbox) | [`tools/microsandbox-provider`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/tools/microsandbox-provider) | [`deploy/microsandbox`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/deploy/microsandbox/README.md) |
 | E2B (direct) | [`sandbox/e2b`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/internal/sandbox/e2b) | [`tools/e2b-provider`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/tools/e2b-provider/README.md) | [`deploy/e2b`](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/services/agents-api/deploy/e2b/README.md) |
 
diff --git a/apps/docs/content/docs/troubleshooting.mdx b/apps/docs/content/docs/troubleshooting.mdx
index 53167eb74..c920476ca 100644
--- a/apps/docs/content/docs/troubleshooting.mdx
+++ b/apps/docs/content/docs/troubleshooting.mdx
@@ -3,14 +3,11 @@ title: "Operations and troubleshooting"
 description: "oac lifecycle commands, backups, key rotation, current-version repair and diagnostics."
 ---
 
-The installation operator owns the Core host, its storage and its availability. Node
-hosts run their own services; see [Nodes](/hosted-providers). Settings are described in the
-[configuration reference](/configure).
+The installation operator owns the Core host, its storage and its availability. Node hosts run their own services; see [Nodes](/hosted-providers). Settings are described in the [configuration reference](/configure).
 
 ## The oac command
 
-Each installation has its own management command in its directory. It needs neither
-the bundle nor root:
+Each installation has its own management command in its directory. It needs neither the bundle nor root:
 
 ```sh
 ~/.oac/core/oac status
@@ -18,7 +15,7 @@ the bundle nor root:
 
 | Command | What it does |
 | --- | --- |
-| `oac status` | Shows each service and its health, Core and Web health, the public URL, API base URL, console address and source commit, the reverse-proxy routes to configure, `config.json` changes not applied yet and generated files edited by hand. A Web-only installation also checks that its Core accepts its Core key. Exits non-zero when a service is unavailable. It never calls a model |
+| `oac status` | Shows each service and its health, Core and Web health, the public URL, API base URL, console address and source commit, the routes a reverse proxy needs, `config.json` changes not applied yet and generated files edited by hand. A Web-only installation also checks that its Core accepts its Core key. Exits non-zero when a service is unavailable. It never calls a model |
 | `oac start` | Starts every service with the files last written by `apply`; warns about unapplied changes |
 | `oac stop` | Stops PostgreSQL, Core and Web. Data, nodes and sandboxes are kept, and running sandbox work may continue |
 | `oac apply` | Applies `config.json` and restarts what changed; see [how apply works](/configure#how-oac-apply-works) |
@@ -26,11 +23,10 @@ the bundle nor root:
 | `oac apply --discard-edits` | Overwrites generated files edited by hand, keeping each as `generated/<file>.edited-<time>` |
 | `oac apply --confirm-public-url-change URL` | Confirms a public URL change without a prompt; must equal the new URL |
 | `oac apply --yes` | Web-only: pairs Web with a different Core without asking |
+| `oac domain HOSTNAME [--confirm-public-url-change URL]` | Managed ingress: sets the public URL to `https://HOSTNAME`, as **Configure domain and HTTPS** in Web does; see [Configure the domain and HTTPS](/install#configure-the-domain-and-https) |
 | `oac rotate-core-key [--yes]` | Replaces the Core key; see [Rotate the Core key](#rotate-the-core-key) |
 
-`install.sh --status` and `--stop` are retired; they name the `oac` command instead.
-For a second installation, use its own command, such as
-`~/.oac/web/oac status`.
+For a second installation, use its own command, such as `~/.oac/web/oac status`.
 
 ## Service health
 
@@ -44,18 +40,14 @@ Use these observations for different questions:
 | Environment connection | The Runtime transport is connected |
 | A finished Turn and its results | The task's recorded outcome |
 
-Service health does not prove that a native harness or a model works. Use Session,
-Turn, Items and Usage reads for execution, and Web's **Nodes** page for node connection,
-readiness and placement. For local diagnosis, use the installation's own Compose file:
+Service health does not show that a harness or a model works. Use Session, Turn, Items and Usage reads for execution, and Web's **Nodes** page for node connection, readiness and placement. For local diagnosis, use the installation's own Compose file:
 
 ```sh
 docker compose -f "$HOME/.oac/core/generated/compose.json" ps --all
 docker compose -f "$HOME/.oac/core/generated/compose.json" logs --tail 200 core
 ```
 
-Native Core logs to its user unit: `journalctl --user -u <project>-core.service`, with
-`project` from `state.json`. Don't paste `docker compose config`, `docker inspect` or
-raw logs into public issue reports.
+Native Core logs to its user unit: `journalctl --user -u <project>-core.service`, with `project` from `state.json`. Don't paste `docker compose config`, `docker inspect` or raw logs into public issue reports.
 
 ## Stop and restart
 
@@ -66,65 +58,58 @@ Let active work settle before a planned restart:
 ~/.oac/core/oac start
 ```
 
-Stopping Core stops no node and no sandbox. Node services, their microVMs and Docker
-containers keep running; stopping is not a way to reclaim compute. A Core restart does
-not continue an interrupted native tool call transparently. After reconnecting, query
-the same Session; don't create a new Session to replay uncertain work. Session event
-streams are live only; recover through Session, Turn and Items reads.
+Stopping Core stops no node and no sandbox. Node services, their microVMs and Docker containers keep running; stopping is not a way to reclaim compute. A Core restart does not continue an interrupted native tool call transparently. After reconnecting, query the same Session; don't create a new Session to replay uncertain work. Session event streams are live only; recover through Session, Turn and Items reads.
 
-A Web restart, including one caused by `oac apply`, signs everyone out of the
-console.
+A Web restart, including one caused by `oac apply`, signs everyone out of the console. Web sign-ins otherwise last 12 hours.
 
 ## Core key
 
-Each installation has one administrator credential, the Core key. The installer
-generates a 64-character random key in `<install dir>/secrets/core.key`, by default
-`~/.oac/core/secrets/core.key`. The Core key:
+Each installation has one administrator credential, the Core key. The installer generates a 64-character random key in `<install dir>/secrets/core.key`, by default `~/.oac/core/secrets/core.key`. The Core key:
 
 - signs in to Web. The browser gets an HttpOnly session cookie, never the key;
 - authorizes Core API (`/core/v1`) requests sent as `Authorization: Bearer <Core key>`;
-- never authorizes the Agent API (`/v1`). Applications use Project API keys, which in
-  turn can't call `/core/v1`.
+- never authorizes the Agents API (`/v1`). Applications use Project API keys, which in turn can't call `/core/v1`.
 
-Keep it private: `secrets/` is mode `0700` and its files `0600`. Of the services, only
-Web reads `core.key`; Core reads its SHA-256 from `generated/core-key-digests.json`,
-which `oac apply` derives from the key. Both read them only at startup. A Core key
-has at least 32 characters and no whitespace. Web limits failed sign-ins.
+Keep it private: `secrets/` is mode `0700` and its files `0600`. Web and, with managed ingress, the `installation` service read `core.key`; Core reads only its SHA-256 from `generated/core-key-digests.json`, which `oac apply` derives from the key. A Core key has at least 32 characters and no whitespace. Web limits failed sign-ins.
 
-Scripts run on the Core host, call Core's loopback port and read the key from its file,
-which keeps it off the command line:
+### Script the Core API
+
+Run scripts on the Core host against Core's loopback port. This helper reads the key from its file, keeping it off the command line:
 
 ```sh
-curl -fsS -H @<(printf 'Authorization: Bearer %s\n' "$(cat "$HOME/.oac/core/secrets/core.key")") \
-  http://127.0.0.1:8091/core/v1/projects
+core() {  # core METHOD PATH [JSON body]
+  curl -fsS -X "$1" "http://127.0.0.1:8091/core/v1$2" \
+    -H @<(printf 'Authorization: Bearer %s\n' "$(cat ~/.oac/core/secrets/core.key)") \
+    -H 'Content-Type: application/json' ${3:+-d "$3"}
+}
 ```
 
+| Task | Command |
+| --- | --- |
+| List Projects | `core GET /projects` |
+| Create a Project | `core POST /projects '{"name": "billing-bot"}'` |
+| Issue an API key (shown once, as `key`) | `core POST /projects/$PROJECT_ID/keys '{"name": "prod"}'` |
+| Revoke a key | `core DELETE /projects/$PROJECT_ID/keys/$KEY_ID` |
+| Archive a Project (revokes all keys) | `core POST /projects/$PROJECT_ID/archive` |
+| See harnesses and their default models | `core GET /harnesses` |
+| Set Codex's default model | `core PUT /harnesses/codex/model-configuration '{"model": "your-model-id", "model_provider": {"protocol": "responses", "base_url": "https://provider.example/v1", "api_key": "sk-..."}}'` |
+| Installation facts, including the API base URL | `core GET /installation` |
+
+The [API index](/public-api#core-api) lists every route; errors use the [Core error envelope](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/core-errors.md).
+
 ### Rotate the Core key
 
 ```sh
 ~/.oac/core/oac rotate-core-key
 ```
 
-It refuses while `config.json` has changes that are not applied or a generated file was
-edited by hand: run `oac apply` first. It asks for confirmation (`--yes` skips it),
-stops Web, writes a new key to `secrets/core.key` and regenerates the digest file. On a
-running installation it then restarts Core, starts Web and checks that Core accepts the
-new key and refuses the old one; a stopped installation only gets the new files and
-uses the new key at the next `oac start`. The old key stops working as soon as Core
-restarts, and every console session ends: sign in again and update your scripts. If the
-command stops early, `secrets/core.key` holds the key to use; run `oac apply` to
-finish.
-
-A separate Web-only installation keeps its own copy of the key. After rotating, copy
-`secrets/core.key` from the Core host into that installation's `secrets/core.key`
-(mode `0600`) and run its `oac apply`. Its `oac status` reports a key that Core
-refuses. `rotate-core-key` refuses to run on a Web-only installation.
+It refuses while `config.json` has changes that are not applied or a generated file was edited by hand: run `oac apply` first. It asks for confirmation (`--yes` skips it), stops Web, writes a new key to `secrets/core.key` and regenerates the digest file. On a running installation it then restarts Core, starts Web and checks that Core accepts the new key and refuses the old one; a stopped installation only gets the new files and uses the new key at the next `oac start`. The old key stops working as soon as Core restarts, and every console session ends: sign in again and update your scripts. If the command stops early, `secrets/core.key` holds the key to use; run `oac apply` to finish.
+
+A separate Web-only installation keeps its own copy of the key. After rotating, copy `secrets/core.key` from the Core host into that installation's `secrets/core.key` (mode `0600`) and run its `oac apply`. Its `oac status` reports a key that Core refuses. `rotate-core-key` refuses to run on a Web-only installation.
 
 ## Projects and API keys
 
-Create Projects and issue keys in Web, on **Projects and keys**, or through the
-[Core API](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/admin-api.md) under `/core/v1/projects`. How
-Projects and keys behave is in [Projects own assets](/concepts#projects-own-assets).
+Create Projects and issue keys in Web, on **Projects and keys**, or through the [Core API](#script-the-core-api). How Projects and keys behave is in [Projects own assets](/concepts#projects-own-assets).
 
 To rotate an application key:
 
@@ -134,117 +119,69 @@ To rotate an application key:
 
 **Archive** disables every key of a Project and keeps its assets.
 
-## Data and current-release repair
+Core records which key made each public resource write; the retention of that history is [`core.write_audit_retention`](/configure#settings).
 
-### Back up
+## Back up
 
 Back up these together; a restore needs all of them:
 
-- the PostgreSQL volume `<project>_database`. It holds Projects, key digests, nodes,
-  default models, encrypted credentials and all execution history, including large
-  objects. A logical dump:
+- the PostgreSQL volume `<project>_database`. It holds Projects, key digests, nodes, default models, encrypted credentials and all execution history, including large objects. A logical dump:
 
   ```sh
   docker compose -f "$HOME/.oac/core/generated/compose.json" exec -T database \
     pg_dump -U agents_api agents_api > oac-backup.sql
   ```
 
-- the installation directory: `config.json`, `state.json` (installation ID) and
-  `secrets/`. `credential.key` must stay with the database, or stored credentials can't
-  be decrypted; never regenerate it to get past an error.
+- the installation directory: `config.json`, `state.json` (installation ID) and `secrets/`. `credential.key` must stay with the database, or stored credentials can't be decrypted; never regenerate it to get past an error.
 - `state/e2b/`, when E2B is used: receipts Core needs to clean up E2B sandboxes.
-- each node's state directory on its host,
-  `/var/lib/oac-node/.oac/nodes/<installation-id>/`,
-  with its provider storage: Docker
-  volumes or microsandbox's store.
-- the bundle you installed from, to repair or recover the same release.
-
-A missing node state directory is a recovery incident: restore it with the database
-and provider storage rather than registering over existing resources. Never prune
-Docker volumes or delete native history to make a retry pass. A deleted Session does
-not prove that all provider resources were reclaimed.
+- each node's state directory on its host, `/var/lib/oac-node/.oac/nodes/<installation-id>/`, with its provider storage: Docker volumes or microsandbox's store. See [when a node host fails](/hosted-providers#when-a-node-host-fails) for restoring them.
+- the bundle you installed from, to repair the same release.
 
-### Installation version policy
+Never prune Docker volumes or delete native harness history to make a retry pass. A deleted Session does not prove that all provider resources were reclaimed.
 
-In-place version upgrades, downgrades and historical conversions are not supported.
-Keep existing data and installations intact; install the new release into a new,
-empty directory. There is no automatic data migration or history conversion.
+## Installation version policy
 
-Repair the current release with `./install.sh --install-dir DIR` from the exact
-same bundle. Repair preserves identity, settings, secrets and history. The installer
-and mutating `oac` commands use the same installation lock, including during repair
-and interrupted apply recovery. If another command owns it, retry after it finishes.
-Never remove or replace `.oac.lock` to bypass a busy installation.
+An installation runs one release for its whole life. In-place version upgrades, downgrades and historical conversions are not supported. Nothing migrates data between releases.
 
-Reinstallation never deletes another installation's files, database, Runtime
-resources or Session history.
+To move to a new release, install it into a new, empty directory, with its own database, Core key and nodes, and add nodes from its Web. Keep the old installation, its data and its nodes until their work is finished. Nodes run the program of the console that added them and are never upgraded in place; Core accepts only nodes that speak its own node protocol.
 
-### Machine connections
+Repair the current release by rerunning `./install.sh --install-dir DIR` from the exact same bundle; the downloader keeps it under `~/.oac/releases/`. Repair reloads missing images, restores the `oac` command, applies `config.json` and starts the services. It preserves identity, settings, secrets and history, accepts only `--install-dir`, and refuses a bundle from another release.
 
-Core and its nodes must come from the same distribution; the node installer refuses
-a mismatched release. Route `/api/v1/*`, including WebSocket upgrades, to Core;
-Web returns 404 there. This applies to Docker and microsandbox nodes, E2B and
-self-hosted executors. See
-[HTTPS and the reverse proxy](/install#https-and-the-reverse-proxy).
+The installer and mutating `oac` commands hold the same installation lock, `.oac.lock`, including during repair and interrupted apply recovery. If another command holds it, retry after that command finishes; never remove or replace `.oac.lock` to get past a busy installation. Reinstallation never deletes another installation's files, database, Runtime resources or Session history.
 
 ## Troubleshooting
 
 | Symptom | Cause and fix |
 | --- | --- |
 | `Core installation requires Linux amd64 with Docker access` | Use Linux amd64 and an account with Docker access; root and ordinary users are supported |
-| `Installation failed; inspect prerequisites and private deployment files` | A prerequisite failed without its own message, most often Docker: check that `docker info` and `docker compose version` work for this user |
+| `Installation failed: inspect prerequisites and private deployment files` | A prerequisite failed without its own message, most often Docker: check that `docker info` and `docker compose version` work for this user |
 | `Docker Compose 2.26.0 or newer is required …` | Update the Docker Compose plugin |
 | `Port N is already in use; select another port` | Free the port, or install with `--core-port`/`--port` |
 | `Installation directory is not empty …` | Use an empty `--install-dir` |
 | `This installation is configured by …/config.json …` | Flags only seed a new installation: edit `config.json` and run `oac apply` |
-| `This installation version or historical conversion is not supported …` | Preserve the installation and data; [install separately](#installation-version-policy) |
+| `This installation version or historical conversion is not supported …` | The target directory holds an installation of another release, or a default install found one at `~/.parsar/core`. Keep it, and install into another empty `--install-dir` ([version policy](#installation-version-policy)) |
 | `generated/<file> was edited by hand` | Put the change in `config.json`, then `oac apply --discard-edits` |
 | `config.json has changes that are not applied` | Run `oac apply` |
 | `Core rejects secrets/core.key …` | Run `oac apply`, which restarts Core with the key's digest |
 | `config.json not applied: …` | `oac apply` printed Core's startup error above; fix `config.json` and apply again |
-| Web answers 403 `Forbidden` | Open exactly the console address `oac status` prints; the reverse proxy must pass the original Host |
-| `/v1` or `/api/v1` answers 404 | Those paths reach Web; route them to Core ([reverse proxy](/install#https-and-the-reverse-proxy)) |
+| `HTTPS verification failed …` during domain setup | See [Configure the domain and HTTPS](/install#configure-the-domain-and-https) |
+| Web answers 403 `Forbidden` | Open exactly the console address `oac status` prints; a reverse proxy must pass the original Host |
+| `/v1` or `/api/v1` answers 404 | Those paths reach Web; route them to Core ([reverse proxy](/install-options#https-and-the-reverse-proxy)) |
 | Web shows that Core is unavailable (502) | Core is stopped or failing: `oac status`, then Core's log |
 | Session creation returns 400 `model_provider_required` | No model provider: set a [default model](/configure#default-models) for the harness, or pass one; self-hosted Sessions always pass their own |
-| Add node says nodes need an HTTPS public URL | Set `public_url` and run `oac apply` |
-| Add node says the console has no node files | Install from the offline bundle, or add the node files and rerun `./install.sh` |
+| Add node shows no command | See [Before you add a node](/hosted-providers#before-you-add-a-node) |
 | A node is not ready | See [node troubleshooting](/hosted-providers#troubleshooting) |
 
 ## Exposure and network policy
 
-Core and Web listen on host loopback; PostgreSQL has no published port unless Core is
-native. Your TLS reverse proxy routes `/v1` and `/api/v1` to Core and everything else to
-Web. Web signs administrators in with the Core key, checks the origin of every request,
-and forwards signed-in `/core/v1` requests to Core with the Core key, which stays on
-the server. It answers 404 on `/v1` and `/api/v1` whatever credential a request carries,
-serves only the non-secret node payload at `/node-install/`, and has no Docker or KVM
-access. Machine routes keep their own enrollment and connection credentials. Web
-sign-in sessions live in Web's memory and last 12 hours.
-
-microsandbox uses an explicit network policy: public egress, the Core and DNS ports the
-Runtime needs, and no inbound or private-network access. Private model or MCP endpoints
-need an explicit policy change. The daemon does not enforce Session-level
-`disabled` or `restricted` networking. Combinations without the required outer
-network enforcement are unsupported; a requested mode is not an isolation guarantee.
-
-Docker isolates the Runtime at the outer container boundary. The daemon does not
-add an inner filesystem, permission or network sandbox. The node's service account
-needs the host's Docker daemon, and Core has no Docker socket. Install nodes on
-trusted hosts and do not share their Docker access with untrusted users.
-
-A Core restart leaves node services and resident microVMs running. A host reboot, the
-end of a user manager or the loss of a running microVM is not a Core restart and is not
-a qualified recovery workflow. Idle snapshots keep their recovery contract.
-
-### API-key write history
-
-Core records which key made each public resource write, for the console. Set
-`core.write_audit_retention` in `config.json` (Go duration, at least `1h`, default
-`2160h`) to control how long non-creation history is kept; creation ownership is kept
-for good. Removing keys or resources does not delete these records. See the
-[query contract](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/write-audit.md); administrator mutations
-have a separate
-[audit log](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/contracts/agents-api/admin-api.md#monitoring-and-audit). Neither
-logs bodies or secrets.
+| Listener | Managed ingress (default) | External ingress |
+| --- | --- | --- |
+| Web | Reached only through the `gateway` service, which publishes `ports.web` (8080), 80 and 443 on `host` (all IPv4 interfaces by default) | `host:ports.web` (loopback by default), behind your reverse proxy |
+| Core | `127.0.0.1:ports.core` (8091); the gateway routes `/v1` and `/api/v1` to it | `host:ports.core`, behind your reverse proxy |
+| PostgreSQL | No published port | No published port, or a loopback port with native Core |
+
+Web signs administrators in with the Core key, checks the origin of every request, and forwards signed-in `/core/v1` requests to Core with the Core key, which stays on the server. It answers 404 on `/v1` and `/api/v1` whatever credential a request carries, serves only the non-secret node payload at `/node-install/`, and has no Docker or KVM access. Machine routes under `/api/v1` use their own enrollment and connection credentials. With managed ingress, the `installation` service applies domain changes through the Docker socket; Web reaches it only over a private Unix socket, and it checks the Core key on every request.
+
+Sandboxes are the isolation boundary ([Runtime and outer isolation](/concepts#runtime-and-outer-isolation)). Docker sandboxes share the node's kernel, and a Docker node is [root-equivalent](/hosted-providers#what-the-installer-sets-up) on its host; microsandbox gives each sandbox a microVM with an explicit [network policy](/hosted-providers#what-the-installer-sets-up). Core itself has no Docker socket or KVM access.
 
 [Repository source](https://github.com/MiniMax-AI/parsar-core/blob/f6d258735fc601c521dd990e6f9e1ed261f4ef2d/docs/getting-started/operations.md)
diff --git a/apps/docs/content/guide-sources.json b/apps/docs/content/guide-sources.json
index c9eac5446..b22e342ef 100644
--- a/apps/docs/content/guide-sources.json
+++ b/apps/docs/content/guide-sources.json
@@ -1,62 +1,62 @@
 {
   "revision": "f6d258735fc601c521dd990e6f9e1ed261f4ef2d",
   "sources": {
-    "docs/getting-started/README.md": "7b7f82e484a20d7847e970c2192709091107b6acc253709c9f38ef91caeabcf1",
+    "docs/getting-started/README.md": "d93c270e208fdf84edaf71827ed635a017be8cf67e0a4afef7279e3945d53173",
     "docs/design-principles.md": "334e0d477c255552f874f3ca8a2db603d0d07892ad7d58930bf8e3d06b86c636",
     "docs/web/architecture.md": "cf694aa624cf6078a154c2f8fdd67055d41dea0c0bb80b8dc8f0cdbc5d572fb1",
-    "docs/getting-started/install.md": "84b21002136acd4f006392685b7a071323336e87c1aac6e3c23ca56acb40833c",
-    "docs/getting-started/install-options.md": "e03487bb6d978f84c596467028e25fd99fdc21cf2060af24ceb68df885084798",
-    "docs/configuration.md": "7dc0031145bb5811bf22cab15270b511b1c43b1bd1ee2b71175d3bc848751bd6",
+    "docs/getting-started/install.md": "16a77eeeefeb608e329df63318edcc9e111c37273c27c0994054ab5c659fa1bc",
+    "docs/getting-started/install-options.md": "51fb99f87310f137ee3842137f69d181d15547f1121b0ba43765f990ef1cbd25",
+    "docs/configuration.md": "c4034b1b36c065f3e11afce355338a9d8b54c8af0728b24990cba3f282c5d8e9",
     "docs/web/core-connection.md": "861c75c32676fd17b84eb356b263096703af5750c1ceb71bb339e84607fffc56",
-    "docs/getting-started/quickstart.md": "b989682ac2e58d59a794118fd371b37d1ea64c957d3512ff53739458a95d0f9a",
-    "docs/api/README.md": "faada41906e584a2dfcd1efb0af893e6039cd456eff989f019e0dd816dc419ff",
+    "docs/getting-started/quickstart.md": "51374df1c86cc3376a92da4599915818d05b94863d728b234bd12be445d1156d",
+    "docs/api/README.md": "319c1dc63a23864b1324e5c98df7bfc95da60070465a62ec2e6958994e11a5d0",
     "contracts/agents-api/execution-tools.md": "fe1e3cf471fe9c7ef04afa7230e6b7742fbf2146c74bd944a7a22d5d4d4197da",
     "docs/api/public-agent-api.md": "e1111aaf5215392178246969e281b930374b22ee380d529b08b2482836d6333d",
     "docs/examples.md": "c12c34adc5b2fa57c81602b23d8ecc8317596f9c5a4aedbf1f1fe934a08a94f5",
-    "contracts/agents-api/environments.md": "2f4d506d7353c3ab4734bd2c06216dbac231d951e95e397171e793d74dc535b0",
-    "docs/getting-started/nodes.md": "7c1b7e364ce85b5b5916358cafc618f29042b2125ac45653be665ba07e772fdb",
+    "contracts/agents-api/environments.md": "404cdc48ce09bb61729c7808bc2a79c5493ffbdb0f230f871d47160522798de8",
+    "docs/getting-started/nodes.md": "395d04a29b95a9299a2474d76955d65e66edebdfd5bf3d8ce798e1bbda223148",
     "docs/getting-started/self-hosted.md": "653a9132ea6bbc39186f7917fa1596027d091071172e6a6afd9f618fc1dab725",
     "apps/web/public/onboarding/monitor-en.webp": "29dc220cb1250c7016b7c4bf7f30e9510b07c07b814a48c3aa9303b2d76f20b2",
     "docs/web/README.md": "47159689b2488f0a94a1af8488bcf98b465e0cca4003d64a4699d7b4db24e086",
-    "docs/api/web-management.md": "fc064c53874ca2aa6d17e5265763a4a4c744860062c27353cfafe74d3e6ac790",
+    "docs/api/web-management.md": "efba58e8d38734e167e767d2c75d5991202d97f519ec1829d2e531b0e3ea4af2",
     "contracts/agents-api/runtime-observability-api.md": "cd46e777fe716a7e76374f4655c96dfbad9d8be1bfca6203ed6118ab87874c2b",
-    "docs/getting-started/operations.md": "4069e89deed7ef619f28cc8d9779055669246eabe322089113ac3a786c3cb2d5",
+    "docs/getting-started/operations.md": "5cf3f4c6fa26b6445645c501ed53f78f450e9d9a31667166afebfaf02131f9a7",
     "docs/user-guide.md": "078ad930003dd333e65beb152dab11809b08d58dcc9d5d108c61f60dc3a320e2",
     "docs/assets/development-architecture.png": "24e6d0145d4f16ad70b07b6bc643808a6455aaf6398434d199cf74def200fca6",
     "docs/development.md": "f5c340253036a2cabc43e22aecdf70522d90280d6511e7649278ae93712ab8b6",
     "contracts/agents-api/harness-onboarding.md": "03b069b0c2ae18248cf6b1d1c82b6c3a6cd74719746bd343acb128a86d2c67a2",
     "docs/runtime-bootstrap.md": "0d49aed73b298039e04453e6f465b0e925fb2227fa35d4206820bb3acbd8df39",
     "docs/runtime-protocol.md": "4bce016e8ec239281969c84c8483044cf3247051eb062ec30d3effa00b661001",
-    "docs/sandbox-provider.md": "a1323c7f6a28a4f5f0e823274c08422707a5dab85b11e008ccb28a3aafc02058",
-    "apps/docs/scripts/guides.json": "19265370dbcb8e30b125079d0d25fad05b6f783ec368b7ebb6e81389b7853342"
+    "docs/sandbox-provider.md": "7c05d1799fa027897451032ee444ab01e444795030659da59ff33ac03d45ab18",
+    "apps/docs/scripts/guides.json": "219d019f1cc36756eb178306a07fe1fe2bc643d1d05a169abdedab5632d5aa85"
   },
   "outputs": {
-    "content/docs/index.mdx": "bf78e8aab0a834fb62ee7287fef3e29363b7384e63ec61aefcf7448f65a71a80",
+    "content/docs/index.mdx": "55c6f5320b163a46dc74c705581cc34416766132b9fb10b0f5a1cf5832b46f2f",
     "content/docs/concepts.mdx": "b9aceda2f72f3f1239e5518c3cecff8c9c0aa11a3eb622ddf9db6af2984a1abc",
     "content/docs/execution-model.mdx": "7b8d8498a1b157270f00a8c370c9a86547fa481df9ffa8904c810946b1626b38",
-    "content/docs/install.mdx": "6c3ec01d1b80cbce35d58e3f141b0fa832d6294a2ecc07c3b286ecc56ba66919",
-    "content/docs/install-options.mdx": "aaafc209293a905d5b433511149aa1f0cc422bd31d5bb5b6cd7eec0d532ab8eb",
-    "content/docs/configure.mdx": "02d1eee789646fdf65ed2ec48b6fe954c81107d6ff5891536ec6ac2df0a8c4dc",
+    "content/docs/install.mdx": "90cd9f76a0ef5116363c2d20ad21465171bd0dca55f9d5d9b0df443cc3c844b3",
+    "content/docs/install-options.mdx": "090f8840f5c164f41d6438b7b403c406ea1b7c0d695adbca3c3f06ba2193a5aa",
+    "content/docs/configure.mdx": "e0e335aba3b37273fb3f540c9ac3a669596ddfddf93380acdc0b2f836a942a6f",
     "content/docs/bootstrap-projects-keys.mdx": "91a6f62cbe41737adfce9e8ec56e6dc3e2fb0ec8f6b677576f941cdfb378dc47",
-    "content/docs/quickstart.mdx": "d0ab9537ab68f6dd3109353e937a29c5d58ec3894b56a52873c9a1d79dfa60a6",
-    "content/docs/public-api.mdx": "cc0bad7611eb2c4f1d7ec231a3f77c37989e268b76423f292eee88ccf25eb892",
+    "content/docs/quickstart.mdx": "e389d12e7417456494b67047fa5de922678634539154bd6486ff424b08344126",
+    "content/docs/public-api.mdx": "62d2ed6b5ddb71fd04ab2bfc62fe770b89b8100c0bb1877fdfdf68c70e7bbd10",
     "content/docs/agents-and-tools.mdx": "3ca16d2e2ff1c759251fbdf6e071ff09a93d5efc7acaca36a48854597d4f9576",
     "content/docs/sessions.mdx": "e8693563738f690c21be92e0ea09e925528bc85bea2c0fb4799c3f1c4074cfba",
     "content/docs/examples.mdx": "5f1dde8043695c40edf775345159d93b2444d5ce6a109829b78678b0b5de0d46",
-    "content/docs/environments-and-files.mdx": "a51751d78649cbd5af3458890efd360a857f82538de889d6419a458d01b2a02d",
-    "content/docs/hosted-providers.mdx": "9c241090709a9929ab6a34615db1e20a94c1f36649026281836060e81ac40b4c",
+    "content/docs/environments-and-files.mdx": "6a59efd3c4b2f37b389b3801c596efccef5128cae65d9b56b47cdd2e1a417b13",
+    "content/docs/hosted-providers.mdx": "da86d65fe1fa44f27600c3a0ea61e4954f894339724310be972d5e2bc03163e5",
     "content/docs/self-hosted-execution.mdx": "a8e6500e41c666eacb2c75882b2b8ee0cf122fe19ea36f39ef89f5dcf17b68e1",
     "public/images/source/apps/web/public/onboarding/monitor-en.webp": "29dc220cb1250c7016b7c4bf7f30e9510b07c07b814a48c3aa9303b2d76f20b2",
     "content/docs/console.mdx": "a930ce36035de74f0c2bef71bed067fc2287ba1c70a485758bf100d484f6adfd",
-    "content/docs/admin-api.mdx": "6fcfe4c5b5b70d5322c131ce4ab70f1a7ea8b0033a5f500b20cf27abb338236e",
+    "content/docs/admin-api.mdx": "52bfea0ffc4d1e3bd1b9e476c32250e787e82b1d167c2343e662d7550b6a64e9",
     "content/docs/observability.mdx": "c81214e1865517a9163c48c7ce7c396f5490c9d162080dfa05fa5ebc147f6c8b",
-    "content/docs/troubleshooting.mdx": "bccd725d2389a80b66caf1a1da80532bd68dd3d470bf851799d0114f84e0af25",
+    "content/docs/troubleshooting.mdx": "cf5b9e9d28fe9b56146bccc8e43d1804b3c6c5cc8ff2bb345aa4a3961329e838",
     "content/docs/user-guide.mdx": "92b839c8d1a2fbf4d35388c414c4524734f32724c30c07395edc994fa11cf702",
     "public/images/source/docs/assets/development-architecture.png": "24e6d0145d4f16ad70b07b6bc643808a6455aaf6398434d199cf74def200fca6",
     "content/docs/development.mdx": "2e5249ddfca571d264e93fd1e0e390a4bd5b0b623bda100cd02f2982929850bb",
     "content/docs/harness-onboarding.mdx": "e434d62bd0b558745774c8d729e4d86d2b40ed3026e3d77b777c48aef141c659",
     "content/docs/runtime-bootstrap.mdx": "58982955811c9ad46a9fc04d8d2aef5a762fc9d25d5833f88aa75ee3fc46523f",
     "content/docs/runtime-protocol.mdx": "560f887d5fc9fa673275a6481220f5fb997c4ece30c09384b81b14dbc7aa0dd4",
-    "content/docs/sandbox-provider.mdx": "83a6244fb2140836aa6746c990c9cd04d04e58d5b3a52faf1a84e5e846dfd99f"
+    "content/docs/sandbox-provider.mdx": "c492be921a1b99c97a73c52d740f061533b174f6ce3023a60feb06087a579564"
   }
 }
diff --git a/apps/docs/scripts/guides.json b/apps/docs/scripts/guides.json
index 165a78af6..f3dc9bab8 100644
--- a/apps/docs/scripts/guides.json
+++ b/apps/docs/scripts/guides.json
@@ -21,13 +21,13 @@
     "slug": "install",
     "source": "docs/getting-started/install.md",
     "title": "Install Core and Web",
-    "description": "Current distribution, host prerequisites, HTTPS, first sign-in and installation options."
+    "description": "Host prerequisites, installation, HTTPS, first sign-in, a default model and the first Project API key."
   },
   {
     "slug": "install-options",
     "source": "docs/getting-started/install-options.md",
-    "title": "Installation options",
-    "description": "Listener addresses, ports and initial installation choices."
+    "title": "Installation options and advanced deployments",
+    "description": "Installer flags, sandbox backends, listeners, reverse proxies, split and native deployments and offline hosts."
   },
   {
     "slug": "configure",
diff --git a/apps/docs/scripts/verify-docs-facts.mjs b/apps/docs/scripts/verify-docs-facts.mjs
index fce27c13d..4c246c4cf 100644
--- a/apps/docs/scripts/verify-docs-facts.mjs
+++ b/apps/docs/scripts/verify-docs-facts.mjs
@@ -18,10 +18,10 @@ const source = slug => fs.readFileSync(path.join(app, 'content/docs', slug + '.m
 for (const token of ['/v1', '/core/v1', '/api/v1', 'Project API key', 'Core key', 'executor']) assert.ok(source('public-api').includes(token), 'Credential matrix omits ' + token)
 for (const token of ['config.json', 'oac apply']) assert.ok(source('configure').includes(token), 'Configuration guide omits ' + token)
 for (const token of ['oac-node', '/var/lib/oac-node/.oac/nodes', 'Node installation and removal require root.']) assert.ok(source('hosted-providers').includes(token), 'Node guide omits ' + token)
-// Keep the installation policy visible in the operator guides.
+// Keep the installation policy visible in its operator guide; the node guide links to it.
 for (const [slug, tokens] of [
   ['troubleshooting', ['In-place version upgrades, downgrades and historical conversions are not supported.', '.oac.lock']],
-  ['hosted-providers', ['Node program version updates are not supported.', '`--update` refuses']],
+  ['hosted-providers', ['/troubleshooting#installation-version-policy']],
 ]) for (const token of tokens) assert.ok(source(slug).includes(token), 'Installation policy drift in ' + slug + ': ' + token)
 for (const file of fs.readdirSync(path.join(app, 'content/docs')).filter(n => n.endsWith('.mdx'))) {
   const text = fs.readFileSync(path.join(app, 'content/docs', file), 'utf8')
diff --git a/contracts/agents-api/README.md b/contracts/agents-api/README.md
index 589ca69e1..120b8f8eb 100644
--- a/contracts/agents-api/README.md
+++ b/contracts/agents-api/README.md
@@ -65,7 +65,7 @@ still differ. See the [accepted scope and evidence](#accepted-milestone-and-evid
 The same three harnesses passed historical Core-managed E2B V1 qualification in
 PR #705. That original route is historical evidence; it does not qualify the later
 user-managed enrollment or current deployment-level E2B configuration. See the
-[current hosted provider contract](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md). The [user-managed V1 qualification](user-managed-runtime-v1.md)
+[current hosted provider contract](sandbox-deployment.md). The [user-managed V1 qualification](user-managed-runtime-v1.md)
 records separate real deployment acceptance and its exact scope.
 Select further work only within current user authorization. Parsar cutover and
 business Team orchestration are separate from protocol coverage.
@@ -168,7 +168,7 @@ new model-issued command after a recovery prompt, not automatic API replay.
 
 This is historical evidence for the original Core-managed E2B route. Current
 deployment-level E2B configuration is documented in the
-[Hosted Sandbox Manager](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md).
+[sandbox deployment contract](sandbox-deployment.md).
 This older run does not qualify later enrollment/configuration changes or transfer
 caller-owned compute to Core.
 
diff --git a/contracts/agents-api/environments.md b/contracts/agents-api/environments.md
index 1f1ebfaea..62cc14360 100644
--- a/contracts/agents-api/environments.md
+++ b/contracts/agents-api/environments.md
@@ -8,7 +8,7 @@ Session may instead select its exact canonical physical directory. The
 [recorded deployment qualification](user-managed-runtime-v1.md) retains its historical
 source, paths and tested capability scope.
 For hosted compute, the deployment selects E2B, Docker or microsandbox through
-[Hosted Sandbox Manager](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md).
+[sandbox deployment](sandbox-deployment.md).
 For the separate caller-managed E2B path, the user owns allocation, renewal and
 cleanup through the official SDK and [Runtime packaging](../../services/agents-api/deploy/e2b/README.md).
 [Templates](environment-templates.md) provide reusable preparation; the Core extension also applies their execution configuration to user-managed machines;
diff --git a/contracts/agents-api/runtime-observability.md b/contracts/agents-api/runtime-observability.md
index d4c4cd9cb..cc1a4cb19 100644
--- a/contracts/agents-api/runtime-observability.md
+++ b/contracts/agents-api/runtime-observability.md
@@ -148,7 +148,7 @@ Core restart and browser reload without replaying execution.
 
 See the [design](runtime-observability-design.md),
 [current API](runtime-observability-api.md), [history API](runtime-history-api.md)
-and [configuration](../../services/agents-api/runtime-history/README.md).
+and [configuration](../../docs/configuration.md#settings).
 Additional provider telemetry and idle-policy authority remain separate work.
 
 The OTLP resource identifies Core with `service.name=oac-core` and
diff --git a/contracts/agents-api/sandbox-deployment.md b/contracts/agents-api/sandbox-deployment.md
index 7bef7f43f..1060dc558 100644
--- a/contracts/agents-api/sandbox-deployment.md
+++ b/contracts/agents-api/sandbox-deployment.md
@@ -10,7 +10,7 @@ The public `/v1` Agent API, Environment Templates and caller-managed `self_hoste
 provisioning are unchanged. A provider selection is independent of the harness.
 A deployment can remain unconfigured, with no execution nodes or hosted admission.
 
-See [Hosted Sandbox Manager](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md)
+See [Nodes](../../docs/getting-started/nodes.md)
 for the operator workflow. Generated schemas cover the
 [administrator routes](core.openapi.yaml) and the
 [node machine connection routes](runtime.openapi.yaml).
@@ -27,6 +27,9 @@ for the operator workflow. Generated schemas cover the
 | `POST /core/v1/sandbox/e2b/templates` | Core Web server or operator script with Core key | List up to 200 templates visible to a transient E2B credential |
 | `POST /core/v1/sandbox/e2b/templates/{template_id}/builds` | Core Web server or operator script with Core key | List up to 200 ready builds for one selected template |
 | `GET /api/v1/sandbox-node/configuration` | Enrollment token or retained node credential | Read the active node installation configuration without consuming enrollment |
+| `POST /api/v1/sandbox-node/enroll` | One-use enrollment token | Register a node; consumes the token |
+| `GET /api/v1/sandbox-node/identity?node_id=` | Node credential | Recover the node's registered identity, approved capacity and readiness |
+| WebSocket `GET /api/v1/sandbox-node/connect?node_id=` | Node credential | The node's connection to Core |
 
 Template discovery posts `{ "api_key": "...", "api_url": "https://sandbox.sandbase.ai", "domain": "sandbox.sandbase.ai" }`.
 The official E2B endpoint may omit both endpoint fields. The first response is
@@ -497,7 +500,7 @@ classifies the first failed readiness check and sends only the code; Core stores
 any other value as `provider_unavailable` and never stores or returns probe error
 text or host paths. Core and nodes must use the same distribution; unknown-code
 handling does not establish cross-version compatibility. See
-[Node readiness diagnostics](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md#node-readiness-diagnostics)
+[Readiness codes](../../docs/getting-started/nodes.md#readiness-codes)
 for causes, precedence and operator actions.
 
 Core rejects `AGENTS_API_MANAGED_RUNTIMES_FILE`. A node provider file remains an
diff --git a/contracts/agents-api/user-managed-runtime-v1.md b/contracts/agents-api/user-managed-runtime-v1.md
index 1c48b6a80..3e8841ab1 100644
--- a/contracts/agents-api/user-managed-runtime-v1.md
+++ b/contracts/agents-api/user-managed-runtime-v1.md
@@ -7,7 +7,7 @@ Environment ID, returned `remote_url` and scoped executor credential. This priva
 transport does not interoperate with stock Codex `exec-server` or Noise.
 
 For `openai_hosted`, Core uses the deployment-selected
-[E2B, Docker or microsandbox provider](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md).
+[E2B, Docker or microsandbox provider](sandbox-deployment.md).
 This document qualifies the separate caller-managed path: Docker and E2B use the
 same Runtime contract, but the application owns their compute. In that path, E2B
 create, information, renewal and deletion use the official E2B SDK outside Core. Public execution and
diff --git a/deploy/install/config.schema.json b/deploy/install/config.schema.json
index cfe508512..4d9937c4f 100644
--- a/deploy/install/config.schema.json
+++ b/deploy/install/config.schema.json
@@ -229,38 +229,38 @@
           "properties": {
             "transport": {
               "type": "string",
-              "description": "OTLP export transport.",
+              "description": "OTLP export transport: `otlp_http`. Required with endpoint.",
               "x-oac": {"restarts": ["core"]}
             },
             "endpoint": {
               "type": "string",
-              "description": "OTLP collector endpoint. Omit it to keep history local.",
+              "description": "OTLP/HTTP metrics URL: a canonical absolute URL with a path and no credentials, query or fragment; HTTPS, or HTTP with insecure. Omit it to keep history local; transport, insecure and headers then must be absent.",
               "x-oac": {"restarts": ["core"]}
             },
             "insecure": {
               "type": "boolean",
-              "description": "Export without TLS.",
+              "description": "Export without TLS. Required for an HTTP endpoint and refused for HTTPS.",
               "x-oac": {"restarts": ["core"]}
             },
             "headers": {
               "type": "object",
               "additionalProperties": {"type": "string"},
-              "description": "Headers sent with each export, such as credentials. Never shown by oac or Core.",
+              "description": "Headers sent with each export, such as credentials. Host, Content-Length, Content-Type and Content-Encoding are refused. Never shown by oac or Core.",
               "x-oac": {"sensitive": true, "restarts": ["core"]}
             },
             "queue_capacity": {
               "type": "integer",
-              "description": "Export queue capacity.",
+              "description": "Capacity of the history write queue and of the export queue, up to 4096. Omitted or 0 selects 256.",
               "x-oac": {"restarts": ["core"]}
             },
             "timeout_seconds": {
               "type": "integer",
-              "description": "Export and query timeout in seconds.",
+              "description": "History write, export and query timeout in seconds, up to 30. Omitted or 0 selects 2.",
               "x-oac": {"restarts": ["core"]}
             },
             "sample_interval_seconds": {
               "type": "integer",
-              "description": "Periodic sampling interval in seconds.",
+              "description": "Periodic sampling interval in seconds, 5 to 300. Omitted or 0 selects 30.",
               "x-oac": {"restarts": ["core"]}
             }
           }
diff --git a/docs/api/README.md b/docs/api/README.md
index 6f939f077..c99f90beb 100644
--- a/docs/api/README.md
+++ b/docs/api/README.md
@@ -8,14 +8,14 @@ public release content.
 | --- | --- | --- | --- | --- |
 | `/v1` | Applications (business systems, SDKs) | Project API key | Exactly the pinned official Agents API routes. Core-only fields live only in `x_agents_core` (`harness`, `model_provider`, `harness_config`, Session `installation`) | [Agents API guide](public-agent-api.md) |
 | `/core/v1` | Core Web's server and operator scripts | [Core key](../getting-started/operations.md#core-key) | Installation facts, Projects and keys, resource reads and deletion, Session archive, credential issuance, metrics, audit, sandbox deployment and nodes, deployment model providers | [Core API](#core-api), [Web API](web-management.md), [Core OpenAPI](../../contracts/agents-api/core.openapi.yaml) |
-| `/api/v1` | Nodes, Runtime daemons, self-hosted executors | Machine credentials: short-lived Session installation grants, node enrollment tokens and executor credentials issued through `/core/v1` or claimed by installation, node credentials registered with an enrollment token, and daemon credentials Core issues for hosted sandboxes | Machine bootstrap and connections: `/api/v1/sandbox-node/*` and `/api/v1/agent-daemon/*`, including WebSockets; each credential works only on its own routes | [Node operations](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md#register-a-host), [executor credentials](../../contracts/agents-api/environment-executor-credentials.md), [machine OpenAPI](../../contracts/agents-api/runtime.openapi.yaml) |
+| `/api/v1` | Nodes, Runtime daemons, self-hosted executors | Machine credentials: short-lived Session installation grants, node enrollment tokens and executor credentials issued through `/core/v1` or claimed by installation, node credentials registered with an enrollment token, and daemon credentials Core issues for hosted sandboxes | Machine bootstrap and connections: `/api/v1/sandbox-node/*` and `/api/v1/agent-daemon/*`, including WebSockets; each credential works only on its own routes | [Node routes](../../contracts/agents-api/sandbox-deployment.md#authority-and-routes), [executor credentials](../../contracts/agents-api/environment-executor-credentials.md), [machine OpenAPI](../../contracts/agents-api/runtime.openapi.yaml) |
 
 A credential used in another namespace gets 401: a Project API key on `/core/v1` or
 `/api/v1`, the Core key on `/v1` or `/api/v1`. How Projects and keys behave is in
 [Projects own assets](../design-principles.md#projects-own-assets).
 
 **Routing.** The reverse proxy sends `/v1` and `/api/v1` to Core and everything else
-to Web ([proxy setup](../getting-started/install.md#https-and-the-reverse-proxy)).
+to Web ([proxy setup](../getting-started/install-options.md#https-and-the-reverse-proxy)).
 Browsers reach `/core/v1` only through Web's server, which adds the Core key after
 sign-in; Web returns 404 for `/v1` and `/api/v1`. Operator scripts call `/core/v1`
 on Core's loopback port. Details: [Web and Core](web-management.md).
@@ -74,7 +74,7 @@ Errors use the [Core error envelope](../../contracts/agents-api/core-errors.md).
 | `projects/{project_id}/environments/{environment_id}/executor-credentials[/{key_id}]` | Executor credentials for a self-hosted Environment | [Executor credentials](../../contracts/agents-api/environment-executor-credentials.md) |
 | `installation` | Public URL, API base URL, source commit, the installer's process settings and what is bound to the public URL; available before any deployment | [Installation](../../contracts/agents-api/installation.md) |
 | `metrics` | Core's own process metrics | [Core metrics](../../contracts/agents-api/core-metrics.md) |
-| `sandbox/deployment[/reset]`, `sandbox/e2b/templates[/{template_id}/builds]`, `sandbox/enrollment-tokens`, `sandbox/nodes[/{node_id}[/allocations]]` | Sandbox deployment, read-only E2B template discovery, node enrollment tokens and nodes | [Sandbox deployment](../../contracts/agents-api/sandbox-deployment.md), [node operations](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md), [node host history](../../contracts/agents-api/node-host-history.md) |
+| `sandbox/deployment[/reset]`, `sandbox/e2b/templates[/{template_id}/builds]`, `sandbox/enrollment-tokens`, `sandbox/nodes[/{node_id}[/allocations]]` | Sandbox deployment, read-only E2B template discovery, node enrollment tokens and nodes | [Sandbox deployment](../../contracts/agents-api/sandbox-deployment.md), [nodes guide](../getting-started/nodes.md), [node host history](../../contracts/agents-api/node-host-history.md) |
 | `harnesses`, `harnesses/{harness}/model-configuration` | Supported harnesses and each harness's deployment default model configuration (write-only provider key) | [Model execution](../../contracts/agents-api/model-execution.md#deployment-defaults) |
 
 ## Machine connection API
@@ -84,9 +84,9 @@ the Core key or a Project API key.
 
 | Routes | Caller | Credential | Contract |
 | --- | --- | --- | --- |
-| `POST sandbox-node/enroll` | Node installer | One-use enrollment token from `POST /core/v1/sandbox/enrollment-tokens` | [Node operations](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md#register-a-host), [machine OpenAPI](../../contracts/agents-api/runtime.openapi.yaml) |
+| `POST sandbox-node/enroll` | Node installer | One-use enrollment token from `POST /core/v1/sandbox/enrollment-tokens` | [Node routes](../../contracts/agents-api/sandbox-deployment.md#authority-and-routes), [machine OpenAPI](../../contracts/agents-api/runtime.openapi.yaml) |
 | `GET sandbox-node/configuration` | Node installer and node | Enrollment token, or node credential with `X-OAC-Node-ID` | [Sandbox deployment](../../contracts/agents-api/sandbox-deployment.md), [machine OpenAPI](../../contracts/agents-api/runtime.openapi.yaml) |
-| `GET sandbox-node/identity`, WebSocket `GET sandbox-node/connect` | Node | Node credential registered at enrollment | [Node operations](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md#register-a-host) |
+| `GET sandbox-node/identity`, WebSocket `GET sandbox-node/connect` | Node | Node credential registered at enrollment | [Node routes](../../contracts/agents-api/sandbox-deployment.md#authority-and-routes) |
 | `POST agent-daemon/enroll`, `GET agent-daemon/connection` | Self-hosted executor and its installer | Executor credential from `/core/v1/projects/{project_id}/environments/{environment_id}/executor-credentials` | [Executor credentials](../../contracts/agents-api/environment-executor-credentials.md) |
 | WebSocket `GET agent-daemon/ws`, `POST agent-daemon/bootstrap`, `GET agent-daemon/device-status` | Runtime daemons | Daemon credential: Core writes one into each hosted sandbox it prepares; a self-hosted executor uses its executor credential | [Runtime enrollment](../../services/agents-api/README.md#user-managed-runtime-enrollment) |
 
diff --git a/docs/api/web-management.md b/docs/api/web-management.md
index a0ec241d0..48204dc2a 100644
--- a/docs/api/web-management.md
+++ b/docs/api/web-management.md
@@ -99,7 +99,7 @@ it is operational attribution, not per-key billing.
 ## Sandbox administration
 
 The [deployment configuration contract](../../contracts/agents-api/sandbox-deployment.md),
-[nodes and sandbox backends reference](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md)
+[nodes guide](../getting-started/nodes.md)
 and [generated OpenAPI](../../contracts/agents-api/core.openapi.yaml)
 define deployment and node operations:
 
diff --git a/docs/configuration.md b/docs/configuration.md
index a0aaa69a8..c5c5fe801 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -5,21 +5,13 @@ Every setting of a Core installation has exactly one home. There are two kinds:
 | Kind | Examples | Home | Change it with | Takes effect |
 | --- | --- | --- | --- | --- |
 | [Process settings](#process-settings-configjson) | Public URL, ports, logging, harnesses, execution concurrency, audit retention, OAuth origins, database pool, Runtime history export | `config.json` in the installation directory (default `~/.oac/core`) | Web domain setup or `oac domain` for managed HTTPS; otherwise edit the file, then run `oac apply` | `oac apply` restarts the services that read the changed settings |
-| [Runtime settings](#runtime-settings-web) | Sandbox backend and size, nodes, Projects and keys, default models, executor credentials | Core's PostgreSQL database | Web, or the Core API (`/core/v1`) with the Core key | Saved without a Core restart; node Runtime changes prepare asynchronously |
+| [Runtime settings](#runtime-settings-web) | Sandbox backend and size, nodes, Projects and keys, default models, executor credentials | Core's PostgreSQL database | Web, or the Core API (`/core/v1`) with the Core key | Saved without a Core restart; nodes prepare Runtime changes asynchronously |
 
-Web's **System** page shows both: the installation's addresses, the process settings
-read-only under **Startup settings**, and managed HTTPS under **Domain and HTTPS** with the path of `config.json` and the apply
-command, the default models, and the sandbox configuration. Secrets live in
-[`secrets/`](#secrets-and-identity), one copy each. Each setting is set in one place;
-the files in `generated/` are only derived from `config.json`. No configuration file
-defines Projects or API keys.
+Web's **System** page shows the installation's addresses, the default models, the sandbox configuration and, under **Startup settings**, the process settings read-only with the path of `config.json` and the apply command. Secrets live in [`secrets/`](#installation-directory), one copy each. The files in `generated/` are derived from `config.json`. No configuration file defines Projects or API keys.
 
 ## Process settings: config.json
 
-The installer writes every setting that applies to the installation's
-[mode](getting-started/install.md#modes), so the file shows each value. Installer flags
-listed in [Installation options](getting-started/install-options.md) only seed it. To change a
-setting, edit the file and apply it:
+The installer writes every setting that applies to the installation's [mode](getting-started/install-options.md#modes), so the file shows each value. Installer flags listed in [installation options](getting-started/install-options.md) only seed it. To change a setting, edit the file and apply it:
 
 ```sh
 ~/.oac/core/oac apply --dry-run   # show the changed settings, files and restarts
@@ -28,59 +20,29 @@ setting, edit the file and apply it:
 
 ### How oac apply works
 
-1. It validates `config.json` and changes nothing if a value is invalid. `mode` and
-   `native_core` and `ingress` are fixed after installation; to change them, install into a new
-   directory.
-2. It writes the files Core, Web and Compose read into `generated/`: `compose.json`,
-   `core.env`, `core-key-digests.json`, `settings.json` and, when used,
-   `runtime-history.json`, the managed `Caddyfile` and the native Core unit. Don't edit them. A generated file
-   edited by hand stops `apply` until you move the change into `config.json` and run
-   `oac apply --discard-edits`, which keeps the edited copy as
-   `generated/<file>.edited-<time>`.
-3. It compares what it wrote with what actually runs. Each container carries a digest
-   of its inputs (the `io.oac.inputs` label; native Core carries `OAC_INPUTS`),
-   and `apply` recreates or restarts exactly the services whose inputs differ: Core
-   first, then Web. The **Restarts** column below says which services a setting
-   affects. Restarting Web signs everyone out of the console.
-4. While any service runs, `apply` also starts the stopped ones. After `oac stop`,
-   it only writes the files and the installation stays stopped.
-5. If Core refuses a value at startup, `apply` prints Core's startup error. If every
-   service was running with the previous files, it restores them and starts the
-   services again; otherwise it reports the failure, and the next `apply` finishes
-   the work.
-
-`oac status` reports changes to `config.json` that are not applied yet and
-generated files edited by hand.
+1. It validates `config.json` and changes nothing if a value is invalid. `mode`, `native_core` and `ingress` are fixed after installation; to change them, install into a new directory.
+2. It writes the files Core, Web and Compose read into `generated/`: `compose.json`, `core.env`, `core-key-digests.json`, `settings.json` and, when used, `runtime-history.json`, the managed `Caddyfile` and the native Core unit. Don't edit them. A generated file edited by hand stops `apply` until you move the change into `config.json` and run `oac apply --discard-edits`, which keeps the edited copy as `generated/<file>.edited-<time>`.
+3. It compares what it wrote with what actually runs. Each container carries a digest of its inputs (the `io.oac.inputs` label; native Core carries `OAC_INPUTS`), and `apply` recreates or restarts exactly the services whose inputs differ: Core first, then Web. The **Restarts** column below says which services a setting affects; see [stop and restart](getting-started/operations.md#stop-and-restart) for what a restart interrupts.
+4. While any service runs, `apply` also starts the stopped ones. After `oac stop`, it only writes the files and the installation stays stopped.
+5. If Core refuses a value at startup, `apply` prints Core's startup error. If every service was running with the previous files, it restores them and starts the services again; otherwise it reports the failure, and the next `apply` finishes the work.
+
+`oac status` reports changes to `config.json` that are not applied yet and generated files edited by hand.
 
 ### Changing the public URL
 
-`public_url` is the one origin that applications, nodes, sandboxes and self-hosted
-executors use; Core derives the daemon WebSocket URL, the self-hosted `remote_url` and
-each sandbox's connection address from it. With `null`, Core uses
-the configured loopback Core origin. The default managed installation still exposes
-Web by IP for setup; that initial HTTP endpoint does not expose the machine API.
-
-For managed ingress, use **System → Domain and HTTPS** or `oac domain HOSTNAME`.
-Both use the installation lock and the same `config.json`/`oac apply` operation.
-The installer verifies the certificate before switching addresses. External ingress
-uses a separately configured proxy and `oac apply`. When nodes, hosted
-sandboxes or self-hosted executors are bound to the current address, `apply` lists
-them and asks you to type the new URL (`--confirm-public-url-change URL` when not
-interactive). Afterwards, nodes on the old address get no new sandboxes: remove them
-in Web and add them again. Existing sandboxes and executors keep working only while
-the old address still reaches this Core, and `apply` warns that self-hosted executors
-must restart with the new `remote_url`. Their installer refuses to reuse an
-installation made for the old address, and moving an executor isn't supported yet:
-create new self-hosted Sessions and connect their hosts again. Update your reverse
-proxy first when using external ingress. A managed domain change replaces the
-previous domain route; reconnect clients and executors that still use it.
+`public_url` is the one origin that applications, nodes, sandboxes and self-hosted executors use. Core derives the daemon WebSocket URL, the self-hosted `remote_url` and each sandbox's connection address from it. With `null`, Core uses its loopback origin. Until `public_url` is set, a managed installation serves only Web, over HTTP on the host's IP address at `ports.web`; afterwards that address redirects to `public_url`.
+
+With managed ingress, change it in Web (**System** → **Configure domain and HTTPS**) or with `oac domain HOSTNAME`. Both take the installation lock, verify the new certificate and address, then write `config.json` and apply it. With external ingress, update your reverse proxy first, then edit `public_url` and run `oac apply`.
+
+When nodes, hosted sandboxes or self-hosted executors are bound to the current address, `apply` lists them and asks you to type the new URL (`--confirm-public-url-change URL` without a terminal). Afterwards:
+
+- Nodes on the old address get no new sandboxes: remove them in Web and add them again.
+- Existing sandboxes and executors keep working only while the old address still reaches this Core. A managed domain change replaces the previous domain route.
+- Self-hosted executors must restart with the new `remote_url`, and their installer refuses an installation made for the old address: create new self-hosted Sessions and connect their hosts again.
 
 ### Settings
 
-`core.runtime_history.headers` may hold export credentials. They stay in the
-`0600` `config.json` and the generated file Core reads, and never appear in `oac`
-output or in Core's settings snapshot. Model providers are not process settings; see
-[Default models](#default-models).
+`core.runtime_history.headers` may hold export credentials. They stay in the `0600` `config.json` and the generated file Core reads, and never appear in `oac` output or in Core's settings snapshot. Model providers are not process settings; see [Default models](#default-models).
 
 <!-- BEGIN config-reference: generated by scripts/config-reference.py from deploy/install/config.schema.json -->
 | Key | Type | Default | Modes | Change | Restarts | Meaning |
@@ -109,137 +71,88 @@ output or in Core's settings snapshot. Model providers are not process settings;
 | `core.database_pool.max_conn_idle_time` | string or null (Go duration) | `null` | `all`, `core-only` | `oac apply` | core | Go duration. null keeps the driver default, 30m. |
 | `core.database_pool.health_check_period` | string or null (Go duration) | `null` | `all`, `core-only` | `oac apply` | core | Go duration. null keeps the driver default, 1m. |
 | `core.runtime_history` | object or null | `null` | `all`, `core-only` | `oac apply` | core | Runtime history collection and OTLP export. null keeps local collection with Core's defaults. Core checks the values at startup. |
-| `core.runtime_history.transport` | string | none | `all`, `core-only` | `oac apply` | core | OTLP export transport. |
-| `core.runtime_history.endpoint` | string | none | `all`, `core-only` | `oac apply` | core | OTLP collector endpoint. Omit it to keep history local. |
-| `core.runtime_history.insecure` | boolean | none | `all`, `core-only` | `oac apply` | core | Export without TLS. |
-| `core.runtime_history.headers` | object of string values | none | `all`, `core-only` | `oac apply` | core | Headers sent with each export, such as credentials. Never shown by oac or Core. Sensitive. |
-| `core.runtime_history.queue_capacity` | integer | none | `all`, `core-only` | `oac apply` | core | Export queue capacity. |
-| `core.runtime_history.timeout_seconds` | integer | none | `all`, `core-only` | `oac apply` | core | Export and query timeout in seconds. |
-| `core.runtime_history.sample_interval_seconds` | integer | none | `all`, `core-only` | `oac apply` | core | Periodic sampling interval in seconds. |
+| `core.runtime_history.transport` | string | none | `all`, `core-only` | `oac apply` | core | OTLP export transport: `otlp_http`. Required with endpoint. |
+| `core.runtime_history.endpoint` | string | none | `all`, `core-only` | `oac apply` | core | OTLP/HTTP metrics URL: a canonical absolute URL with a path and no credentials, query or fragment; HTTPS, or HTTP with insecure. Omit it to keep history local; transport, insecure and headers then must be absent. |
+| `core.runtime_history.insecure` | boolean | none | `all`, `core-only` | `oac apply` | core | Export without TLS. Required for an HTTP endpoint and refused for HTTPS. |
+| `core.runtime_history.headers` | object of string values | none | `all`, `core-only` | `oac apply` | core | Headers sent with each export, such as credentials. Host, Content-Length, Content-Type and Content-Encoding are refused. Never shown by oac or Core. Sensitive. |
+| `core.runtime_history.queue_capacity` | integer | none | `all`, `core-only` | `oac apply` | core | Capacity of the history write queue and of the export queue, up to 4096. Omitted or 0 selects 256. |
+| `core.runtime_history.timeout_seconds` | integer | none | `all`, `core-only` | `oac apply` | core | History write, export and query timeout in seconds, up to 30. Omitted or 0 selects 2. |
+| `core.runtime_history.sample_interval_seconds` | integer | none | `all`, `core-only` | `oac apply` | core | Periodic sampling interval in seconds, 5 to 300. Omitted or 0 selects 30. |
 | `ingress` | `"managed"` \| `"external"` | `"external"` | all | fixed | none | managed provides automatic HTTPS and Web domain setup for a combined Docker installation; install.sh selects it by default. external uses your existing proxy. Fixed after installation. |
 <!-- END config-reference -->
 
-The schema is
-[`deploy/install/config.schema.json`](../deploy/install/config.schema.json); each
-installation keeps a copy in `generated/config.schema.json` for editors. Core serves
-the non-secret settings snapshot, with the path of `config.json` and the apply
-command, at `GET /core/v1/installation`.
+The schema is [`deploy/install/config.schema.json`](../deploy/install/config.schema.json); each installation keeps a copy in `generated/config.schema.json` for editors. Core serves the non-secret settings snapshot, with the path of `config.json` and the apply command, at `GET /core/v1/installation`. How Core collects and keeps Runtime history is in [retained history](../contracts/agents-api/runtime-observability.md#retained-history-and-optional-export).
 
 ## Runtime settings: Web
 
-Runtime settings live in Core's database. Change them in Web; scripts use the same
-Core API with the Core key.
+Runtime settings live in Core's database. Change them in Web; scripts use the same Core API with the Core key.
 
 | Setting | Where in Web | Core API | Notes |
 | --- | --- | --- | --- |
-| Sandbox backend: Docker, microsandbox or E2B | **System** → **Sandbox backend**: the setup wizard, ending with **Save configuration** | `/core/v1/sandbox/deployment` | One backend per deployment. `install.sh --sandbox` saves the first choice. Changing backend requires explicit reset and a new setup at the resulting generation |
-| Sandbox size and Runtime release | **System** → **Sandbox backend**: **Change resources** | `/core/v1/sandbox/deployment` | New targets use the saved size; retained generations keep their original specification. See [Sandbox deployment](#sandbox-deployment) |
-| E2B API key and template build | **System** → **Sandbox backend**: the setup wizard's **E2B cloud** | `/core/v1/sandbox/deployment` | The key is write-only and encrypted |
-| Nodes and their capacity | **Nodes**: **Add node**, **Edit node**, **Remove node** on a node's page (**Remove** in its list row) | `/core/v1/sandbox/enrollment-tokens`, `/core/v1/sandbox/nodes` | See [Node capacity](#node-capacity) and the [nodes guide](getting-started/nodes.md) |
+| Sandbox backend: Docker, microsandbox or E2B | **System** → **Manage sandbox configuration**: the setup wizard, ending with **Save configuration** | `/core/v1/sandbox/deployment` | One backend per installation. `install.sh --sandbox` saves the first choice. Another backend needs **Reset deployment** first; see [change the sandbox configuration](getting-started/nodes.md#change-the-sandbox-configuration) |
+| Sandbox size, Runtime release, E2B key and template build | **System** → **Manage sandbox configuration** → **Change resources** | `/core/v1/sandbox/deployment` | Web proposes the sizes in [`standard-sizes.json`](../apps/web/src/features/sandbox/standard-sizes.json). Existing sandboxes keep their size and release. The E2B key is write-only and encrypted |
+| Nodes and their capacity | **Nodes**: **Add node**; **Edit node** and **Remove node** on a node's page | `/core/v1/sandbox/enrollment-tokens`, `/core/v1/sandbox/nodes` | See [Node capacity](#node-capacity) and the [nodes guide](getting-started/nodes.md) |
 | Projects and API keys | **Projects and keys**: **Create project**, **Rename**, **Issue key**, **Revoke**, **Archive** | `/core/v1/projects` | Keys are shown once; Core stores digests |
-| Default model per harness | **System**: **Default model** | `/core/v1/harnesses/{harness}/model-configuration` | See [Default models](#default-models) |
-| Executor credentials of a self-hosted Session | **Session log**, the Session's page: **Executor credentials** | `/core/v1/projects/{project_id}/environments/{environment_id}/executor-credentials` | See [self-hosted executors](getting-started/self-hosted.md) |
-
-Which harnesses are enabled, and the default one, are process settings
-(`core.harnesses`, `core.default_harness`); System shows them read-only. The
-[API index](api/README.md#core-api) lists every Core API route.
-
-### Sandbox deployment
+| Default model per harness | **System** → **Default model configuration**: **Set** | `/core/v1/harnesses/{harness}/model-configuration` | See [Default models](#default-models) |
+| Executor credentials of a self-hosted Session | **Session log**, then the **Session** page: **Executor credentials** | `/core/v1/projects/{project_id}/environments/{environment_id}/executor-credentials` | See [self-hosted executors](getting-started/self-hosted.md) |
 
-Configure the backend and sandbox size in **System** → **Sandbox backend**.
-**Change resources** edits the deployment target; **Nodes** manages enrolled
-machines and their readiness.
-
-The [deployment contract](../contracts/agents-api/sandbox-deployment.md) owns
-provider-specific fields, limits, Runtime identity and online change/reset rules.
-The [node protocol](../contracts/agents-api/node-generation-protocol.md) owns
-generation preparation and wire compatibility. This page does not maintain
-another version table or set of provider rules.
-
-Web proposes sizes from
-[`standard-sizes.json`](../apps/web/src/features/sandbox/standard-sizes.json);
-the installer uses the bundle's copy of that source. For operator steps, see
-[changing the sandbox backend or size](getting-started/nodes.md#change-the-sandbox-backend-or-size).
+Which harnesses are enabled, and the default one, are process settings (`core.harnesses`, `core.default_harness`); System shows them read-only. The [API index](api/README.md#core-api) lists every Core API route, and the [deployment contract](../contracts/agents-api/sandbox-deployment.md) defines the sandbox fields, limits and change rules.
 
 ### Node capacity
 
-Core approves a node's capacity when you generate its Add node command: **Sandboxes at
-once** (`max_active`, default 2) and, for microsandbox only, **Retained sandboxes**
-(`max_retained`, default 8), with `max_retained >= max_active >= 1`. Docker never
-suspends sandboxes, so Web doesn't ask for it and Core keeps `max_retained` equal to
-`max_active`. Change them later with **Edit node**. Reservations and cleanup that is
-not confirmed count against capacity; lowering a limit stops no running sandbox. A
-node's own files can't change its capacity, size or Runtime.
+Core approves a node's capacity when you generate its Add node command: **Sandboxes at once** (`max_active`, default 2) and, for microsandbox only, **Retained sandboxes** (`max_retained`, default 8), with `max_retained >= max_active >= 1`. Docker never suspends sandboxes, so Web doesn't ask for it and Core keeps `max_retained` equal to `max_active`. Change them later with **Edit node**. Reservations and cleanup that is not confirmed count against capacity; lowering a limit stops no running sandbox. A node's own files can't change its capacity, size or Runtime.
 
 `core.execution_concurrency` is unrelated: it limits concurrent execution work in Core.
 
 ### Default models
 
-Set a default in **System** → **Default model**, or use
-`PUT /core/v1/harnesses/{harness}/model-configuration`. Core encrypts provider keys
-with `secrets/credential.key` and does not return them.
+Set a default in **System** → **Default model configuration**, or use `PUT /core/v1/harnesses/{harness}/model-configuration`. Core encrypts provider keys with `secrets/credential.key` and never returns them. [Model execution](../contracts/agents-api/model-execution.md#deployment-defaults) owns the request fields and replacement rules, and [precedence](../contracts/agents-api/model-execution.md#saved-defaults-and-precedence) says which Sessions use a default.
 
-[Model execution](../contracts/agents-api/model-execution.md#deployment-defaults)
-owns the request fields, replacement rules and applicable sources. The
-[user guide](user-guide.md#which-model-provider-a-session-uses) explains how to
-choose a source for a Session.
+## Installation directory
 
-## Secrets and identity
+The installer creates the installation directory, `~/.oac/core` by default, with mode `0700`; the files in `secrets/` are `0600`.
 
-| File | Content | Changed by |
+| Path | Content | Changed by |
 | --- | --- | --- |
+| `config.json` | [Process settings](#process-settings-configjson). The only file you edit | You, then `oac apply`; managed domain setup for `public_url` |
+| `oac` | The [management command](getting-started/operations.md#the-oac-command) | The installer |
+| `state.json` | Installation ID, Compose project name, image IDs, source commit and the digests of generated files | The tools only |
 | `secrets/core.key` | The [Core key](getting-started/operations.md#core-key) | `oac rotate-core-key` |
 | `secrets/credential.key` | Encryption key for what Core stores sealed in the database: model providers, the E2B key, Vault credentials, Skills, initial files and environment setup | Nothing. Keep it with the database; `oac apply` refuses a changed file |
 | `secrets/database.password` | PostgreSQL password | Nothing. PostgreSQL reads it only when the database is created; `oac apply` refuses a changed file |
-| `state.json` | Installation ID, Compose project, image IDs, source commit and the digests of generated files | The tools only |
+| `generated/` | Files derived from `config.json` | `oac apply` |
+| `node-payload/` | The node installer and node files that Web serves at `/node-install/`, one directory per release | The installer |
+| `native-installers/` | Self-hosted daemon installers for each platform, with their catalog, when the bundle carries them | The installer |
+| `state/e2b/` | Private E2B receipts | Core |
+| `ingress/` | Managed HTTPS: certificates and gateway state, domain setup status and the control sockets | The `gateway` and `installation` services |
+| `native/` | Core binaries, with native Core | The installer |
+| `.oac.lock` | The installation lock | The installer and mutating `oac` commands |
+
+A Web-only installation has only `secrets/core.key`, a copy of its Core's key, and no `state/` or `native-installers/`. A Core-only installation has no `node-payload/`. Only managed ingress has `ingress/`. With native Core, the installation directory and the bundle must be canonical absolute paths without control characters, quotes, backslashes or wildcards.
 
-A Web-only installation has only `secrets/core.key`, a copy of its Core's key.
+In Docker, the Compose project is named `oac-<10 hex digits>` (`project` in `state.json`). Its services are `database`, `migrate`, `core` and `web`, plus `gateway` and `installation` with managed ingress. `gateway` publishes `ports.web`, 80 and 443 and routes to Core and Web; `installation` applies domain changes from Web and uses the Docker socket to do so. The volume `<project>_database` holds all data. Native Core runs Core as the systemd user unit `<project>-core.service` instead of a container. Apart from Docker's storage, nothing is written outside your home directory.
 
 ## Appendix: Core environment without the installer
 
-Core reads only its environment. The installer renders `generated/core.env` from
-`config.json`; if you run Core yourself (see
-[Maintainers and advanced deployments](maintainers.md)), set these variables. Compose
-loads the file with `env_file` and systemd with `EnvironmentFile`, so Compose must be
-2.26.0 or newer.
+Core reads only its environment. The installer renders `generated/core.env` from `config.json`; if you run Core yourself (see [Maintainers and advanced deployments](maintainers.md)), set these variables. Compose loads the file with `env_file` and systemd with `EnvironmentFile`, so Compose must be 2.26.0 or newer.
 
 | Variable | Set from |
 | --- | --- |
-| `OAC_PUBLIC_URL` | `public_url`, or Core's loopback origin. Core derives the daemon WebSocket URL, the self-hosted `remote_url`, the hosted sandbox address and the deployment's read-only `core_url` from it. Required with `OAC_INSTALLATION_ID` |
-| `OAC_ADDR` | `ports.core` (native Core) or the container port |
+| `OAC_PUBLIC_URL` | `public_url`, or Core's loopback origin. Core derives the daemon WebSocket URL, the self-hosted `remote_url`, the hosted sandbox address and the deployment's read-only `core_url` from it, never from request headers. Without it, Core runs no Runtime gateway and executes no Sessions |
+| `OAC_ADDR` | `ports.core` (native Core) or `:8091` in the container |
 | `OAC_DATABASE_URL` | The installation's PostgreSQL without a password, plus `core.database_pool` as `pool_*` query parameters |
 | `OAC_DATABASE_PASSWORD_FILE` | `secrets/database.password`. The URL must then carry no password; migrations and the maintenance commands read the file too |
 | `OAC_CREDENTIAL_KEY_FILE` | `secrets/credential.key` |
 | `OAC_CORE_KEY_DIGESTS_FILE` | `generated/core-key-digests.json`: a JSON array with the SHA-256 of the Core key |
-| `OAC_INSTALLATION_ID` | `state.json`; pinned to the database |
+| `OAC_INSTALLATION_ID` | The installation ID from `state.json`, a canonical UUID. It enables the sandbox deployment and node routes and requires `OAC_PUBLIC_URL` and `OAC_CORE_KEY_DIGESTS_FILE`. Core refuses an ID other than the one its database recorded, so keep the two together |
 | `OAC_SETTINGS_FILE` | `generated/settings.json`, the snapshot Core serves at `GET /core/v1/installation`; Core does not act on it |
 | `OAC_EXECUTION_CONCURRENCY`, `OAC_DEFAULT_HARNESS`, `OAC_HARNESSES`, `OAC_WRITE_AUDIT_RETENTION`, `OAC_OAUTH_TRUSTED_ORIGINS` | The matching `core.*` settings |
-| `OAC_HISTORY_SETTINGS_FILE` | `generated/runtime-history.json` when `core.runtime_history` is set; see the [history contract](../contracts/agents-api/runtime-history-api.md) |
+| `OAC_HISTORY_SETTINGS_FILE` | `generated/runtime-history.json`: the [`core.runtime_history`](#settings) object, when it is set |
 | `OAC_LOG_LEVEL`, `OAC_LOG_FORMAT`, `OAC_LOG_ADD_SOURCE` | `log.*`; Web reads the same three |
-| `OAC_E2B_STATE_DIR`, `OAC_E2B_PROVIDER_BIN` | The E2B receipt directory and, for native Core, the bundled helper. The E2B key and template live in the database |
-
-A Web you run without the installer reads the variables in
-[Connecting the administrator console to Core](web/core-connection.md#server-configuration-and-login),
-plus `OAC_WEB_NODE_PAYLOAD_DIR`: the absolute path of the matched distribution's
-node payload (the installer's `node-payload/`). Without it, Add node is
-unavailable. Native self-hosted installation uses its separate platform bundle.
-
-Core fails at startup, naming the replacement, while a retired variable is set:
-`AGENTS_API_DAEMON_WS_URL` (use `OAC_PUBLIC_URL`), `AGENTS_API_CONFIG_FILE` (no
-replacement), `AGENTS_API_EXECUTION_OPTIONS_FILE` (use
-[default models](#default-models)), `AGENTS_API_SANDBOX_ADMIN_DIGESTS_FILE` (use
-`OAC_CORE_KEY_DIGESTS_FILE`), and `AGENTS_API_MANAGED_RUNTIMES_FILE`,
-`AGENTS_API_SANDBOX_NODE_STATE_DIR` and `AGENTS_API_SANDBOX_NODE_CORE_URL` (the
-sandbox deployment lives in the database and nodes enroll separately). Core logs the
-file paths it loads, never environment values or file contents. Native installation
-paths must be canonical absolute paths without control characters, quotes, backslashes
-or wildcards. Keep the installation ID and the database together; Core refuses a
-missing installation ID when its database already has a deployment.
-
-### Native daemon distributions
-
-Release Core images include matched self-hosted installers. A standalone Core
-process can set `OAC_NATIVE_INSTALLER_DIR` to the release's `native-installers`
-directory. Core checks the catalog's source revision, Runtime protocol and archive
-checksums before serving it. This setting supplies installation artifacts only;
-it does not change Runtime preparation, permissions or execution.
+| `OAC_E2B_STATE_DIR` | `state/e2b/`: an absolute directory owned by Core's user, with no group or other access. Back it up with the database and `credential.key`; don't mount it into Web or a Runtime |
+| `OAC_E2B_PROVIDER_BIN` | The E2B helper: `/opt/oac/e2b/oac-e2b-provider` in the Core image, `native/e2b/oac-e2b-provider` for native Core. The E2B key and template live in the database |
+| `OAC_NATIVE_INSTALLER_DIR` | `native-installers/`, served to self-hosted machines; the Core image has a copy at `/opt/oac/native-installers`, used when this is unset. Core checks the catalog against its own release before serving it |
+
+Core logs the file paths it loads, never environment values or file contents.
+
+A Web you run without the installer reads the variables in [Connecting the administrator console to Core](web/core-connection.md#server-configuration-and-login), plus `OAC_WEB_NODE_PAYLOAD_DIR`: the absolute path of the matched distribution's node payload (the installer's `node-payload/`). Without it, Add node is unavailable.
diff --git a/docs/getting-started/README.md b/docs/getting-started/README.md
index 1714424a0..1c1b4cf52 100644
--- a/docs/getting-started/README.md
+++ b/docs/getting-started/README.md
@@ -1,37 +1,31 @@
 # OpenAgentCore documentation
 
-OpenAgentCore runs AI agents on your own infrastructure behind the OpenAI Agents
-API. Pick the path that matches your role. New here? Read the
-[architecture overview](../architecture.md) first.
+OpenAgentCore runs AI agents on your own infrastructure behind the OpenAI Agents API. The [architecture overview](../architecture.md) explains its parts. Pick the guides for your role.
 
-## Operators: install and run
+## Operators
 
-1. [Install Core and Web](install.md) and sign in.
-2. Add execution capacity: [managed nodes or E2B](nodes.md), or
-   [your own machine](self-hosted.md).
-3. Issue a Project API key and hand it to the application developer.
+Operators install Core and Web, add sandbox capacity and issue Project API keys.
 
 | Guide | Covers |
 | --- | --- |
-| [Installation](install.md) | Prerequisites, HTTPS, first sign-in, advanced options |
-| [Configuration](../configuration.md) | `config.json`, default models, sandbox deployment |
-| [Nodes](nodes.md) | Adding, checking and removing managed nodes |
-| [Self-hosted execution](self-hosted.md) | Connecting your own machine to a Session |
-| [Operations](operations.md) | Services, backups, keys, repair and troubleshooting |
+| [Install Core and Web](install.md) | The default installation, from an empty host to the first Project API key |
+| [Installation options](install-options.md) | Installer flags, existing reverse proxies, split and native deployments, offline hosts |
+| [Nodes](nodes.md) | Adding, changing, removing and troubleshooting sandbox nodes |
+| [Operations](operations.md) | The `oac` command, the Core key, backups, upgrades and troubleshooting |
+| [Configuration reference](../configuration.md) | Every setting, file and environment variable |
 | [Web console](../web/README.md) | What the console shows and manages |
 
-## Application developers: build on the API
+## Application developers
+
+Application developers call the API with a Project API key, and can run Sessions on machines they own.
 
 | Guide | Covers |
 | --- | --- |
 | [Quickstart](quickstart.md) | From a Project API key to a finished Session |
 | [User guide](../user-guide.md) | Common tasks: harness and model choice, follow-ups, capabilities, files, cancel |
 | [Agents API guide](../api/public-agent-api.md) | Every resource, with SDK and HTTP examples |
+| [Self-hosted execution](self-hosted.md) | Running a Session on your own machine |
 | [Examples](../examples.md) | Complete applications built on the API |
 | [API index](../api/README.md) | All three namespaces and their credentials |
 
-## Contributors: extend Core
-
-Start with the [developer guide](../development.md): repository map, local setup,
-and how to add a Sandbox Provider, a harness or a Runtime feature. Repository rules
-are in [CONTRIBUTING.md](../../CONTRIBUTING.md).
+Contributors start with the [developer guide](../development.md) and [CONTRIBUTING.md](../../CONTRIBUTING.md).
diff --git a/docs/getting-started/install-options.md b/docs/getting-started/install-options.md
index 05ea369c3..b803a34a2 100644
--- a/docs/getting-started/install-options.md
+++ b/docs/getting-started/install-options.md
@@ -1,21 +1,20 @@
-# Installation options
+# Installation options and advanced deployments
+
+The [default installation](install.md) needs no options. Use this page to choose the sandbox backend at install time, run behind an existing reverse proxy, split Core and Web across hosts, run Core natively or install without internet access.
 
 Pass options to the downloaded script:
 
 ```sh
-./install.sh --host 127.0.0.1 --port 8088
+./install.sh --sandbox docker
 ```
 
-With the Quick start pipeline, append `-s --` and the options after `bash`.
-The release downloader also accepts `--version TAG` to select a published release;
-otherwise it selects the latest stable release.
+With the one-line command, append them after `bash -s --`. The release downloader also accepts `--version TAG` to select a published release; otherwise it selects the latest stable release. It verifies the bundle's SHA-256 before extracting it and keeps the verified bundle for [repair](operations.md#installation-version-policy).
+
+The installer prints each stage, then a summary of addresses, sign-in details and next steps. Set `NO_COLOR=1` to disable colors. A failed step stops installation without a success message.
 
 ## Process settings
 
-These flags seed the installation's `config.json` once. Their defaults, valid values
-and restart behavior are defined in the [configuration reference](../configuration.md#settings).
-After installation, edit that file and run `oac apply`; rerunning the installer
-repairs the same version and accepts only `--install-dir`.
+These flags seed the installation's `config.json` once. Their defaults, valid values and restart behavior are defined in the [configuration reference](../configuration.md#settings). After installation, edit that file and run `oac apply`; rerunning the installer only [repairs](operations.md#installation-version-policy) the installation.
 
 <!-- BEGIN install-flags: generated by scripts/config-reference.py -->
 | Flag | config.json field |
@@ -30,40 +29,16 @@ repairs the same version and accepts only `--install-dir`.
 | `--ingress` | `ingress` |
 <!-- END install-flags -->
 
-`--config FILE` seeds `config.json` from a JSON file instead of these setting flags;
-they cannot be combined. There is no precedence between two configuration sources.
-Generated Compose and environment files are derived outputs, not editable settings.
-
-## Listeners and access
-
-The default combined Docker installation selects `--ingress managed` and
-`--host 0.0.0.0`. The gateway publishes Web on `--port` (8080 by default), and
-reserves ports 80 and 443 for automatic HTTPS. Core's `--core-port` remains on
-loopback; PostgreSQL remains private. `--host` accepts IPv4 or IPv6, without a
-port, scheme or zone. Use a concrete server IP in the browser, not a wildcard.
-
-`--ingress external` keeps the existing proxy arrangement. It is the default for
-Core-only, Web-only and native Core; these modes do not support managed ingress.
-Their Core/Web listeners default to loopback. External non-loopback listeners
-require an HTTPS `public_url` and your own
-[reverse proxy configuration](install.md#https-and-the-reverse-proxy).
-
-`--public-url` can seed a DNS-based HTTPS origin for unattended managed setup;
-certificate and connectivity checks must pass. Without it, open Web by IP first
-and use **System → Domain and HTTPS**. An explicit `--config` document follows the
-schema defaults; set `ingress: "managed"` and `host: "0.0.0.0"` to choose that flow.
-The ingress mode is fixed for an installation. Managed ingress needs a local
-Docker Unix socket and Docker's ability to publish ports 80 and 443.
+`--config FILE` seeds `config.json` from a JSON file instead of these setting flags; they cannot be combined. A `--config` document follows the schema defaults, so set `ingress: "managed"` and `host: "0.0.0.0"` in it for managed HTTPS.
 
 ## Installation actions
 
-These options choose an installation location or perform initial setup. They do not
-create another process configuration file.
+These options choose an installation location or perform initial setup; they are not saved in `config.json`.
 
 | Option | Purpose |
 | --- | --- |
 | `--install-dir DIR` | Absolute installation directory; defaults to `~/.oac/core`. A new installation requires an empty or missing directory |
-| `--sandbox docker\|microsandbox\|e2b\|none` | Select the initial [sandbox backend](install.md#sandbox-backend), saved in Core's database; change it later in Web |
+| `--sandbox docker\|microsandbox\|e2b\|none` | Select the initial [sandbox backend](#sandbox-backend), saved in Core's database; change it later in Web |
 | `--accept-docker-risks` | Accept Docker's weaker isolation without an interactive prompt |
 | `--e2b-api-key-file FILE` | With E2B: absolute path to a private key file, no group/other access and at most 4 KiB |
 | `--e2b-template ID:BUILD` | With E2B: ready template build as `template-id:build-uuid` |
@@ -71,8 +46,259 @@ create another process configuration file.
 | `--e2b-domain DOMAIN` | With E2B: sandbox data-plane DNS suffix; use together with `--e2b-api-url` |
 | `--core-key-file FILE` | With Web-only: absolute path to a private file containing the existing Core key, at least 32 characters |
 
-See [deployment modes](install.md#modes), [native Core](install.md#native-core) and
-[sandbox setup](install.md#sandbox-backend) for their prerequisites.
-Several installations can share a machine when they use distinct installation
-directories and ports. Only one managed gateway can own ports 80 and 443 on a
-particular IP; use distinct IPs or an external shared proxy for additional installations. Each has its own database, Core key and node registrations.
+Several installations can share a machine when they use distinct installation directories and ports. Only one managed gateway can own ports 80 and 443 on an IP address; use distinct IP addresses or an external shared proxy for more. Each installation has its own database, Core key and nodes.
+
+## Sandbox backend
+
+An installation runs its sandboxes on exactly one backend:
+
+| `--sandbox` | Sandboxes run on | You then |
+| --- | --- | --- |
+| `microsandbox` (default) | microVMs on your nodes, which need KVM | [Add nodes](nodes.md) in Web |
+| `docker` | Docker containers on your nodes; weaker isolation | [Add nodes](nodes.md) in Web |
+| `e2b` | E2B's cloud, sized by your template build | Nothing: E2B needs no nodes |
+| `none` | Nothing yet | Choose in Web under **System** → **Manage sandbox configuration** |
+
+Docker and microsandbox start at the Standard size in Web's [`standard-sizes.json`](../../apps/web/src/features/sandbox/standard-sizes.json). If Core refuses the choice, for example because E2B rejects the key, the installer prints Core's message and exits; the services keep running and you choose the backend in Web. To change the backend or size later, see [change the sandbox configuration](nodes.md#change-the-sandbox-configuration).
+
+**Docker** shares each node's kernel with its sandboxes, and its node service account is [root-equivalent](nodes.md#what-the-installer-sets-up). Choose it only for trusted workloads or hosts without KVM. The installer asks for confirmation (default No); without a terminal, pass `--accept-docker-risks`.
+
+**E2B** needs a public HTTPS URL that is not loopback, because E2B's sandboxes call Core from E2B's cloud, so pass `--public-url`. Prepare the template build with the [E2B guide](../../services/agents-api/deploy/e2b/README.md), then:
+
+```sh
+./install.sh --public-url https://core.example --sandbox e2b \
+  --e2b-api-key-file "$HOME/.oac/e2b-api-key" --e2b-template '<template-id>:<build-uuid>'
+```
+
+## Listeners and access
+
+The default combined Docker installation selects `--ingress managed` and `--host 0.0.0.0`. Its gateway publishes Web on `--port` (8080 by default) and uses ports 80 and 443 for automatic HTTPS. Core's `--core-port` stays on loopback and PostgreSQL stays private. `--host` accepts IPv4 or IPv6, without a port, scheme or zone. Use a concrete server IP in the browser, not a wildcard. Managed ingress needs a local Docker Unix socket and Docker's ability to publish ports 80 and 443.
+
+`--ingress external` uses your own reverse proxy instead. It is the only choice for Core-only, Web-only and native Core installations, and their default. Core and Web then listen on `--host`, loopback by default. External non-loopback listeners require an HTTPS `public_url` and a [reverse proxy](#https-and-the-reverse-proxy), and Web's domain setup is unavailable: set `public_url` in `config.json` and run `oac apply`.
+
+`--public-url` seeds a DNS-based HTTPS origin for unattended setup; with managed ingress, the certificate and connectivity checks must pass. The ingress mode is fixed for an installation.
+
+## HTTPS and the reverse proxy
+
+With external ingress, Core and Web share one public origin. Your reverse proxy terminates TLS and routes by path:
+
+| Path | Goes to | Callers |
+| --- | --- | --- |
+| `/v1`, `/v1/*` | Core, `127.0.0.1:8091` by default | Applications, with a Project API key |
+| `/api/v1/*` | Core, `127.0.0.1:8091` | Nodes, sandboxes and self-hosted machines. Uses WebSockets |
+| Everything else | Web, `127.0.0.1:8080` by default | Browsers, and node installers at `/node-install/*` |
+
+The proxy must:
+
+- **Preserve Host.** Web accepts only the host of its public URL.
+- **Pass WebSocket upgrades** on `/api/v1`.
+- **Not buffer or time out streams.** `/v1` streams Session events.
+- **Accept large uploads.** Source files may reach 512 MiB; Core enforces the limits.
+
+Run the proxy on the Core host while Core and Web listen on loopback, the default. `oac status` prints these routes with your addresses and ports.
+
+**Caddy** obtains the certificate itself and passes Host and WebSockets by default:
+
+```caddyfile
+core.example {
+	@core path /v1 /v1/* /api/v1/*
+	handle @core {
+		reverse_proxy 127.0.0.1:8091
+	}
+	handle {
+		reverse_proxy 127.0.0.1:8080
+	}
+}
+```
+
+**nginx**, for example in `/etc/nginx/conf.d/oac.conf` inside the `http` block:
+
+```nginx
+map $http_upgrade $connection_upgrade {
+    default upgrade;
+    ''      close;
+}
+
+server {
+    listen 80;
+    server_name core.example;
+    return 301 https://$host$request_uri;
+}
+
+server {
+    listen 443 ssl;
+    server_name core.example;
+    ssl_certificate     /etc/letsencrypt/live/core.example/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/core.example/privkey.pem;
+
+    client_max_body_size 0;          # Core enforces its own upload limits
+    proxy_http_version 1.1;
+    proxy_set_header Host $http_host;
+    proxy_set_header Upgrade $http_upgrade;
+    proxy_set_header Connection $connection_upgrade;
+    proxy_buffering off;             # server-sent events on /v1
+    proxy_request_buffering off;
+    proxy_read_timeout 1h;           # long-lived WebSockets and streams
+    proxy_send_timeout 1h;
+
+    location = /v1    { proxy_pass http://127.0.0.1:8091; }
+    location /v1/     { proxy_pass http://127.0.0.1:8091; }
+    location /api/v1/ { proxy_pass http://127.0.0.1:8091; }
+    location /        { proxy_pass http://127.0.0.1:8080; }
+}
+```
+
+Then set `public_url` in `~/.oac/core/config.json` and run `~/.oac/core/oac apply`. Check the routing:
+
+```sh
+curl -s -o /dev/null -w '%{http_code}\n' -H 'OpenAI-Beta: agents=v1' https://core.example/v1/agents
+```
+
+`401` means `/v1` reached Core, which asks for a key. `404` means it reached Web: fix the proxy, or application calls and every node connection will fail.
+
+TLS verification stays on everywhere. With a private certificate authority, node hosts, self-hosted machines and the Runtime image must trust it.
+
+### Try it locally with a quick tunnel
+
+A [Cloudflare quick tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/do-more-with-tunnels/trycloudflare/) gives a trial installation with external ingress a temporary public HTTPS address. It forwards to one port, so put a local proxy with the same routes in front:
+
+```caddyfile
+http://:8443 {
+	bind 127.0.0.1
+	@core path /v1 /v1/* /api/v1/*
+	handle @core {
+		reverse_proxy 127.0.0.1:8091
+	}
+	handle {
+		reverse_proxy 127.0.0.1:8080
+	}
+}
+```
+
+1. Start the proxy: `caddy run --config Caddyfile`.
+2. Start the tunnel: `cloudflared tunnel --url http://127.0.0.1:8443`. It prints an address such as `https://random-words.trycloudflare.com`.
+3. Set that address as `public_url` in `~/.oac/core/config.json` and run `~/.oac/core/oac apply`.
+
+The address changes whenever `cloudflared` restarts; nodes bound to the old address must then be added again. Throughput is low, so a node's first Runtime download (about 500 MB) can be slow; see [slow links](nodes.md#rerun-expiry-and-slow-links).
+
+## Modes
+
+| Mode | Runs | Use it for |
+| --- | --- | --- |
+| all (default) | PostgreSQL, Core and Web | Most installations |
+| `--core-only` | PostgreSQL and Core | A Core whose Web runs elsewhere, or scripts only. No Add node command |
+| `--web-only` | Web | A second host for the console, paired with an existing Core |
+
+The mode and native Core are fixed once installed; to change them, install into a new directory.
+
+A Web-only console forwards signed-in `/core/v1` requests to its Core with the Core key, so `--core-url` must reach Core's `/core/v1` directly. The public URL doesn't, because the proxy sends `/core/v1` to Web:
+
+- **Web on the Core host:** use `--core-url http://127.0.0.1:8091`.
+- **Web on another host:** give Core a second HTTPS name that sends every path to Core, such as `https://core-api.example`, and allow only the Web host's address.
+
+### Split deployment
+
+| Host | Install | Reverse proxy |
+| --- | --- | --- |
+| Core | `./install.sh --core-only --public-url https://core.example` | `core.example`: `/v1`, `/v1/*` and `/api/v1/*` to Core; `/node-install/*` to the Web host with Host rewritten to `console.example`; nothing else. `core-api.example`: every path to Core, for the Web host's address only |
+| Web | `./install.sh --web-only …`, below | `console.example`: every path to Web |
+
+```sh
+./install.sh --web-only --install-dir "$HOME/.oac/web" \
+  --public-url https://console.example \
+  --core-url https://core-api.example \
+  --core-key-file "$HOME/core.key"
+```
+
+Browsers and node installers use `console.example`. Applications, nodes, sandboxes and self-hosted machines call Core at `core.example`; self-hosted machines also download their installer there, which is why `core.example` forwards `/node-install/*` to Web. Missing node files redirect to the release; for disconnected nodes, install Web from the [offline bundle](#offline-hosts).
+
+Caddy on the Core host, where `203.0.113.10` is the Web host's address:
+
+```caddyfile
+core.example {
+	@core path /v1 /v1/* /api/v1/*
+	handle @core {
+		reverse_proxy 127.0.0.1:8091
+	}
+	handle /node-install/* {
+		reverse_proxy https://console.example {
+			header_up Host console.example
+		}
+	}
+	handle {
+		respond 404
+	}
+}
+
+core-api.example {
+	@web remote_ip 203.0.113.10
+	handle @web {
+		reverse_proxy 127.0.0.1:8091
+	}
+	handle {
+		respond 403
+	}
+}
+```
+
+nginx on the Core host, with the `map` from the [main example](#https-and-the-reverse-proxy):
+
+```nginx
+server {
+    listen 443 ssl;
+    server_name core.example;
+    ssl_certificate     /etc/letsencrypt/live/core.example/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/core.example/privkey.pem;
+
+    client_max_body_size 0;
+    proxy_http_version 1.1;
+    proxy_set_header Host $http_host;
+    proxy_set_header Upgrade $http_upgrade;
+    proxy_set_header Connection $connection_upgrade;
+    proxy_buffering off;
+    proxy_request_buffering off;
+    proxy_read_timeout 1h;
+    proxy_send_timeout 1h;
+
+    location = /v1    { proxy_pass http://127.0.0.1:8091; }
+    location /v1/     { proxy_pass http://127.0.0.1:8091; }
+    location /api/v1/ { proxy_pass http://127.0.0.1:8091; }
+    location /node-install/ {
+        proxy_pass https://console.example;
+        proxy_set_header Host console.example;   # Web serves node files only for its own name
+        proxy_ssl_server_name on;
+        proxy_ssl_name console.example;
+        proxy_ssl_verify on;
+        proxy_ssl_verify_depth 2;
+        proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
+    }
+    location / { return 404; }
+}
+
+server {
+    listen 443 ssl;
+    server_name core-api.example;
+    ssl_certificate     /etc/letsencrypt/live/core-api.example/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/core-api.example/privkey.pem;
+
+    allow 203.0.113.10;                        # the Web host
+    deny all;
+    client_max_body_size 0;
+    proxy_http_version 1.1;
+    proxy_buffering off;
+    proxy_read_timeout 1h;
+    location / { proxy_pass http://127.0.0.1:8091; }
+}
+```
+
+The Web host's proxy sends every path to Web, for example `console.example { reverse_proxy 127.0.0.1:8080 }` in Caddy.
+
+Copy `secrets/core.key` from the Core host with mode `0600`, then delete `$HOME/core.key`; the installer keeps its own copy. After a [Core key rotation](operations.md#rotate-the-core-key), copy it again. A Web-only install selects no sandbox backend.
+
+## Native Core
+
+`--native-core` runs Core as a systemd user service; PostgreSQL and Web stay in containers. It needs a running systemd user manager with lingering, which the host administrator enables with `sudo loginctl enable-linger "$USER"`, and the bundle's native binaries must load on the host. PostgreSQL then listens on a loopback port the installer picks (`ports.database`). Native Core is unrelated to the sandbox backend.
+
+## Offline hosts
+
+Transfer the release's `*-linux-amd64-offline.tar.gz` and its `.sha256` file, verify and extract them, then run the bundled `./install.sh`. The offline bundle also carries the node and Runtime files, so Web serves them to nodes without release access.
diff --git a/docs/getting-started/install.md b/docs/getting-started/install.md
index fb5a5c96d..0042b2ec9 100644
--- a/docs/getting-started/install.md
+++ b/docs/getting-started/install.md
@@ -1,39 +1,26 @@
 # Install Core and Web
 
-One command installs Core, the Web console and PostgreSQL on a Linux host. Web is
-the administrator console: you sign in with the Core key, issue Project API keys
-and add nodes. Applications then call Core's API with those keys.
-
-The default path has five steps:
+One command installs Core, the Web console and PostgreSQL on a Linux host. Web is the administrator console: you sign in with the Core key, give the installation a domain, set a default model and issue Project API keys. Applications then call Core's API with those keys, and their Sessions run in sandboxes on nodes you add, or on E2B.
 
 1. [Check the prerequisites](#prerequisites).
 2. [Run the installer](#install).
-3. Open the printed `http://SERVER_IP:8080` address and [sign in to Web](#sign-in-to-web).
-4. [Configure HTTPS in Web](#make-core-reachable), set a default model and issue a key.
-5. [Add execution capacity](#next-steps): a node, E2B or your own machine.
+3. [Sign in to Web](#sign-in-to-web).
+4. [Configure the domain and HTTPS](#configure-the-domain-and-https).
+5. [Set a default model](#set-a-default-model).
+6. [Issue a Project API key](#issue-a-project-api-key).
+7. [Add sandbox capacity](#add-sandbox-capacity).
 
-Every flag, listener addresses and ports are in
-[installation options](install-options.md). Offline hosts, other sandbox backends
-and split deployments are in [Advanced installation](#advanced-installation).
+This page follows the default path. Every flag, existing reverse proxies, split and native deployments and offline hosts are in [installation options](install-options.md).
 
 ## Prerequisites
 
-**The Core host**
-
-- Linux amd64 with Python 3.9 or newer.
+- Linux amd64 with Python 3.9 or newer, and curl. No GitHub account or CLI is needed.
 - Docker Engine with Docker Compose 2.26.0 or newer (`docker compose version`).
-- An account that can run `docker` and write to its home directory. Ordinary users
-  and root both work; the installer never calls sudo.
-- Free ports 8080 (initial Web access), 80 and 443 (HTTPS gateway), and loopback
-  port 8091 (Core). Docker must be able to publish these ports; the installer
-  does not elevate privileges or change host policy.
-- curl. No GitHub CLI or login is needed.
+- An account that can run `docker` and write to its home directory. Ordinary users and root both work; the installer never calls sudo.
+- Free ports 8080 (initial Web access), 80 and 443 (HTTPS), and 8091 (Core, on loopback). Docker must be able to publish them; the installer does not change host policy.
+- A DNS hostname that points to this host, before you connect applications, nodes, E2B or self-hosted machines. You can install and sign in first.
 
-The Core host needs no KVM.
-
-A DNS hostname is needed when you connect applications, nodes, E2B or self-hosted
-machines. You can install and open Web before configuring it; the managed gateway
-obtains and renews the certificate automatically.
+The Core host needs no KVM; nodes that run microsandbox do.
 
 ## Install
 
@@ -41,426 +28,63 @@ obtains and renews the certificate automatically.
 curl -fsSL https://github.com/MiniMax-AI/parsar-core/releases/latest/download/install.sh | bash
 ```
 
-For noninteractive setup with DNS already pointing at the server, pass the public address:
+If DNS already points to this host, pass the address to set up HTTPS during installation instead of in step 4:
 
 ```sh
 curl -fsSL https://github.com/MiniMax-AI/parsar-core/releases/latest/download/install.sh | bash -s -- --public-url https://core.example
 ```
 
-The script picks the latest stable release, verifies its checksum and runs the
-bundled installer, which:
-
-1. checks the host and loads the Core, Web, PostgreSQL and installation gateway images;
-2. creates `~/.oac/core` (mode `0700`) with the Core key, `config.json` and the
-   `oac` management command;
-3. starts the services with Docker Compose. Web is reachable through the gateway
-   on `0.0.0.0:8080`; Core stays on loopback and PostgreSQL stays private;
-4. selects the microsandbox backend at the Standard size. It adds no node.
-
-It creates no Project or key and makes no model request. It ends by printing the
-console address, the API base URL and the next steps.
-
-Open the printed Web address. If the server is behind NAT, use the IP address
-reachable from your browser. The initial HTTP endpoint serves Web; machine API
-connections require the HTTPS address configured next.
-
-## Make Core reachable
-
-In Web, open **System → Domain and HTTPS** and enter a DNS hostname, such as
-`core.example.com`. Its A/AAAA records must point to this server, and ports 80 and
-443 must be reachable from the internet. Choose **Configure HTTPS**.
-
-The installer requests a certificate and verifies that the trusted HTTPS endpoint
-reaches this installation before switching Core and Web. On success, open the
-HTTPS address and sign in again; the initial HTTP Web address redirects there.
-Certificate renewal is automatic. DNS or certificate failures leave the previous
-address available; correct the reported problem and retry. An interrupted switch
-can be retried with the same hostname, or inspected with `oac status` and completed
-with `oac apply`. Installation data and execution workspaces are retained.
-
-The equivalent terminal operation uses the same preparation and apply flow:
-
-```sh
-~/.oac/core/oac domain core.example.com
-```
-
-Core derives every machine connection address from the resulting `public_url`.
-[Changing the public URL](../configuration.md#changing-the-public-url) explains
-existing connection bindings and confirmation.
-
-### External proxy deployments
-
-Select `--ingress external` to use an existing proxy or a quick tunnel instead.
-Core-only, Web-only and native Core installations select external ingress by
-default. Their listeners remain loopback by default. Configure the proxy below,
-then set `public_url` in `config.json` and run `oac apply`; automatic domain setup in
-Web is unavailable for these installations.
-
-### HTTPS and the reverse proxy
-
-Core and Web share one public origin. Your reverse proxy terminates TLS and routes
-by path:
-
-| Path | Goes to | Callers |
-| --- | --- | --- |
-| `/v1`, `/v1/*` | Core, `127.0.0.1:8091` by default | Applications, with a Project API key |
-| `/api/v1/*` | Core, `127.0.0.1:8091` | Nodes, sandboxes and self-hosted machines. Uses WebSockets |
-| Everything else | Web, `127.0.0.1:8080` by default | Browsers, and node installers at `/node-install/*` |
-
-The proxy must:
-
-- **Preserve Host.** Web accepts only the host of its public URL.
-- **Pass WebSocket upgrades** on `/api/v1`.
-- **Not buffer or time out streams.** `/v1` streams Session events.
-- **Accept large uploads.** Source files may reach 512 MiB; Core enforces the limits.
-
-Run the proxy on the Core host when Core and Web listen on loopback (the default).
-`oac status` prints these routes with your addresses and ports.
-
-**Caddy** obtains the certificate itself and passes Host and WebSockets by default:
-
-```caddyfile
-core.example {
-	@core path /v1 /v1/* /api/v1/*
-	handle @core {
-		reverse_proxy 127.0.0.1:8091
-	}
-	handle {
-		reverse_proxy 127.0.0.1:8080
-	}
-}
-```
-
-**nginx**, for example in `/etc/nginx/conf.d/oac.conf` inside the `http` block:
-
-```nginx
-map $http_upgrade $connection_upgrade {
-    default upgrade;
-    ''      close;
-}
-
-server {
-    listen 80;
-    server_name core.example;
-    return 301 https://$host$request_uri;
-}
-
-server {
-    listen 443 ssl;
-    server_name core.example;
-    ssl_certificate     /etc/letsencrypt/live/core.example/fullchain.pem;
-    ssl_certificate_key /etc/letsencrypt/live/core.example/privkey.pem;
-
-    client_max_body_size 0;          # Core enforces its own upload limits
-    proxy_http_version 1.1;
-    proxy_set_header Host $http_host;
-    proxy_set_header Upgrade $http_upgrade;
-    proxy_set_header Connection $connection_upgrade;
-    proxy_buffering off;             # server-sent events on /v1
-    proxy_request_buffering off;
-    proxy_read_timeout 1h;           # long-lived WebSockets and streams
-    proxy_send_timeout 1h;
-
-    location = /v1    { proxy_pass http://127.0.0.1:8091; }
-    location /v1/     { proxy_pass http://127.0.0.1:8091; }
-    location /api/v1/ { proxy_pass http://127.0.0.1:8091; }
-    location /        { proxy_pass http://127.0.0.1:8080; }
-}
-```
-
-Check the routing:
+The script picks the latest stable release, verifies its checksum and runs the bundled installer, which:
 
-```sh
-curl -s -o /dev/null -w '%{http_code}\n' -H 'OpenAI-Beta: agents=v1' https://core.example/v1/agents
-```
-
-`401` means `/v1` reached Core, which asks for a key. `404` means it reached Web:
-fix the proxy, or application calls and every node connection will fail.
-
-TLS verification stays on everywhere. With a private certificate authority, node
-hosts, self-hosted machines and the Runtime image must trust it.
-
-### Try it locally with a quick tunnel
-
-A [Cloudflare quick tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/do-more-with-tunnels/trycloudflare/)
-gives a trial installation a temporary public HTTPS address. It forwards to one
-port, so put a local proxy with the same routes in front:
-
-```caddyfile
-http://:8443 {
-	bind 127.0.0.1
-	@core path /v1 /v1/* /api/v1/*
-	handle @core {
-		reverse_proxy 127.0.0.1:8091
-	}
-	handle {
-		reverse_proxy 127.0.0.1:8080
-	}
-}
-```
+1. checks the host and loads the Core, Web, PostgreSQL and HTTPS gateway images;
+2. creates the [installation directory](../configuration.md#installation-directory), `~/.oac/core`, with the Core key, `config.json` and the `oac` management command;
+3. starts the services with Docker Compose. The gateway serves Web on port 8080 of all IPv4 interfaces; Core stays on loopback and PostgreSQL stays private;
+4. selects the microsandbox sandbox backend at the Standard size. It adds no node.
 
-1. Start the proxy: `caddy run --config Caddyfile`.
-2. Start the tunnel: `cloudflared tunnel --url http://127.0.0.1:8443`. It prints an
-   address such as `https://random-words.trycloudflare.com`.
-3. Set that address as `public_url` in `~/.oac/core/config.json` and run
-   `~/.oac/core/oac apply`.
-
-The address changes whenever `cloudflared` restarts; nodes bound to the old address
-must then be added again. Throughput is low, so a node's first Runtime download
-(about 500 MB) can be slow; see [slow links](nodes.md#rerun-expiry-and-slow-links).
+It creates no Project or key and makes no model request. It ends by printing the console address, the API base URL and the next steps.
 
 ## Sign in to Web
 
-1. **Open the console** at the address the installer printed: your public URL, or
-   `http://127.0.0.1:8080` on the Core host by default. Web refuses other host names.
-   For a remote host without a public URL, forward the port over SSH first, for
-   example `ssh -L 8080:127.0.0.1:8080 <core-host>`.
-2. **Sign in with the Core key**, the installation's administrator credential. Web has
-   no user accounts. See [Core key](operations.md#core-key).
+1. Open the console address the installer printed: `http://SERVER_IP:8080`, or your public URL if you passed one. Behind NAT, use the IP address your browser reaches. Until a domain is set, Web accepts IP addresses only, not host names.
+2. Sign in with the [Core key](operations.md#core-key), the installation's administrator credential. Web has no user accounts.
 
    ```sh
    cat ~/.oac/core/secrets/core.key
    ```
 
-3. **Set a default model.** On **System**, find **Default model**. On the card marked
-   **Default** (Codex unless you changed it), choose **Set** and enter the model and
-   its provider's base URL and API key. MiniMax Code also needs the context window
-   and max output tokens. See [Default models](../configuration.md#default-models).
-4. **Create a project and issue a key.** On **Projects and keys**, choose
-   **Create project**, then **Issue key**. The dialog shows the key once: copy it and
-   keep it safe. Its **How to call** card shows the API base URL and sample requests.
-5. **Hand over** the key and the API base URL to the application developer. They continue with the [quickstart](quickstart.md).
-
-Web's **Overview** tracks these steps in a **Getting started** checklist.
-
-## Next steps
-
-| Goal | Guide |
-| --- | --- |
-| Run Sessions in managed sandboxes | [Add a node](nodes.md), or use [E2B](#sandbox-backend) |
-| Run your first Session | [Quickstart](quickstart.md) |
-| Run Sessions on your own machine | [Self-hosted execution](self-hosted.md) |
-| Operate the installation | [Operations](operations.md) and [configuration](../configuration.md) |
-
-## Advanced installation
+## Configure the domain and HTTPS
 
-### Installer options
+Applications, nodes and sandboxes reach Core at one HTTPS address, the public URL. The initial HTTP address serves only Web.
 
-Every flag, with the `config.json` field it seeds, is in
-[installation options](install-options.md). Pass them after `bash -s --`, or
-download `install.sh` from the Release page and run it directly. The script
-verifies the bundle's SHA-256 before extracting it and keeps the verified bundle
-under `~/.oac/releases/` for repair. It never upgrades an existing installation.
+1. Point the hostname's A/AAAA records to this host, and allow inbound ports 80 and 443 from the internet.
+2. In Web, open **System**, choose **Configure domain and HTTPS**, enter the hostname, such as `core.example.com`, and choose **Apply**.
 
-**Offline hosts.** Transfer the Release's `*-linux-amd64-offline.tar.gz` and its
-`.sha256` file, verify and extract them, then run the bundled `./install.sh`. The
-offline bundle also carries the node and Runtime files, so Web can serve them to
-nodes without release access.
+The installation requests a certificate and checks that the HTTPS address reaches this installation before switching Core and Web to it. Then open the HTTPS address and sign in again; the initial HTTP address redirects there. Certificates renew automatically. If DNS or the certificate fails, the previous address stays in use: correct the reported problem and retry. Retry an interrupted switch with the same hostname, or check it with `oac status` and finish it with `oac apply`.
 
-**Output.** The installer prints each stage, then a summary of addresses, sign-in
-details and next steps. Set `NO_COLOR=1` to disable colors. A failed step stops
-installation without a success message.
-
-### Sandbox backend
-
-A deployment runs its sandboxes on exactly one backend:
-
-| `--sandbox` | Sandboxes run on | You then |
-| --- | --- | --- |
-| `microsandbox` (default) | microVMs on your nodes (KVM): 2 CPUs, 4 GiB memory and two 8 GiB disks each | [Add nodes](nodes.md) in Web |
-| `docker` | Docker on your nodes: 2 CPUs and 2 GiB each; weaker isolation | [Add nodes](nodes.md) in Web |
-| `e2b` | E2B's cloud, sized by your template build | Nothing: E2B needs no nodes |
-| `none` | Nothing yet | Choose on the **Nodes** page in Web |
-
-The Standard sizes come from Web's
-[`standard-sizes.json`](../../apps/web/src/features/sandbox/standard-sizes.json). If
-Core refuses the choice, for example because E2B rejects the key, the installer
-prints Core's message and exits; the services keep running and you choose the
-backend in Web. To change the backend or size later, see
-[Sandbox deployment](../configuration.md#sandbox-deployment).
-
-**Docker's risks.** Containers share the host kernel, so a container escape reaches
-the node host; microsandbox gives each sandbox its own microVM. The node's service
-account in the `docker` group is root-equivalent. Choose Docker only for trusted
-workloads or hosts without KVM. The installer asks for confirmation (default No);
-without a terminal, pass `--accept-docker-risks`.
-
-**E2B** needs a public HTTPS URL that is not loopback, because E2B's sandboxes call
-Core from E2B's cloud. Prepare the template build with the
-[E2B guide](../../services/agents-api/deploy/e2b/README.md), then:
+The same operation from a terminal:
 
 ```sh
-./install.sh --public-url https://core.example --sandbox e2b \
-  --e2b-api-key-file "$HOME/.oac/e2b-api-key" --e2b-template '<template-id>:<build-uuid>'
+~/.oac/core/oac domain core.example.com
 ```
 
-### Modes
+To change the address later, see [changing the public URL](../configuration.md#changing-the-public-url).
 
-| Mode | Runs | Use it for |
-| --- | --- | --- |
-| all (default) | PostgreSQL, Core and Web | Most installations |
-| `--core-only` | PostgreSQL and Core | A Core whose Web runs elsewhere, or scripts only. No Add node command |
-| `--web-only` | Web | A second host for the console, paired with an existing Core |
+## Set a default model
 
-The mode and native Core are fixed once installed; to change them, install into a
-new directory.
+Core-hosted Sessions without their own model provider use their harness's default model. On **System**, under **Default model configuration**, find the harness marked **Default** (Codex unless you changed `core.default_harness`) and choose **Set**. Enter the model ID, the protocol, and the provider's base URL and API key. MiniMax Code also needs the context window and max output tokens. See [default models](../configuration.md#default-models).
 
-A Web-only console forwards signed-in `/core/v1` requests to its Core with the Core
-key, so `--core-url` must reach Core's `/core/v1` directly. The public URL doesn't,
-because the default proxy sends `/core/v1` to Web:
+## Issue a Project API key
 
-- **Web on the Core host:** use `--core-url http://127.0.0.1:8091`.
-- **Web on another host:** give Core a second HTTPS name that sends every path to
-  Core, such as `https://core-api.example`, and allow only the Web host's address.
+1. On **Projects and keys**, choose **Create project**, then **Issue key**. The dialog shows the key once: copy it and keep it safe. Its **How to call** card shows the API base URL and sample requests.
+2. Give the key and the API base URL to the application developer. They continue with the [quickstart](quickstart.md).
 
-#### Split deployment
-
-| Host | Install | Reverse proxy |
-| --- | --- | --- |
-| Core | `./install.sh --core-only --public-url https://core.example` | `core.example`: `/v1`, `/v1/*` and `/api/v1/*` to Core; `/node-install/*` to the Web host with Host rewritten to `console.example`; nothing else. `core-api.example`: every path to Core, for the Web host's address only |
-| Web | `./install.sh --web-only …`, below | `console.example`: every path to Web |
+Web's **Overview** tracks these steps in a **Getting started** checklist.
 
-```sh
-./install.sh --web-only --install-dir "$HOME/.oac/web" \
-  --public-url https://console.example \
-  --core-url https://core-api.example \
-  --core-key-file "$HOME/core.key"
-```
+## Add sandbox capacity
 
-Browsers and node installers use `console.example`. Applications, nodes, sandboxes
-and self-hosted machines call Core at `core.example`; self-hosted machines also
-download their installer there, which is why `core.example` forwards
-`/node-install/*` to Web. Missing node artifacts redirect to the release; for
-disconnected nodes, install Web from the offline bundle.
-
-Caddy on the Core host, where `203.0.113.10` is the Web host's address:
-
-```caddyfile
-core.example {
-	@core path /v1 /v1/* /api/v1/*
-	handle @core {
-		reverse_proxy 127.0.0.1:8091
-	}
-	handle /node-install/* {
-		reverse_proxy https://console.example {
-			header_up Host console.example
-		}
-	}
-	handle {
-		respond 404
-	}
-}
-
-core-api.example {
-	@web remote_ip 203.0.113.10
-	handle @web {
-		reverse_proxy 127.0.0.1:8091
-	}
-	handle {
-		respond 403
-	}
-}
-```
+Sessions need somewhere to run:
 
-nginx on the Core host, with the `map` from the
-[main example](#https-and-the-reverse-proxy):
-
-```nginx
-server {
-    listen 443 ssl;
-    server_name core.example;
-    ssl_certificate     /etc/letsencrypt/live/core.example/fullchain.pem;
-    ssl_certificate_key /etc/letsencrypt/live/core.example/privkey.pem;
-
-    client_max_body_size 0;
-    proxy_http_version 1.1;
-    proxy_set_header Host $http_host;
-    proxy_set_header Upgrade $http_upgrade;
-    proxy_set_header Connection $connection_upgrade;
-    proxy_buffering off;
-    proxy_request_buffering off;
-    proxy_read_timeout 1h;
-    proxy_send_timeout 1h;
-
-    location = /v1    { proxy_pass http://127.0.0.1:8091; }
-    location /v1/     { proxy_pass http://127.0.0.1:8091; }
-    location /api/v1/ { proxy_pass http://127.0.0.1:8091; }
-    location /node-install/ {
-        proxy_pass https://console.example;
-        proxy_set_header Host console.example;   # Web serves node files only for its own name
-        proxy_ssl_server_name on;
-        proxy_ssl_name console.example;
-        proxy_ssl_verify on;
-        proxy_ssl_verify_depth 2;
-        proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
-    }
-    location / { return 404; }
-}
-
-server {
-    listen 443 ssl;
-    server_name core-api.example;
-    ssl_certificate     /etc/letsencrypt/live/core-api.example/fullchain.pem;
-    ssl_certificate_key /etc/letsencrypt/live/core-api.example/privkey.pem;
-
-    allow 203.0.113.10;                        # the Web host
-    deny all;
-    client_max_body_size 0;
-    proxy_http_version 1.1;
-    proxy_buffering off;
-    proxy_read_timeout 1h;
-    location / { proxy_pass http://127.0.0.1:8091; }
-}
-```
+- **Nodes** run the microsandbox backend the installer selected: [add a node](nodes.md) from Web's **Nodes** page. Docker nodes need `--sandbox docker` at installation, or a [reset](nodes.md#change-the-sandbox-configuration) to change the backend.
+- **E2B**, which needs no nodes: [change the sandbox configuration](nodes.md#change-the-sandbox-configuration) in Web, or [choose it during installation](install-options.md#sandbox-backend).
 
-The Web host's proxy sends every path to Web, for example
-`console.example { reverse_proxy 127.0.0.1:8080 }` in Caddy.
-
-Copy `secrets/core.key` from the Core host with mode `0600`, then delete
-`$HOME/core.key`; the installer keeps its own copy. After a
-[Core key rotation](operations.md#rotate-the-core-key), copy it again. A Web-only
-install selects no sandbox backend.
-
-### Native Core
-
-`--native-core` runs Core as a systemd user service; PostgreSQL and Web stay in
-containers. It needs a running systemd user manager with lingering
-(`sudo loginctl enable-linger "$USER"`), and the bundle's native binaries must load
-on the host. PostgreSQL then listens on a loopback port the installer picks
-(`ports.database`). Native Core is unrelated to the sandbox backend.
-
-### What the installer creates
-
-The installation directory, `~/.oac/core` by default, mode `0700`:
-
-| Path | Content |
-| --- | --- |
-| `config.json` | Process settings. The only file you edit; see the [configuration reference](../configuration.md) |
-| `oac` | The [management command](operations.md#the-oac-command) |
-| `secrets/core.key` | The Core key |
-| `secrets/credential.key` | Encryption key for credentials stored in the database. Back it up with the database; never replace it |
-| `secrets/database.password` | PostgreSQL password |
-| `state.json` | Installation ID, Compose project name, image IDs and source commit. Written by the tools only |
-| `generated/` | Files derived from `config.json`. `oac apply` rewrites them; don't edit them |
-| `node-payload/` | The node installer and files that Web serves at `/node-install/` |
-| `state/e2b/` | Private E2B receipts |
-| `native/` | Core binaries, with `--native-core` only |
-
-Web-only installations have only `secrets/core.key` among the secrets. Core-only
-installations have no `node-payload/`.
-
-In Docker, the Compose project is named `oac-<10 hex digits>` (`project` in
-`state.json`), with the containers `database`, `migrate`, `core` and `web` and the
-volume `<project>_database` that holds all data. Apart from Docker's storage,
-nothing is written outside your home directory. Native Core adds a systemd user
-unit.
-
-### Rerun the installer
-
-Rerunning `./install.sh` from the same bundle repairs an installation: it reloads
-missing images, restores the `oac` command, applies `config.json` and starts the
-services. It accepts only `--install-dir` and refuses a bundle from another
-release; see [installation version policy](operations.md#installation-version-policy).
-
-An installation from before the rename, at `~/.parsar/core`, blocks a new default
-install. Keep it and choose another `--install-dir`.
+Day-to-day operation, backups and upgrades are in [Operations](operations.md).
diff --git a/docs/getting-started/nodes.md b/docs/getting-started/nodes.md
index c51bcdd76..07365e55d 100644
--- a/docs/getting-started/nodes.md
+++ b/docs/getting-started/nodes.md
@@ -1,86 +1,30 @@
 # Add and manage nodes
 
-A node is a Linux machine that runs sandboxes for Core-hosted Sessions when the
-sandbox backend is Docker or microsandbox. Core places each new Session on a node with
-free capacity; the node creates the sandbox, and the sandbox connects back to Core.
-With E2B you need no nodes. Self-hosted executors, which applications run for their
-own Sessions, are a different thing; see [Self-hosted executors](self-hosted.md).
+A node is a Linux host that runs sandboxes for Core-hosted Sessions when the sandbox backend is Docker or microsandbox. Core places each new Session on a node with free capacity; the node creates the sandbox, and the sandbox connects back to Core. E2B needs no nodes. Machines that applications connect for their own Sessions are [self-hosted executors](self-hosted.md), not nodes.
 
-You add a node by generating a command in Web and pasting it on the host. The
-[operator reference](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md) covers the
-node protocol, manual registration, placement and failure handling.
+You add a node by generating a command in Web and running it on the host. The [sandbox deployment contract](../../contracts/agents-api/sandbox-deployment.md) defines the sandbox settings and their change rules, and the [node protocol](../../contracts/agents-api/node-generation-protocol.md) defines how nodes prepare and keep Runtime generations.
 
 ## Before you add a node
 
-- **Core has an HTTPS public URL** that the host and its sandboxes can reach: each
-  sandbox calls Core at `public_url`. A loopback installation can't have nodes, and
-  Web says so at Add node. See
-  [HTTPS and the reverse proxy](install.md#https-and-the-reverse-proxy).
-- **Nodes can download their execution files.** Web supplies the release metadata.
-  With the default online installation, nodes follow HTTPS redirects to download
-  their matching Runtime and provider files directly from the release, verifying
-  sizes and SHA-256 checksums before use. Core and Web do not download these files.
-  For nodes without release access, use the [offline bundle](install.md#installer-options)
-  on the Web host so it serves the files locally. Verified local files are reused.
-- **A sandbox backend is chosen.** The installer selects microsandbox unless you chose
-  otherwise. After `--sandbox none`, the **Nodes** page first asks you to choose
-  **Own machines**, then microsandbox (preselected as recommended) or Docker, which it
-  asks you to confirm, and a sandbox size, then **Save configuration**. Every node of a
-  deployment uses that provider.
+- **Core has an HTTPS public URL** that the host and its sandboxes can reach. Nodes download from Core's console and connect to Core at `public_url`. Until it is set, Add node says *Configure a domain and HTTPS in System before adding nodes*; see [Configure the domain and HTTPS](install.md#configure-the-domain-and-https), or with external ingress [change the public URL](../configuration.md#changing-the-public-url).
+- **The sandbox configuration is saved.** The installer saves microsandbox at the Standard size unless you passed another `--sandbox`. After `--sandbox none`, open **System** → **Manage sandbox configuration**, choose **Own machines**, then microsandbox (recommended) or Docker and a sandbox size, and **Save configuration**. Every node of an installation uses that backend.
+- **The console can serve the node files.** Nodes download their Runtime and provider files from the console, which redirects to the release for files it does not hold, and check each file's size and SHA-256 against the release manifest. For hosts without access to the release, install Core from the [offline bundle](install-options.md#offline-hosts) so the console holds every file. Without the files, Add node says *This console has no node files for …*.
+
+The Core host joins like any other host: to run sandboxes on it, add it as a node.
 
 ## Add a node
 
-1. In Web, open **Nodes** and select **Add node**.
-2. Set **Sandboxes at once** (default 2): how many sandboxes Core may run on this node.
-   With microsandbox, also set **Retained sandboxes** (default 8): how many it may keep,
-   suspended ones included. With Docker, Core keeps retained equal to at once. You can
-   change them later with **Edit node**.
-3. Select **Generate command** and copy the command. It registers one node, once, and
-   only if it runs within 10 minutes; Web counts down and offers
-   **Generate new command** when it expires.
+1. In Web, open **Nodes** and choose **Add node**.
+2. Set **Sandboxes at once** and, with microsandbox, **Retained sandboxes**: the node's [capacity](../configuration.md#node-capacity). You can change them later with **Edit node**.
+3. Choose **Generate command** and copy the command. It registers one node, once, and only if it runs within 10 minutes; Web counts down and offers **Generate new command** when it expires.
 4. Run it on the host. Web follows the node from registered to connected to ready.
 
-The command downloads the node installer from your console, checks its SHA-256, and
-runs it with a one-time enrollment token. The installer downloads the node files from
-the same console and checks each against the release manifest, imports the Runtime
-image, registers the node, starts its service and waits until Core reports the node
-connected and ready. It never installs software, and it stops with a one-line hint
-before changing anything when a prerequisite is missing.
-
-Node installation and removal require root. Web's command uses `sudo` unless the
-shell is already root. The installer creates an `oac-node` service user and a
-system service; the node runs as that service user, not as root. Direct execution
-as an ordinary user is rejected before reading the enrollment token or changing
-the host. This requirement applies to Sandbox Provider nodes, not the native
-self-hosted daemon installer.
-
-### Download through a proxy
-
-Export standard `http_proxy` / `https_proxy` and `no_proxy` variables before
-running the generated command. Uppercase `HTTP_PROXY`, `HTTPS_PROXY` and
-`NO_PROXY` work too; lowercase takes precedence when both are set (including an
-empty lowercase value). Use an HTTP proxy URL, optionally with URL-encoded
-credentials, and comma-separated host exclusions in `no_proxy`. A proxy for
-HTTPS downloads must support CONNECT.
-
-The command requests sudo preservation of only these six names and keeps them
-when dropping to `oac-node`. If sudo policy denies preservation, ask the host
-administrator to permit those names or run from a root shell with the variables
-exported there. A manually added outer `sudo` can discard them before the
-command starts. Do not put credentials in command arguments or share shell traces.
+The command downloads the node installer from your console, checks its SHA-256 and runs it with a one-time enrollment token. The installer downloads the node files and checks each against the release manifest, imports the Runtime image, registers the node, starts its service and waits until Core reports the node connected and ready. It never installs software, and it stops with a one-line hint before changing anything when a prerequisite is missing.
 
-These settings apply only to installation requests. They are not saved in node
-configuration or the systemd unit; the running node still needs its own network
-access to Core. Without proxy variables, downloads use the existing direct path.
+Node installation and removal require root. Web's command uses `sudo` unless the shell is already root. The installer creates an `oac-node` service user and a system service; the node runs as that user, not as root. Running the installer as an ordinary user fails before it reads the enrollment token or changes the host.
 
 ### The command
 
-The command shows each installation phase as it runs. After Core confirms the
-connection and the Sandbox Provider is ready, it prints a grouped summary with
-status and log commands. Terminal colors are optional (`export NO_COLOR=1` disables them; the generated
-command passes this preference through sudo with `--no-color`);
-redirected output stays plain. Registration tokens are never printed.
-
 This is the command Web generates, with this installation's values:
 
 ```sh
@@ -92,29 +36,29 @@ printf '%s  %s\n' '<installer-sha256>' "$d/node-install.pyz" | sha256sum -c --st
 printf '%s\n' '<enrollment-token>' | $s python3 "$d/node-install.pyz" ${NO_COLOR+--no-color} --enrollment-token-stdin --source-url 'https://core.example' --core-url 'https://core.example' --provider 'docker' --installation-id '<installation-id>')
 ```
 
-- It downloads the installer into a private temporary directory, checks its SHA-256,
-  and runs it with `sudo`, or directly in a root shell.
-- The token reaches the installer on standard input, so it never appears in a process
-  argument, an environment variable or sudo's log.
-- The leading space keeps the command out of the shell history where `HISTCONTROL`
-  ignores such lines (the Debian and Ubuntu default).
-- If the command is interrupted or the download stalls, run the same command again:
-  the download resumes.
+- It downloads the installer into a private temporary directory, checks its SHA-256, and runs it with `sudo`, or directly in a root shell.
+- The token reaches the installer on standard input, so it never appears in a process argument, an environment variable or sudo's log.
+- The leading space keeps the command out of the shell history where `HISTCONTROL` ignores such lines (the Debian and Ubuntu default).
+
+The installer shows each phase as it runs and, once Core confirms the node, a summary with status and log commands. `export NO_COLOR=1` disables colors; the command passes this through sudo as `--no-color`. It never prints tokens.
 
-The host needs:
+### Host requirements
 
 - Linux amd64 with systemd; Python 3.9+, `curl` and `sha256sum`; root or sudo.
-- SELinux not enforcing. Hosts with enforcing SELinux are unsupported by this installer.
-- One Core per host: a host already running a sudo-mode node for another Core is
-  refused.
-- Docker: rootful Docker Engine running, its socket `/var/run/docker.sock` owned by the
-  `docker` group with mode `0660`, enforcing CPU and memory limits (cgroup v2).
-- microsandbox: `/dev/kvm` in the `kvm` group (hardware or nested virtualization), and
-  the libraries microsandbox links (glibc).
-- CPUs and memory for at least one sandbox of the deployment's size, and about 2 GB of
-  disk for the Runtime image.
+- SELinux not enforcing. The installer does not support hosts with enforcing SELinux.
+- Docker: rootful Docker Engine running, its socket `/var/run/docker.sock` owned by the `docker` group with mode `0660`, enforcing CPU and memory limits (cgroup v2).
+- microsandbox: `/dev/kvm` in the `kvm` group (hardware or nested virtualization), and the libraries microsandbox links (glibc).
+- CPUs and memory for at least one sandbox of the installation's size, and about 2 GB of disk for the Runtime image.
 - HTTPS access to the console and Core at the public URL; sandboxes reach Core too.
 
+### Download through a proxy
+
+Export `http_proxy`, `https_proxy` and `no_proxy` before running the generated command. Uppercase `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` work too; lowercase takes precedence when both are set, even when empty. Use an HTTP proxy URL, optionally with URL-encoded credentials, and comma-separated host exclusions in `no_proxy`. A proxy for HTTPS downloads must support CONNECT.
+
+The command asks sudo to preserve only these six names, and the installer keeps them when it drops to `oac-node`. If sudo policy refuses, ask the host administrator to permit those names, or run from a root shell with the variables exported there. An outer `sudo` you add yourself can discard them. Don't put credentials in command arguments or share shell traces.
+
+The proxy applies only to installation downloads. It is not saved in the node's configuration or service, so the running node needs its own network access to Core.
+
 ## What the installer sets up
 
 | Item | Detail |
@@ -125,65 +69,45 @@ The host needs:
 | Node state | `/var/lib/oac-node/.oac/nodes/<installation-id>/`: identity, configuration, node files. microsandbox keeps its images and sandboxes under `/var/lib/oac-node/.oac/m/` |
 | Records | `/etc/oac-node/`: what the installer created or changed, used by reruns and uninstall |
 | Docker | The Runtime image, imported once, and a network `oac-node-<installation-id>` |
+| microsandbox network policy | Sandboxes may reach Core, DNS on the host and public addresses, and nothing else: no inbound connections and no private networks. A private model or MCP endpoint needs a policy change on the node |
+
+Root only prepares the account, the group and the unit; everything else, the Docker network included, runs as `oac-node`, in its own session without a terminal. The installer never installs Docker, KVM or packages, never starts Docker, never changes device permissions, sudoers, firewall or SELinux settings, and never touches other accounts.
 
-Root only prepares the account, the group and the unit; everything else, the Docker
-network included, runs as `oac-node`, in its own session without a terminal. The
-installer never installs Docker, KVM or packages, never starts Docker, never changes
-device permissions, sudoers, firewall or SELinux settings, and never touches other
-accounts.
+**Docker mode is root-equivalent.** Membership in the `docker` group lets `oac-node`, and so anything that controls the node, act as root on the host. Containers also share the host kernel, so a container escape reaches the host. Add Docker nodes only on hosts dedicated to sandboxes. microsandbox nodes need only the `kvm` group and run each sandbox in its own microVM.
 
-**Docker mode is root-equivalent.** Membership in the `docker` group lets
-`oac-node`, and so anything that controls the node, act as root on the host. This
-is inherent to running sandboxes on Docker. Add Docker
-nodes only on hosts dedicated to sandboxes. microsandbox nodes need only the `kvm`
-group.
+**One Core per host.** Nodes share the `oac-node` account, so a host serves one Core; a command from a second Core is refused.
 
-**One Core per host.** Nodes share the `oac-node` account, so a host serves one
-Core; a command from a second Core is refused.
+**One release.** A node runs the program of the console that added it and is never upgraded in place; see the [installation version policy](operations.md#installation-version-policy).
 
-**The token.** It is single-use, expires after 10 minutes and only registers the node.
-The installer takes it only on standard input and refuses it in the environment,
-where `sudo VAR=… python3` would record it in sudo's log. A sudoers policy with
-`log_input` records standard input, and so the token.
+**The token.** It is single-use, expires after 10 minutes and only registers the node. The installer takes it only on standard input and refuses it in the environment, where `sudo VAR=… python3` would record it in sudo's log. A sudoers policy with `log_input` records standard input, and so the token.
 
 ## Rerun, expiry and slow links
 
-- Rerunning the same command is safe. Once the node is registered, a rerun uses the
-  node's own credential, changes nothing that already matches and needs no token.
-- A command that already expired, or was used on another host, fails at once with
-  `Core rejected the node configuration read (HTTP 401)`: generate a new command and
-  run it within 10 minutes.
-- If the command expires during a slow download, registration fails with
-  `The enrollment command expired or was already used`. The downloaded files are kept:
-  generate a new command in Web and run it.
-- Downloads resume where they stopped. A download that brings less than 64 KiB in a
-  minute stops, keeping what it has; run the command again.
-- The Docker Runtime image is about 500 MB. On a slow link, load it first: copy the
-  release's `oac-<commit>-linux-amd64-runtime.tar.gz` asset to the host and run
-  `sudo docker load -i` on it. The installer then finds the exact image and skips the
-  download.
-- Interrupting the installer, or closing its terminal, stops it; run the command again
-  to continue.
+- Rerunning the same command is safe. Once the node is registered, a rerun uses the node's own credential, changes nothing that already matches and needs no token. It refuses, without changing anything, when the node's retained identity belongs to another Core address or installation.
+- A command that already expired, or was used on another host, fails at once with `Core rejected the node configuration read (HTTP 401)`: generate a new command and run it within 10 minutes.
+- If the command expires during a slow download, registration fails with `The enrollment command expired or was already used`. The downloaded files are kept: generate a new command in Web and run it.
+- Downloads resume where they stopped. A download that brings less than 64 KiB in a minute stops, keeping what it has; run the command again.
+- The Docker Runtime image is about 500 MB. On a slow link, load it first: copy the release's `oac-<commit>-linux-amd64-runtime.tar.gz` asset to the host and run `sudo docker load -i` on it. The installer then finds the exact image and skips the download.
+- Interrupting the installer, or closing its terminal, stops it; run the command again to continue.
 
 ## Logs
 
-The installer prints the node's log command (`Logs: …`) when it finishes. The Add node
-dialog shows it too when something needs attention: when the node reports a problem, or
-when it hasn't become connected and ready about a minute after registering.
+The installer prints the node's log command (`Logs: …`) when it finishes. The Add node dialog shows it too when something needs attention: when the node reports a problem, or when it hasn't become connected and ready about a minute after registering.
+
+Run `sudo journalctl -u oac-node-<installation-id>.service`. In a root shell, omit `sudo`. The installation ID is in the command (`--installation-id`) and on the **System** page.
+
+## Change the sandbox configuration
 
-Run `sudo journalctl -u oac-node-<installation-id>.service`. In a root shell, omit
-`sudo`; the installer's summary already does this.
+Sandbox settings apply to the whole installation; nodes follow them.
 
-The installation ID is in the command (`--installation-id`) and on the **System** page.
+- **Size, Runtime release, E2B key or template build.** Open **System** → **Manage sandbox configuration** → **Change resources**, edit and save. Existing sandboxes keep their configuration. Each node prepares the new one while it keeps serving the old one, and **Nodes** shows its progress: **Preparing target**, **Ready for target** or **Preparation failed** with the [reason](#readiness-codes). Core places new Sessions on nodes ready for the new configuration first, and on nodes still serving an older one when those have no room. E2B changes apply at once.
+- **Backend.** On the same page, choose **Reset deployment**. Auto reset archives idle hosted Sessions at once and lets running work finish until the deadline you set; force cancels it now. Offline nodes must come back so Core can confirm their cleanup. When the reset completes, Core has retired every node and unused command: set up the new backend, then add nodes again. **Cancel reset** stops the remaining work; archived Sessions stay archived.
+
+The [reset contract](../../contracts/agents-api/sandbox-deployment.md#generation-ownership-and-rollout) describes what reset archives and keeps. To archive a single hosted Session, use the [Core API](../../contracts/agents-api/admin-api.md#administrative-session-archive).
 
 ## Remove a node
 
-1. In Web, open **Nodes** and choose **Remove node** on the node's page, or
-   **Remove** in its list row, then **Confirm removal**. Core refuses while the node
-   still holds sandboxes, snapshots or pending cleanup; let them finish, or
-   [archive their Sessions](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md#removal-and-reset)
-   through the Core API. Removal is permanent: the host can come back only as a new
-   node.
+1. In Web, open **Nodes** and choose **Remove node** on the node's page, or **Remove** in its list row, then **Confirm removal**. Core refuses while the node still holds sandboxes, snapshots or pending cleanup; let them finish, or archive their Sessions. Removal is permanent: the host can come back only as a new node. Removing every node keeps the sandbox configuration.
 2. Web then shows **Clean up the host** with the uninstall command. Run it on the host:
 
    ```sh
@@ -195,49 +119,67 @@ The installation ID is in the command (`--installation-id`) and on the **System*
    $s python3 "$d/node-install.pyz" ${NO_COLOR+--no-color} --uninstall --installation-id '<installation-id>')
    ```
 
-Uninstall first asks Core, at the address the node enrolled with, whether the node was
-removed, and refuses while Core still lists it. When the node enrolled with an address
-other than the current public URL, the dialog also shows **Old Core address gone?**:
-if that address no longer responds, it gives the command with `--force`, which skips
-the check; remove the node on the Nodes page first. Without the dialog, take the
-installer's SHA-256 from the `node-install.pyz` line of
-`https://core.example/node-install/SHA256SUMS`. Uninstall
-stops and removes the service, the node state, the records and the Docker network. It
-deletes the `oac-node` account only if the installer created it and no node remains;
-an adopted account only loses the groups the installer added.
-
-It never deletes sandboxes, volumes or images. It keeps the Runtime image and prints
-the `docker image rm` command. For microsandbox it keeps the store under
-`/var/lib/oac-node/.oac/m/`, prints how to delete it
-(`sudo -u oac-node rm -rf <store>`), and keeps a created account until the store is
-gone; rerun uninstall afterwards. With `--force`, microVMs may still use the store, so
-check `pgrep -u oac-node` first. Uninstall can be rerun until it completes.
+Uninstall first asks Core, at the address the node enrolled with, whether the node was removed, and refuses while Core still lists it. When the node enrolled with an address other than the current public URL, the dialog also shows **Old Core address gone?**: if that address no longer responds, it gives the command with `--force`, which skips the check; remove the node on the Nodes page first. Without the dialog, take the installer's SHA-256 from the `node-install.pyz` line of `https://core.example/node-install/SHA256SUMS`. Uninstall stops and removes the service, the node state, the records and the Docker network. It deletes the `oac-node` account only if the installer created it and no node remains; an adopted account only loses the groups the installer added.
+
+It never deletes sandboxes, volumes or images. It keeps the Runtime image and prints the `docker image rm` command. For microsandbox it keeps the store under `/var/lib/oac-node/.oac/m/`, prints how to delete it (`sudo -u oac-node rm -rf <store>`), and keeps a created account until the store is gone; rerun uninstall afterwards. With `--force`, microVMs may still use the store, so check `pgrep -u oac-node` first. Uninstall can be rerun until it completes.
+
+## Register a node manually
+
+Use manual registration when you manage the node's files and service yourself instead of running Web's command. A manually registered node serves only the configuration it registered with: after a size or Runtime change, **Nodes** shows it as **Node software incompatible**, and it keeps serving the old configuration until you remove it and register the host again.
+
+1. Take `oac-node` from the same release as Core.
+2. Get an enrollment token: the token in a command from **Add node**, or `POST /core/v1/sandbox/enrollment-tokens` with the Core key. It is single-use and carries the node's approved capacity; the response's `expires_at` says when it expires. Save it in a `0600` file on the host.
+3. Read the node configuration with the token, which does not consume it: `GET /api/v1/sandbox-node/configuration` with `Authorization: Bearer <token>`.
+4. Write a private provider file. Copy `provider`, `installation_id`, `core_url`, `generation` and `specification` from the response, and add one adapter object for the host:
+   - `docker`: `host` (an explicit Unix socket), `image` (the locally imported Runtime image of the approved release), `network`, `extra_hosts`, an absolute `seccomp_file` and `nested_sandbox`.
+   - `microsandbox`: absolute `helper_path`, `runtime_path` and `firmware_path` with their `runtime_sha256` and `firmware_sha256`, `image`, the sandbox `cpus`, `memory_mib`, `root_disk_mib` and `environment_disk_mib`, a `network` policy, and `runtime_home`: a private directory, which the helper creates with mode `0700` when it is missing. microsandbox places Unix sockets under it, so keep its path within 48 bytes; the installer refuses a longer one for its own nodes.
+5. Register, then run the node under the host's service supervisor, with real absolute paths:
+
+   ```sh
+   oac-node register \
+     --config /var/lib/oac/provider.json \
+     --state-dir /var/lib/oac/node \
+     --core-url https://core.example \
+     --name worker-1 \
+     --enrollment-token-file /var/lib/oac/enrollment-token
+   oac-node run \
+     --config /var/lib/oac/provider.json \
+     --state-dir /var/lib/oac/node
+   ```
+
+`oac-node run` exits with status 78 once Core rejects its credential, after the node is removed; configure the supervisor not to restart it then (systemd: `RestartPreventExitStatus=78`).
+
+The node connects out to Core; Core needs no SSH or Docker TCP access to the host. Registration writes the node's identity to the state directory before contacting Core, so a lost response can be retried under the same identity. Keep the state directory on persistent storage, private to the node's account and used by one process at a time. Never copy it to another directory or host: Core refuses a second connection for a node while the first is open. The provider file can't change the node's capacity or sandbox configuration. Core compares its digest at registration and on every connection, and a node whose file differs takes no work until the approved configuration is restored.
+
+## When a node host fails
+
+A restarted node service keeps its identity and finds its existing sandboxes again. Core never replaces a missing sandbox by itself, and never moves a Session to another node: the Session's resources show as **Node disconnected** or **Sandbox resource missing** until the original host and its storage are back, or you archive the Session. A lost node state directory is a recovery incident: restore it from its [backup](operations.md#back-up) together with the database and the provider storage, rather than registering the host again over existing resources.
 
 ## Troubleshooting
 
 ### Readiness codes
 
-When a node is online but its provider is not ready, **Nodes** shows its status as
-**Provider unavailable**, with the reason in a help tip; **Overview** counts it as a
-**Provider issue**. The API reports the reason as a fixed code, the `diagnostic` field
-of `GET /core/v1/sandbox/nodes`. A node reports only its first failed check, and the
-next heartbeat, about ten seconds after a fix, clears or replaces it. The node's log has
-the local error behind the code.
+When a node is online but its sandbox provider is not ready, **Nodes** and **Overview** show it as **Provider not ready**. Where the reason appears depends on how the node was added:
+
+- **Nodes added with Web's command** report a failed check of the current sandbox configuration as **Preparation failed** in the node's target status, with the reason in a help tip (`rollout.diagnostic` in `GET /core/v1/sandbox/nodes`). The tip beside **Provider not ready** only says *Sandbox provider unavailable*.
+- **Manually registered nodes** show the reason in the help tip beside **Provider not ready** (`diagnostic`).
+
+The node's log has the local error behind the code.
 
-| Code | Web shows | Cause | Fix |
+A node reports only its first failed check, in this order: the Docker daemon or KVM, Docker's limit support, host capacity, then the installed Runtime files. An unreachable Docker daemon therefore hides a missing image. The next heartbeat, about ten seconds after a fix, clears or replaces the code. An offline node keeps its last code, which Web hides until the node reconnects.
+
+| Code | Help tip | Cause | Fix |
 | --- | --- | --- | --- |
 | `docker_unavailable` | Docker unavailable | The Docker socket is unreachable or not accessible, or Docker fails its info or image request | Start Docker and give the node's user access to `/var/run/docker.sock` |
 | `docker_limits_unsupported` | Docker limits unsupported | Docker reports no CPU quota or memory limit support | Use a host whose cgroups enforce CPU and memory limits (cgroup v2) |
-| `runtime_image_unavailable` | Runtime image missing | Docker does not have the pinned Runtime image | Rerun the add command, or load the image from the matching release |
-| `kvm_unavailable` | KVM unavailable | The node can't open `/dev/kvm` for reading and writing | Enable hardware virtualization and give the node's user KVM access, through the `kvm` group |
-| `microsandbox_artifacts_unavailable` | microsandbox components missing | The Runtime or firmware is missing or fails its SHA-256 check, or the helper is missing | Rerun the add command |
 | `capacity_insufficient` | Host too small | The host has fewer CPUs or less memory than one sandbox | Use a larger host, or change the sandbox size |
-| `provider_unavailable` | Sandbox provider unavailable | Any other failure, and every failure an older node reports | Read the node's log |
+| `runtime_image_unavailable` | Runtime image missing | Docker does not have the pinned Runtime image | A node added with Web's command downloads it again by itself; otherwise load the image from the matching release |
+| `kvm_unavailable` | KVM unavailable | The node can't open `/dev/kvm` for reading and writing | Enable hardware virtualization and give the node's user KVM access, through the `kvm` group |
+| `microsandbox_artifacts_unavailable` | microsandbox components missing | The Runtime or firmware is missing or fails its SHA-256 check, or the helper is missing | A node added with Web's command downloads the missing files by itself; otherwise restore them from the matching release |
+| `runtime_download_failed` | Runtime download failed | While preparing a new configuration, the node could not download or verify the Runtime files | Check the node's HTTPS access to the console and the release. The node retries with growing delays, up to 30 minutes apart |
+| `provider_unavailable` | Sandbox provider unavailable | Any other failure | Read the node's log |
 
-A new group membership applies only to a new process. Restart the node service:
-`sudo systemctl restart oac-node-<installation-id>.service`. A node that is registered
-but never connects usually can't reach Core at the public URL, or its `/api/v1`
-WebSocket doesn't pass the reverse proxy.
+A new group membership applies only to a new process. Restart the node service: `sudo systemctl restart oac-node-<installation-id>.service`. A node that is registered but never connects usually can't reach Core at the public URL, or its `/api/v1` WebSocket doesn't pass the reverse proxy.
 
 ### Installer messages
 
@@ -251,41 +193,7 @@ WebSocket doesn't pass the reverse proxy.
 | KVM is unavailable, or `/dev/kvm` must be group-accessible | Enable virtualization; your distribution's KVM package sets `root:kvm 0660` |
 | This host has N CPUs and M MiB of memory; each sandbox needs … | Use a larger host, or change the sandbox size |
 | SELinux is enforcing on this host | Use a host supported by the installer; it does not change SELinux settings |
-| This host already runs a sudo-mode node for another Core | One host serves one Core in sudo mode. Remove that node and uninstall it first |
+| This host already runs a sudo-mode node for another Core | Remove that node and uninstall it first |
 | Node installation and removal require root | Run Web's command with sudo, or from a root shell |
 | Core still lists this node | Remove it on the Nodes page first |
-
-## Change the sandbox backend or size
-
-Change the backend or sandbox size in Web under **System** → **Sandbox backend**.
-What each change does, and when it needs a reset, is in
-[Sandbox deployment](../configuration.md#sandbox-deployment). This section covers
-only what happens on the nodes.
-
-Node program version updates are not supported. `--update` refuses without changing
-node state. Preserve an older installation and its Runtime data; provision a fresh
-node separately through **Add node**. Current Runtime generation operations below
-are independent of program version upgrades.
-
-Fresh v2 preparation keeps a private recovery plan until the actual provider image
-identity is resolved and its final configuration is published. Restart does not
-serve a pending or partly collected generation. Generation lock identity is durable:
-if a lease or its identity record is missing or replaced, preserve the installation
-for inspection. Do not delete records, recreate lock files or re-enroll to bypass
-that refusal; a process restart does not prove that older helpers have stopped.
-
-Automatic Docker generation GC removes only installation-owned generation/release
-files. Shared daemon images remain; a host administrator may remove them only after
-confirming no installation still needs them. Microsandbox image cleanup remains
-scoped to the installation's private native store and verified ownership receipts.
-
-The [operator reference](../../services/agents-api/HOSTED-SANDBOX-MANAGER.md#removal-and-reset)
-describes reset and API behavior. Same-team E2B edits have a separate online Core
-API path and do not involve node installation.
-
-
-## Installation scope
-
-Nodes and Core must come from the same distribution. Provision nodes through
-**Add node**; the installer never adopts or removes another installation's
-resources. See the [installation version policy](operations.md#installation-version-policy).
+| Core no longer accepts this node | It was removed, or a reset retired it. Uninstall it, then add the host with a new command |
diff --git a/docs/getting-started/operations.md b/docs/getting-started/operations.md
index 57cea2197..07e4d9a6a 100644
--- a/docs/getting-started/operations.md
+++ b/docs/getting-started/operations.md
@@ -1,13 +1,10 @@
 # Operate your installation
 
-The installation operator owns the Core host, its storage and its availability. Node
-hosts run their own services; see [Nodes](nodes.md). Settings are described in the
-[configuration reference](../configuration.md).
+The installation operator owns the Core host, its storage and its availability. Node hosts run their own services; see [Nodes](nodes.md). Settings are described in the [configuration reference](../configuration.md).
 
 ## The oac command
 
-Each installation has its own management command in its directory. It needs neither
-the bundle nor root:
+Each installation has its own management command in its directory. It needs neither the bundle nor root:
 
 ```sh
 ~/.oac/core/oac status
@@ -15,7 +12,7 @@ the bundle nor root:
 
 | Command | What it does |
 | --- | --- |
-| `oac status` | Shows each service and its health, Core and Web health, the public URL, API base URL, console address and source commit, the reverse-proxy routes to configure, `config.json` changes not applied yet and generated files edited by hand. A Web-only installation also checks that its Core accepts its Core key. Exits non-zero when a service is unavailable. It never calls a model |
+| `oac status` | Shows each service and its health, Core and Web health, the public URL, API base URL, console address and source commit, the routes a reverse proxy needs, `config.json` changes not applied yet and generated files edited by hand. A Web-only installation also checks that its Core accepts its Core key. Exits non-zero when a service is unavailable. It never calls a model |
 | `oac start` | Starts every service with the files last written by `apply`; warns about unapplied changes |
 | `oac stop` | Stops PostgreSQL, Core and Web. Data, nodes and sandboxes are kept, and running sandbox work may continue |
 | `oac apply` | Applies `config.json` and restarts what changed; see [how apply works](../configuration.md#how-oac-apply-works) |
@@ -23,11 +20,10 @@ the bundle nor root:
 | `oac apply --discard-edits` | Overwrites generated files edited by hand, keeping each as `generated/<file>.edited-<time>` |
 | `oac apply --confirm-public-url-change URL` | Confirms a public URL change without a prompt; must equal the new URL |
 | `oac apply --yes` | Web-only: pairs Web with a different Core without asking |
+| `oac domain HOSTNAME [--confirm-public-url-change URL]` | Managed ingress: sets the public URL to `https://HOSTNAME`, as **Configure domain and HTTPS** in Web does; see [Configure the domain and HTTPS](install.md#configure-the-domain-and-https) |
 | `oac rotate-core-key [--yes]` | Replaces the Core key; see [Rotate the Core key](#rotate-the-core-key) |
 
-`install.sh --status` and `--stop` are retired; they name the `oac` command instead.
-For a second installation, use its own command, such as
-`~/.oac/web/oac status`.
+For a second installation, use its own command, such as `~/.oac/web/oac status`.
 
 ## Service health
 
@@ -41,18 +37,14 @@ Use these observations for different questions:
 | Environment connection | The Runtime transport is connected |
 | A finished Turn and its results | The task's recorded outcome |
 
-Service health does not prove that a native harness or a model works. Use Session,
-Turn, Items and Usage reads for execution, and Web's **Nodes** page for node connection,
-readiness and placement. For local diagnosis, use the installation's own Compose file:
+Service health does not show that a harness or a model works. Use Session, Turn, Items and Usage reads for execution, and Web's **Nodes** page for node connection, readiness and placement. For local diagnosis, use the installation's own Compose file:
 
 ```sh
 docker compose -f "$HOME/.oac/core/generated/compose.json" ps --all
 docker compose -f "$HOME/.oac/core/generated/compose.json" logs --tail 200 core
 ```
 
-Native Core logs to its user unit: `journalctl --user -u <project>-core.service`, with
-`project` from `state.json`. Don't paste `docker compose config`, `docker inspect` or
-raw logs into public issue reports.
+Native Core logs to its user unit: `journalctl --user -u <project>-core.service`, with `project` from `state.json`. Don't paste `docker compose config`, `docker inspect` or raw logs into public issue reports.
 
 ## Stop and restart
 
@@ -63,65 +55,58 @@ Let active work settle before a planned restart:
 ~/.oac/core/oac start
 ```
 
-Stopping Core stops no node and no sandbox. Node services, their microVMs and Docker
-containers keep running; stopping is not a way to reclaim compute. A Core restart does
-not continue an interrupted native tool call transparently. After reconnecting, query
-the same Session; don't create a new Session to replay uncertain work. Session event
-streams are live only; recover through Session, Turn and Items reads.
+Stopping Core stops no node and no sandbox. Node services, their microVMs and Docker containers keep running; stopping is not a way to reclaim compute. A Core restart does not continue an interrupted native tool call transparently. After reconnecting, query the same Session; don't create a new Session to replay uncertain work. Session event streams are live only; recover through Session, Turn and Items reads.
 
-A Web restart, including one caused by `oac apply`, signs everyone out of the
-console.
+A Web restart, including one caused by `oac apply`, signs everyone out of the console. Web sign-ins otherwise last 12 hours.
 
 ## Core key
 
-Each installation has one administrator credential, the Core key. The installer
-generates a 64-character random key in `<install dir>/secrets/core.key`, by default
-`~/.oac/core/secrets/core.key`. The Core key:
+Each installation has one administrator credential, the Core key. The installer generates a 64-character random key in `<install dir>/secrets/core.key`, by default `~/.oac/core/secrets/core.key`. The Core key:
 
 - signs in to Web. The browser gets an HttpOnly session cookie, never the key;
 - authorizes Core API (`/core/v1`) requests sent as `Authorization: Bearer <Core key>`;
-- never authorizes the Agent API (`/v1`). Applications use Project API keys, which in
-  turn can't call `/core/v1`.
+- never authorizes the Agents API (`/v1`). Applications use Project API keys, which in turn can't call `/core/v1`.
 
-Keep it private: `secrets/` is mode `0700` and its files `0600`. Of the services, only
-Web reads `core.key`; Core reads its SHA-256 from `generated/core-key-digests.json`,
-which `oac apply` derives from the key. Both read them only at startup. A Core key
-has at least 32 characters and no whitespace. Web limits failed sign-ins.
+Keep it private: `secrets/` is mode `0700` and its files `0600`. Web and, with managed ingress, the `installation` service read `core.key`; Core reads only its SHA-256 from `generated/core-key-digests.json`, which `oac apply` derives from the key. A Core key has at least 32 characters and no whitespace. Web limits failed sign-ins.
 
-Scripts run on the Core host, call Core's loopback port and read the key from its file,
-which keeps it off the command line:
+### Script the Core API
+
+Run scripts on the Core host against Core's loopback port. This helper reads the key from its file, keeping it off the command line:
 
 ```sh
-curl -fsS -H @<(printf 'Authorization: Bearer %s\n' "$(cat "$HOME/.oac/core/secrets/core.key")") \
-  http://127.0.0.1:8091/core/v1/projects
+core() {  # core METHOD PATH [JSON body]
+  curl -fsS -X "$1" "http://127.0.0.1:8091/core/v1$2" \
+    -H @<(printf 'Authorization: Bearer %s\n' "$(cat ~/.oac/core/secrets/core.key)") \
+    -H 'Content-Type: application/json' ${3:+-d "$3"}
+}
 ```
 
+| Task | Command |
+| --- | --- |
+| List Projects | `core GET /projects` |
+| Create a Project | `core POST /projects '{"name": "billing-bot"}'` |
+| Issue an API key (shown once, as `key`) | `core POST /projects/$PROJECT_ID/keys '{"name": "prod"}'` |
+| Revoke a key | `core DELETE /projects/$PROJECT_ID/keys/$KEY_ID` |
+| Archive a Project (revokes all keys) | `core POST /projects/$PROJECT_ID/archive` |
+| See harnesses and their default models | `core GET /harnesses` |
+| Set Codex's default model | `core PUT /harnesses/codex/model-configuration '{"model": "your-model-id", "model_provider": {"protocol": "responses", "base_url": "https://provider.example/v1", "api_key": "sk-..."}}'` |
+| Installation facts, including the API base URL | `core GET /installation` |
+
+The [API index](../api/README.md#core-api) lists every route; errors use the [Core error envelope](../../contracts/agents-api/core-errors.md).
+
 ### Rotate the Core key
 
 ```sh
 ~/.oac/core/oac rotate-core-key
 ```
 
-It refuses while `config.json` has changes that are not applied or a generated file was
-edited by hand: run `oac apply` first. It asks for confirmation (`--yes` skips it),
-stops Web, writes a new key to `secrets/core.key` and regenerates the digest file. On a
-running installation it then restarts Core, starts Web and checks that Core accepts the
-new key and refuses the old one; a stopped installation only gets the new files and
-uses the new key at the next `oac start`. The old key stops working as soon as Core
-restarts, and every console session ends: sign in again and update your scripts. If the
-command stops early, `secrets/core.key` holds the key to use; run `oac apply` to
-finish.
-
-A separate Web-only installation keeps its own copy of the key. After rotating, copy
-`secrets/core.key` from the Core host into that installation's `secrets/core.key`
-(mode `0600`) and run its `oac apply`. Its `oac status` reports a key that Core
-refuses. `rotate-core-key` refuses to run on a Web-only installation.
+It refuses while `config.json` has changes that are not applied or a generated file was edited by hand: run `oac apply` first. It asks for confirmation (`--yes` skips it), stops Web, writes a new key to `secrets/core.key` and regenerates the digest file. On a running installation it then restarts Core, starts Web and checks that Core accepts the new key and refuses the old one; a stopped installation only gets the new files and uses the new key at the next `oac start`. The old key stops working as soon as Core restarts, and every console session ends: sign in again and update your scripts. If the command stops early, `secrets/core.key` holds the key to use; run `oac apply` to finish.
+
+A separate Web-only installation keeps its own copy of the key. After rotating, copy `secrets/core.key` from the Core host into that installation's `secrets/core.key` (mode `0600`) and run its `oac apply`. Its `oac status` reports a key that Core refuses. `rotate-core-key` refuses to run on a Web-only installation.
 
 ## Projects and API keys
 
-Create Projects and issue keys in Web, on **Projects and keys**, or through the
-[Core API](../../contracts/agents-api/admin-api.md) under `/core/v1/projects`. How
-Projects and keys behave is in [Projects own assets](../design-principles.md#projects-own-assets).
+Create Projects and issue keys in Web, on **Projects and keys**, or through the [Core API](#script-the-core-api). How Projects and keys behave is in [Projects own assets](../design-principles.md#projects-own-assets).
 
 To rotate an application key:
 
@@ -131,115 +116,67 @@ To rotate an application key:
 
 **Archive** disables every key of a Project and keeps its assets.
 
-## Data and current-release repair
+Core records which key made each public resource write; the retention of that history is [`core.write_audit_retention`](../configuration.md#settings).
 
-### Back up
+## Back up
 
 Back up these together; a restore needs all of them:
 
-- the PostgreSQL volume `<project>_database`. It holds Projects, key digests, nodes,
-  default models, encrypted credentials and all execution history, including large
-  objects. A logical dump:
+- the PostgreSQL volume `<project>_database`. It holds Projects, key digests, nodes, default models, encrypted credentials and all execution history, including large objects. A logical dump:
 
   ```sh
   docker compose -f "$HOME/.oac/core/generated/compose.json" exec -T database \
     pg_dump -U agents_api agents_api > oac-backup.sql
   ```
 
-- the installation directory: `config.json`, `state.json` (installation ID) and
-  `secrets/`. `credential.key` must stay with the database, or stored credentials can't
-  be decrypted; never regenerate it to get past an error.
+- the installation directory: `config.json`, `state.json` (installation ID) and `secrets/`. `credential.key` must stay with the database, or stored credentials can't be decrypted; never regenerate it to get past an error.
 - `state/e2b/`, when E2B is used: receipts Core needs to clean up E2B sandboxes.
-- each node's state directory on its host,
-  `/var/lib/oac-node/.oac/nodes/<installation-id>/`,
-  with its provider storage: Docker
-  volumes or microsandbox's store.
-- the bundle you installed from, to repair or recover the same release.
-
-A missing node state directory is a recovery incident: restore it with the database
-and provider storage rather than registering over existing resources. Never prune
-Docker volumes or delete native history to make a retry pass. A deleted Session does
-not prove that all provider resources were reclaimed.
+- each node's state directory on its host, `/var/lib/oac-node/.oac/nodes/<installation-id>/`, with its provider storage: Docker volumes or microsandbox's store. See [when a node host fails](nodes.md#when-a-node-host-fails) for restoring them.
+- the bundle you installed from, to repair the same release.
 
-### Installation version policy
+Never prune Docker volumes or delete native harness history to make a retry pass. A deleted Session does not prove that all provider resources were reclaimed.
 
-In-place version upgrades, downgrades and historical conversions are not supported.
-Keep existing data and installations intact; install the new release into a new,
-empty directory. There is no automatic data migration or history conversion.
+## Installation version policy
 
-Repair the current release with `./install.sh --install-dir DIR` from the exact
-same bundle. Repair preserves identity, settings, secrets and history. The installer
-and mutating `oac` commands use the same installation lock, including during repair
-and interrupted apply recovery. If another command owns it, retry after it finishes.
-Never remove or replace `.oac.lock` to bypass a busy installation.
+An installation runs one release for its whole life. In-place version upgrades, downgrades and historical conversions are not supported. Nothing migrates data between releases.
 
-Reinstallation never deletes another installation's files, database, Runtime
-resources or Session history.
+To move to a new release, install it into a new, empty directory, with its own database, Core key and nodes, and add nodes from its Web. Keep the old installation, its data and its nodes until their work is finished. Nodes run the program of the console that added them and are never upgraded in place; Core accepts only nodes that speak its own node protocol.
 
-### Machine connections
+Repair the current release by rerunning `./install.sh --install-dir DIR` from the exact same bundle; the downloader keeps it under `~/.oac/releases/`. Repair reloads missing images, restores the `oac` command, applies `config.json` and starts the services. It preserves identity, settings, secrets and history, accepts only `--install-dir`, and refuses a bundle from another release.
 
-Core and its nodes must come from the same distribution; the node installer refuses
-a mismatched release. Route `/api/v1/*`, including WebSocket upgrades, to Core;
-Web returns 404 there. This applies to Docker and microsandbox nodes, E2B and
-self-hosted executors. See
-[HTTPS and the reverse proxy](install.md#https-and-the-reverse-proxy).
+The installer and mutating `oac` commands hold the same installation lock, `.oac.lock`, including during repair and interrupted apply recovery. If another command holds it, retry after that command finishes; never remove or replace `.oac.lock` to get past a busy installation. Reinstallation never deletes another installation's files, database, Runtime resources or Session history.
 
 ## Troubleshooting
 
 | Symptom | Cause and fix |
 | --- | --- |
 | `Core installation requires Linux amd64 with Docker access` | Use Linux amd64 and an account with Docker access; root and ordinary users are supported |
-| `Installation failed; inspect prerequisites and private deployment files` | A prerequisite failed without its own message, most often Docker: check that `docker info` and `docker compose version` work for this user |
+| `Installation failed: inspect prerequisites and private deployment files` | A prerequisite failed without its own message, most often Docker: check that `docker info` and `docker compose version` work for this user |
 | `Docker Compose 2.26.0 or newer is required …` | Update the Docker Compose plugin |
 | `Port N is already in use; select another port` | Free the port, or install with `--core-port`/`--port` |
 | `Installation directory is not empty …` | Use an empty `--install-dir` |
 | `This installation is configured by …/config.json …` | Flags only seed a new installation: edit `config.json` and run `oac apply` |
-| `This installation version or historical conversion is not supported …` | Preserve the installation and data; [install separately](#installation-version-policy) |
+| `This installation version or historical conversion is not supported …` | The target directory holds an installation of another release, or a default install found one at `~/.parsar/core`. Keep it, and install into another empty `--install-dir` ([version policy](#installation-version-policy)) |
 | `generated/<file> was edited by hand` | Put the change in `config.json`, then `oac apply --discard-edits` |
 | `config.json has changes that are not applied` | Run `oac apply` |
 | `Core rejects secrets/core.key …` | Run `oac apply`, which restarts Core with the key's digest |
 | `config.json not applied: …` | `oac apply` printed Core's startup error above; fix `config.json` and apply again |
-| Web answers 403 `Forbidden` | Open exactly the console address `oac status` prints; the reverse proxy must pass the original Host |
-| `/v1` or `/api/v1` answers 404 | Those paths reach Web; route them to Core ([reverse proxy](install.md#https-and-the-reverse-proxy)) |
+| `HTTPS verification failed …` during domain setup | See [Configure the domain and HTTPS](install.md#configure-the-domain-and-https) |
+| Web answers 403 `Forbidden` | Open exactly the console address `oac status` prints; a reverse proxy must pass the original Host |
+| `/v1` or `/api/v1` answers 404 | Those paths reach Web; route them to Core ([reverse proxy](install-options.md#https-and-the-reverse-proxy)) |
 | Web shows that Core is unavailable (502) | Core is stopped or failing: `oac status`, then Core's log |
 | Session creation returns 400 `model_provider_required` | No model provider: set a [default model](../configuration.md#default-models) for the harness, or pass one; self-hosted Sessions always pass their own |
-| Add node says nodes need an HTTPS public URL | Set `public_url` and run `oac apply` |
-| Add node says the console has no node files | Install from the offline bundle, or add the node files and rerun `./install.sh` |
+| Add node shows no command | See [Before you add a node](nodes.md#before-you-add-a-node) |
 | A node is not ready | See [node troubleshooting](nodes.md#troubleshooting) |
 
 ## Exposure and network policy
 
-Core and Web listen on host loopback; PostgreSQL has no published port unless Core is
-native. Your TLS reverse proxy routes `/v1` and `/api/v1` to Core and everything else to
-Web. Web signs administrators in with the Core key, checks the origin of every request,
-and forwards signed-in `/core/v1` requests to Core with the Core key, which stays on
-the server. It answers 404 on `/v1` and `/api/v1` whatever credential a request carries,
-serves only the non-secret node payload at `/node-install/`, and has no Docker or KVM
-access. Machine routes keep their own enrollment and connection credentials. Web
-sign-in sessions live in Web's memory and last 12 hours.
-
-microsandbox uses an explicit network policy: public egress, the Core and DNS ports the
-Runtime needs, and no inbound or private-network access. Private model or MCP endpoints
-need an explicit policy change. The daemon does not enforce Session-level
-`disabled` or `restricted` networking. Combinations without the required outer
-network enforcement are unsupported; a requested mode is not an isolation guarantee.
-
-Docker isolates the Runtime at the outer container boundary. The daemon does not
-add an inner filesystem, permission or network sandbox. The node's service account
-needs the host's Docker daemon, and Core has no Docker socket. Install nodes on
-trusted hosts and do not share their Docker access with untrusted users.
-
-A Core restart leaves node services and resident microVMs running. A host reboot, the
-end of a user manager or the loss of a running microVM is not a Core restart and is not
-a qualified recovery workflow. Idle snapshots keep their recovery contract.
-
-### API-key write history
-
-Core records which key made each public resource write, for the console. Set
-`core.write_audit_retention` in `config.json` (Go duration, at least `1h`, default
-`2160h`) to control how long non-creation history is kept; creation ownership is kept
-for good. Removing keys or resources does not delete these records. See the
-[query contract](../../contracts/agents-api/write-audit.md); administrator mutations
-have a separate
-[audit log](../../contracts/agents-api/admin-api.md#monitoring-and-audit). Neither
-logs bodies or secrets.
+| Listener | Managed ingress (default) | External ingress |
+| --- | --- | --- |
+| Web | Reached only through the `gateway` service, which publishes `ports.web` (8080), 80 and 443 on `host` (all IPv4 interfaces by default) | `host:ports.web` (loopback by default), behind your reverse proxy |
+| Core | `127.0.0.1:ports.core` (8091); the gateway routes `/v1` and `/api/v1` to it | `host:ports.core`, behind your reverse proxy |
+| PostgreSQL | No published port | No published port, or a loopback port with native Core |
+
+Web signs administrators in with the Core key, checks the origin of every request, and forwards signed-in `/core/v1` requests to Core with the Core key, which stays on the server. It answers 404 on `/v1` and `/api/v1` whatever credential a request carries, serves only the non-secret node payload at `/node-install/`, and has no Docker or KVM access. Machine routes under `/api/v1` use their own enrollment and connection credentials. With managed ingress, the `installation` service applies domain changes through the Docker socket; Web reaches it only over a private Unix socket, and it checks the Core key on every request.
+
+Sandboxes are the isolation boundary ([Runtime and outer isolation](../design-principles.md#runtime-and-outer-isolation)). Docker sandboxes share the node's kernel, and a Docker node is [root-equivalent](nodes.md#what-the-installer-sets-up) on its host; microsandbox gives each sandbox a microVM with an explicit [network policy](nodes.md#what-the-installer-sets-up). Core itself has no Docker socket or KVM access.
diff --git a/docs/getting-started/quickstart.md b/docs/getting-started/quickstart.md
index 92d4b7bff..29e6ad915 100644
--- a/docs/getting-started/quickstart.md
+++ b/docs/getting-started/quickstart.md
@@ -1,24 +1,17 @@
 # Run your first Session
 
-This walkthrough takes you from a Project API key to an agent that has created a file
-and reported back. You need:
+This walkthrough takes you from a Project API key to an agent that has created a file and reported back. You need:
 
-- a Project API key and the API base URL, from your administrator
-  ([Sign in to Web](install.md#sign-in-to-web));
-- a ready node or E2B backend, so Core has somewhere to run the agent
-  ([Nodes](nodes.md));
+- a Project API key and the API base URL, from your administrator ([Issue a Project API key](install.md#issue-a-project-api-key));
+- a ready node or E2B backend, so Core has somewhere to run the agent ([Nodes](nodes.md));
 - Python 3.9 or newer;
-- a model: either the installation's default model, set by your administrator, or
-  your own provider's model ID, base URL and API key.
+- a model: the installation's default model, or your own provider's model ID, base URL and API key. [Model execution](../../contracts/agents-api/model-execution.md#saved-defaults-and-precedence) says which one a Session uses and which protocols each harness speaks.
 
-The example uses Codex, which needs a provider that speaks the OpenAI Responses API.
-Other harnesses and protocols are in the
-[user guide](../user-guide.md#choose-a-harness-and-a-model).
+The example uses Codex, whose model provider must speak the OpenAI Responses API.
 
 ## 1. Connect
 
-Core serves the OpenAI Agents API, so the official OpenAI SDK works unchanged. It
-reads two environment variables:
+Core serves the OpenAI Agents API, so the official OpenAI SDK works unchanged. It reads two environment variables:
 
 | Variable | Value |
 | --- | --- |
@@ -51,9 +44,7 @@ curl "$OPENAI_BASE_URL/agents" -H "OpenAI-Beta: agents=v1" \
 
 ## 2. Start a Session
 
-A Session is one agent conversation with its own workspace. With
-`openai_hosted`, Core creates a sandbox for it on a node or E2B and starts the harness
-inside.
+A Session is one agent conversation with its own workspace. With `openai_hosted`, Core creates a sandbox for it on a node or E2B and starts the harness inside.
 
 With the installation's default model, skip this. To use your own provider:
 
@@ -85,15 +76,12 @@ print(session.id)
 
 This makes a real model request and may incur charges.
 
-- `x_agents_core` holds Core's additions to the OpenAI API; see
-  [Core extensions](../api/public-agent-api.md#core-extensions-x_agents_core).
-- Keep the whole `agent` object in `extra_body`. SDK 3.13.0 replaces a body field with
-  the matching `extra_body` field instead of merging them.
+- `x_agents_core` holds Core's additions to the OpenAI API; see [Core extensions](../api/public-agent-api.md#core-extensions-x_agents_core).
+- Keep the whole `agent` object in `extra_body`. SDK 3.13.0 replaces a body field with the matching `extra_body` field instead of merging them.
 
 ## 3. Wait for the result
 
-A Session ID confirms creation, not success. Poll durable state; never resubmit to
-"retry":
+A Session ID confirms creation, not success. Poll durable state; never resubmit to "retry":
 
 ```python
 import time
@@ -112,8 +100,7 @@ else:
     raise TimeoutError(f"Session {session.id} is still running; inspect it before retrying")
 ```
 
-Success is a `completed` Turn whose Items describe the new file. A timeout neither
-cancels the work nor proves it failed.
+Success is a `completed` Turn whose Items describe the new file. A timeout neither cancels the work nor proves it failed.
 
 ## Next steps
 
diff --git a/docs/sandbox-provider.md b/docs/sandbox-provider.md
index c59a14371..8de6e5cc8 100644
--- a/docs/sandbox-provider.md
+++ b/docs/sandbox-provider.md
@@ -313,7 +313,7 @@ Environment provides isolation.
 
 | Kind | Adapter | Helper | Operator guide |
 | --- | --- | --- | --- |
-| Docker (node) | [`sandbox/docker`](../services/agents-api/internal/sandbox/docker) | Node proxy in [`sandbox/node`](../services/agents-api/internal/sandbox/node) | [Hosted sandbox manager](../services/agents-api/HOSTED-SANDBOX-MANAGER.md) |
+| Docker (node) | [`sandbox/docker`](../services/agents-api/internal/sandbox/docker) | Node proxy in [`sandbox/node`](../services/agents-api/internal/sandbox/node) | [Nodes](getting-started/nodes.md) |
 | microsandbox (node) | [`sandbox/microsandbox`](../services/agents-api/internal/sandbox/microsandbox) | [`tools/microsandbox-provider`](../services/agents-api/tools/microsandbox-provider) | [`deploy/microsandbox`](../services/agents-api/deploy/microsandbox/README.md) |
 | E2B (direct) | [`sandbox/e2b`](../services/agents-api/internal/sandbox/e2b) | [`tools/e2b-provider`](../services/agents-api/tools/e2b-provider/README.md) | [`deploy/e2b`](../services/agents-api/deploy/e2b/README.md) |
 
diff --git a/scripts/build-agents-api-release.sh b/scripts/build-agents-api-release.sh
index 26b775530..2d79c4bc2 100755
--- a/scripts/build-agents-api-release.sh
+++ b/scripts/build-agents-api-release.sh
@@ -88,7 +88,6 @@ if "@SOURCE_REVISION@" not in readme:
 readme = readme.replace("@SOURCE_REVISION@", revision).replace("@ARCHIVE_NAME@", archive_name.removesuffix(".tar.gz"))
 (package / "README.md").write_text(readme, encoding="utf-8")
 (package / "LICENSE").write_bytes((source / "LICENSE").read_bytes())
-(package / "HOSTED-SANDBOX-MANAGER.md").write_bytes((source / "services/agents-api/HOSTED-SANDBOX-MANAGER.md").read_bytes())
 manifest = {
     "artifact": "oac-core",
     "source": {"commit": revision, "tree": tree, "commit_timestamp": int(epoch)},
@@ -98,7 +97,7 @@ manifest = {
     "binaries": {"bin/" + name: {"sha256": sha256(package / "bin" / name)} for name in binaries},
 }
 (package / "manifest.json").write_text(json.dumps(manifest, indent=2, sort_keys=True) + "\n", encoding="utf-8")
-members = sorted(["bin/" + name for name in binaries] + ["LICENSE", "README.md", "HOSTED-SANDBOX-MANAGER.md", "manifest.json"])
+members = sorted(["bin/" + name for name in binaries] + ["LICENSE", "README.md", "manifest.json"])
 (package / "SHA256SUMS").write_text("".join(sha256(package / name) + "  " + name + "\n" for name in members), encoding="utf-8")
 members = sorted(members + ["SHA256SUMS"])
 prefix = archive_name.removesuffix(".tar.gz")
diff --git a/scripts/core-distribution-manifest.py b/scripts/core-distribution-manifest.py
index 6eb739b8d..2bf35c3e4 100644
--- a/scripts/core-distribution-manifest.py
+++ b/scripts/core-distribution-manifest.py
@@ -46,7 +46,6 @@
     "docs/getting-started/operations.md",
     "docs/getting-started/quickstart.md",
     "docs/getting-started/self-hosted.md",
-    "services/agents-api/HOSTED-SANDBOX-MANAGER.md",
     "contracts/agents-api/environment-executor-credentials.md",
 )
 # Files the bundled docs show, copied as they are, so they work offline.
diff --git a/scripts/name-allowlist.json b/scripts/name-allowlist.json
index ab1ac6587..387b32e61 100644
--- a/scripts/name-allowlist.json
+++ b/scripts/name-allowlist.json
@@ -464,11 +464,6 @@
     "regex": "(?:AGENTS_API_|AGENTS_CORE_WEB_)[A-Z0-9_]*\\*?",
     "reason": "These Web settings occur only in explicit retirement tables, diagnostics and rejection fixtures."
   },
-  {
-    "path": ".env.example",
-    "regex": "(?:AGENTS_API_|AGENTS_CORE_WEB_)[A-Z0-9_]*\\*?",
-    "reason": "These Web settings occur only in explicit retirement tables, diagnostics and rejection fixtures."
-  },
   {
     "path": "apps/web/PRODUCT.md",
     "regex": "(?:AGENTS_API_|AGENTS_CORE_WEB_)[A-Z0-9_]*\\*?",
@@ -579,11 +574,6 @@
     "regex": "(?:AGENTS_API_|CORE_CONSOLE_|PARSAR_)[A-Z0-9_]*\\*?|X-Parsar-Node-ID",
     "reason": "These names appear in retirement documentation or instructions for an explicitly pinned historical release; current configuration uses OAC settings."
   },
-  {
-    "path": "docs/configuration.md",
-    "regex": "(?:AGENTS_API_|CORE_CONSOLE_|PARSAR_)[A-Z0-9_]*\\*?|X-Parsar-Node-ID",
-    "reason": "These names appear in retirement documentation or instructions for an explicitly pinned historical release; current configuration uses OAC settings."
-  },
   {
     "path": "contracts/agents-api/environment-templates.md",
     "regex": "(?:AGENTS_API_|CORE_CONSOLE_|PARSAR_)[A-Z0-9_]*\\*?|X-Parsar-Node-ID",
@@ -609,11 +599,6 @@
     "regex": "(?:AGENTS_API_|CORE_CONSOLE_|PARSAR_)[A-Z0-9_]*\\*?|X-Parsar-Node-ID",
     "reason": "These names appear in retirement documentation or instructions for an explicitly pinned historical release; current configuration uses OAC settings."
   },
-  {
-    "path": "services/agents-api/HOSTED-SANDBOX-MANAGER.md",
-    "regex": "(?:AGENTS_API_|CORE_CONSOLE_|PARSAR_)[A-Z0-9_]*\\*?|X-Parsar-Node-ID",
-    "reason": "These names appear in retirement documentation or instructions for an explicitly pinned historical release; current configuration uses OAC settings."
-  },
   {
     "path": "services/agents-api/deploy/codex/README.md",
     "regex": "(?:AGENTS_API_|CORE_CONSOLE_|PARSAR_)[A-Z0-9_]*\\*?|X-Parsar-Node-ID",
@@ -629,25 +614,10 @@
     "regex": "parsar-core-runtime@",
     "reason": "Documents the one old stored reference prefix rewritten by the guarded database migration."
   },
-  {
-    "path": "docs/getting-started/install.md",
-    "regex": "~?/\\.parsar/core",
-    "reason": "The installer refuses the old default installation and directs the operator to conversion."
-  },
-  {
-    "path": "docs/getting-started/nodes.md",
-    "regex": "parsar-node(?:-[A-Za-z0-9<>_.-]*)?|\\.parsar/nodes",
-    "reason": "The legacy-node section gives scoped uninstall instructions; new installation and enrollment examples use oac-node."
-  },
-  {
-    "path": "docs/getting-started/operations.md",
-    "regex": "(?:AGENTS_API_|CORE_CONSOLE_|PARSAR_)[A-Z0-9_]*\\*?|parsar(?:[A-Za-z0-9_.*/-]*)|agents-api(?:-[a-z0-9*-]+)?|core-console|agents-runtime-",
-    "reason": "The conversion and retirement table must name the exact old commands, paths, labels, settings and retained backups that operators migrate."
-  },
   {
     "path": "docs/getting-started/operations.md",
-    "regex": "Parsar-product hooks",
-    "reason": "These exact phrases refer to the separate Parsar product, its ownership or historical source, not the OpenAgentCore brand."
+    "regex": "~/\\.parsar/core",
+    "reason": "A default install refuses while this path holds an installation of an earlier release; the troubleshooting row names it."
   },
   {
     "path": "scripts/verify-source-copy.py",
@@ -694,30 +664,10 @@
     "regex": "including Parsar",
     "reason": "Generated copy of docs/web/architecture.md: These exact phrases refer to the separate Parsar product, its ownership or historical source, not the OpenAgentCore brand."
   },
-  {
-    "path": "apps/docs/content/docs/install.mdx",
-    "regex": "~?/\\.parsar/core",
-    "reason": "Generated copy of docs/getting-started/install.md: The installer refuses the old default installation and directs the operator to conversion."
-  },
-  {
-    "path": "apps/docs/content/docs/configure.mdx",
-    "regex": "(?:AGENTS_API_|CORE_CONSOLE_|PARSAR_)[A-Z0-9_]*\\*?|X-Parsar-Node-ID",
-    "reason": "Generated copy of docs/configuration.md: These names appear in retirement documentation or instructions for an explicitly pinned historical release; current configuration uses OAC settings."
-  },
-  {
-    "path": "apps/docs/content/docs/hosted-providers.mdx",
-    "regex": "parsar-node(?:-[A-Za-z0-9<>_.-]*)?|\\.parsar/nodes",
-    "reason": "Generated copy of docs/getting-started/nodes.md: The legacy-node section gives scoped uninstall instructions; new installation and enrollment examples use oac-node."
-  },
-  {
-    "path": "apps/docs/content/docs/troubleshooting.mdx",
-    "regex": "(?:AGENTS_API_|CORE_CONSOLE_|PARSAR_)[A-Z0-9_]*\\*?|parsar(?:[A-Za-z0-9_.*/-]*)|agents-api(?:-[a-z0-9*-]+)?|core-console|agents-runtime-",
-    "reason": "Generated copy of docs/getting-started/operations.md: The conversion and retirement table must name the exact old commands, paths, labels, settings and retained backups that operators migrate."
-  },
   {
     "path": "apps/docs/content/docs/troubleshooting.mdx",
-    "regex": "Parsar-product hooks",
-    "reason": "Generated copy of docs/getting-started/operations.md: These exact phrases refer to the separate Parsar product, its ownership or historical source, not the OpenAgentCore brand."
+    "regex": "~/\\.parsar/core",
+    "reason": "Generated copy of docs/getting-started/operations.md: A default install refuses while this path holds an installation of an earlier release; the troubleshooting row names it."
   },
   {
     "path": "apps/docs/lib/legacy-redirects.ts",
diff --git a/services/agents-api/HOSTED-SANDBOX-MANAGER.md b/services/agents-api/HOSTED-SANDBOX-MANAGER.md
deleted file mode 100644
index 5adc6ad2a..000000000
--- a/services/agents-api/HOSTED-SANDBOX-MANAGER.md
+++ /dev/null
@@ -1,422 +0,0 @@
-# Nodes and sandbox backends: operator reference
-
-This reference is for operators who need the details behind Web's **Nodes** page
-(shown as **Sandbox backend** when the deployment uses E2B): the node protocol,
-manual registration, placement, reset and failure handling. To add, remove or
-troubleshoot a node, start with the [nodes guide](../../docs/getting-started/nodes.md).
-
-One Core execution owner manages sandbox nodes on its own host and on other Linux
-hosts, or provisions cloud sandboxes directly through E2B. A deployment selects
-exactly one provider: `e2b`, `docker` or `microsandbox`. PostgreSQL owns that
-selection, the per-sandbox resource limits and the immutable Runtime release.
-Docker and microsandbox nodes must match its installation, generation and
-specification. These nodes are distinct from user-managed `self_hosted` Environments,
-whose provisioning remains the application's responsibility.
-
-The Nodes page uses the Core key, separate from Project API keys. After console
-sign-in, the console server forwards the page's `/core/v1/sandbox` requests, like
-every other `/core/v1` request, with the Core key it reads from its private file; the
-key never reaches the browser. For a Web you run without the installer, configure the
-private `0600` key file through `OAC_WEB_CORE_KEY_FILE`; Web refuses to start
-without it. Core serves the deployment and node routes only when
-`OAC_INSTALLATION_ID` is set. Project keys cannot register, edit or
-remove nodes. The node installation payload that Web serves contains no secret.
-
-## Sandbox backend selection
-
-A new installation selects microsandbox at Web's Standard size unless
-`install.sh --sandbox` chose Docker, E2B or none. Without a selection, the
-**Nodes** page first asks for **E2B cloud** or **Own machines**; own machines then
-choose Docker or microsandbox, the per-sandbox resources and the matched Runtime
-release. E2B takes an account API key and a qualified immutable Runtime template build
-(`template-id:build-uuid`) that must be ready before the selection can be saved. E2B
-CPU and memory limits are optional: Web sends none, and Core adopts the build's size;
-supplied limits must match the build. The key is write-only, encrypted by Core and
-never returned to the browser. E2B needs no node installation.
-
-Setup takes no Core address. Nodes and guests use the installation public URL, where
-the reverse proxy sends `/api/v1`, including WebSocket upgrades, directly to Core; Web
-does not forward it. The deployment reports it as the read-only `core_url`. E2B
-requires a public URL that is not loopback; a loopback public URL serves only local
-development, because a guest's loopback address cannot reach its Core host.
-
-**Save configuration** validates and initializes the deployment without creating
-compute. A failed candidate leaves the previous selection intact. Refresh after an
-uncertain response before trying again. The selection persists in PostgreSQL and
-activates without a restart; removing all nodes does not reset it. E2B uses the same
-daemon, harness and workspace Runtime as node-backed hosting. Configuration alone does
-not prove provider or model readiness. To prepare the qualified E2B Runtime build, use
-[the E2B build guide](deploy/e2b/README.md); it is not a public Environment Template.
-Microsandbox suspends eligible idle Sessions after 300 seconds and retains their
-snapshots for 86400 seconds. Docker and E2B have no memory snapshot policy.
-A node's allocation list reports `compute_phase_changed_at`, the time each
-allocation entered its current `compute_phase`, or null when unknown; an allocation
-that existed before Core recorded it reports null until its next phase change. A
-suspended allocation's age, combined with this retention, tells roughly when Core
-reclaims it.
-See [what each field means per sandbox provider](../../contracts/agents-api/sandbox-deployment.md#what-each-field-means-per-sandbox-provider)
-for fields that differ between E2B, Docker and microsandbox.
-
-For deployments without the installer that use E2B, install the packaged helper and set
-`OAC_E2B_PROVIDER_BIN` to its absolute executable path. Set
-`OAC_E2B_STATE_DIR` to a persistent directory owned by the Core service user,
-mode `0700`. The standard distribution prepares both. Back up this private state
-with the database and credential-encryption key; losing it can leave an uncertain
-allocation that cannot safely be reclaimed. Do not mount it into Web or Runtime.
-
-Replace an E2B key through the full deployment PUT, using the current template and
-observed generation. Core verifies team ownership and all retained resources before
-committing it. Omit api_key to preserve it; explicitly supplying the same key still
-verifies and advances generation. Revoke the old key only after a successful response.
-Missing or unsettled receipts, another team, or unconfirmed provider reads reject
-without changing the active key. Do not clear allocations or receipts to bypass this.
-See [generation and credential guarantees](../../contracts/agents-api/sandbox-deployment.md#generation-ownership-and-rollout).
-
-For own machines, **Add node** generates a one-time command that uses the
-installation public URL. Before installing, the node installer reads the active
-specification with its enrollment token; this read does not consume the token. The
-local provider file is an installed copy of the server configuration and cannot select
-a different Runtime or resource profile. Closing the dialog discards its one-time
-command. An expired command requires explicit regeneration; failed or uncertain writes
-are never retried automatically. Registration itself creates no Session, sandbox or
-model request. Hosted Session admission fails until setup is complete and a ready node
-has capacity. E2B allocates directly without this node requirement.
-
-For deployments without the installer and with zero nodes, set
-`OAC_INSTALLATION_ID` to a stable UUID, configure
-`OAC_CORE_KEY_DIGESTS_FILE`, and enable the daemon gateway with
-`OAC_PUBLIC_URL`. Core derives the hosted Runtime bootstrap and the public
-daemon WebSocket address from that URL; it never uses the request Host or forwarded
-headers. Preserve the installation UUID and database together.
-
-Use the live sandbox deployment response (`GET /core/v1/sandbox/deployment`) for
-the current selection, including one made after startup.
-
-## Resources and Runtime
-
-The same deployment specification applies to every hosted sandbox. CPU count and
-memory in MiB are required for Docker and microsandbox; E2B may omit them and adopt
-its template build's size. Microsandbox also requires separate root and
-`/environment` disk capacities. Docker and E2B reject nonzero independent disk
-limits because this contract does not enforce those hard quotas. Node active and
-retained reservation limits are separate controls; they do not resize a sandbox.
-
-For Docker/microsandbox, select one verified distribution containing its source
-commit, Docker image ID, OCI manifest digest, microsandbox image reference,
-Runtime binary SHA-256 and firmware SHA-256. The node installer compares these
-identities with the downloaded manifest and checks installed provider settings.
-E2B selects its immutable Runtime through the template build instead. See the
-[deployment protocol](../../contracts/agents-api/sandbox-deployment.md) for fields,
-validation and safe response shapes. The response's `specification.resources`
-contains limits; its top-level `resources` contains cleanup counts.
-
-The Core installer never enrolls its own host. The Core host joins like any other
-host, through **Add node**, with the same database selection and registration
-checks. Node identity and configuration live under
-`~/.oac/nodes/<installation-id>/` in the home of the account that runs the node
-(`/var/lib/oac-node` for a node added with sudo); preserve that private directory
-and its backend storage together. Core has no embedded local provider configuration or node
-identity mount.
-
-## Older file-managed installations
-
-Core rejects `AGENTS_API_MANAGED_RUNTIMES_FILE`. Historical file-managed
-installations are unsupported and have no conversion procedure. Preserve their
-original database, backend resources, Runtime history, private receipts and node
-state; do not clear rows or prune provider storage to bypass a refusal. Install the
-current release separately using its database-managed deployment. Removing an old
-setting does not transfer resource ownership or authorize data deletion. See the
-[installation version policy](../../docs/getting-started/operations.md#installation-version-policy).
-
-## Register a host
-
-Web's **Add node** command is the supported way to register a host; the
-[nodes guide](../../docs/getting-started/nodes.md) describes its required root/sudo
-installation, the `oac-node` service account, removal and troubleshooting. The command downloads only a
-matched bootstrap from `/node-install/`, then checksum-verified prebuilt assets from
-the same console's payload, never from a release URL the build recorded. The console
-must hold them: install from the offline bundle, or place the release assets in the
-bundle's `artifacts/` directory first; `/console/config` lists the providers whose
-assets it holds (`node_artifacts`). The enrollment token is transient and never a
-console or Project credential; the command passes it to the installer on standard
-input (`--enrollment-token-stdin`).
-
-Nodes use only these machine connection routes, authenticated by their own
-credentials. Web does not forward them, and no administrator credential applies. The
-reverse proxy routes `/api/v1`, with WebSocket upgrades, directly to Core; see
-[HTTPS and the reverse proxy](../../docs/getting-started/install.md#https-and-the-reverse-proxy).
-
-| Route | Credential |
-| --- | --- |
-| `GET /api/v1/sandbox-node/configuration` | Enrollment token, or node credential with `X-OAC-Node-ID` |
-| `POST /api/v1/sandbox-node/enroll` | One-use enrollment token |
-| `GET /api/v1/sandbox-node/identity?node_id=` | Node credential |
-| WebSocket `GET /api/v1/sandbox-node/connect?node_id=` | Node credential |
-
-Enrollment sends the Core origin the node stores (`core_url`, from `register
---core-url`). Core refuses one that is not the installation public URL with 409
-`sandbox_node_address_mismatch`, before consuming the token, so a node never records
-an address Core no longer uses. `POST /core/v1/sandbox/enrollment-tokens` also returns
-a non-secret `enrollment_id`; the node it registers reports the same value in
-`/core/v1/sandbox/nodes`, and nodes enrolled before Core recorded it report null.
-
-A node and its Core must come from the same distribution. Historical machine
-protocols and in-place version upgrades are unsupported. Preserve older
-installations and resources; provision current-release nodes separately. See the
-[installation version policy](../../docs/getting-started/operations.md#installation-version-policy).
-Rerunning the same command preserves the node's private identity. A registered retry
-reads configuration with its retained node credential and `X-OAC-Node-ID`; it does
-not enroll again. Changes to the Core origin, installation, generation, specification
-or release are refused without rewriting state.
-
-### Manual registration
-
-Manual registration remains available for operator-managed payloads. These nodes use
-the same current wire version and exact generation routing as installer-managed
-nodes; they do not advertise automatic generation preparation. Build or install
-`oac-node` from the same Core release. On the host, first read
-`GET /api/v1/sandbox-node/configuration` with the enrollment Bearer token. Build the
-private provider JSON from its `provider`, `installation_id`, `core_url` (the
-installation public URL), `generation` and `specification`, plus one adapter object
-for the host:
-
-- Docker: an explicit Unix socket `host`, the locally imported `image`, `network`,
-  `extra_hosts` and an absolute `seccomp_file`, with the existing nested-sandbox
-  security settings. The imported image must match the approved Runtime release.
-- Microsandbox: absolute `helper_path`, `runtime_home`, `runtime_path` and
-  `firmware_path`, the host network policy and validated resource and Runtime copies.
-  The runtime home is an existing private backend namespace. The native Unix socket
-  limit requires `$HOME/.oac/m/<12-character installation hash>` to fit within 48
-  encoded bytes; the installer rejects a longer path before creating node state, so
-  use a service account with a shorter persistent home.
-
-The node file has no `max_active`, `max_retained`, idle-policy or reset
-override, and a node never receives arbitrary host paths from the browser. Editing the
-downloaded specification does not change Core: the node validates its content and file
-hashes, and Core compares its digest at enrollment and on every connection. A mismatch
-rejects work until the approved configuration is restored. Node capacity is approved by
-Core when the administrator creates an enrollment token and retained in PostgreSQL;
-registration and node files can't overwrite it. See
-[Node capacity](../../docs/configuration.md#node-capacity).
-
-Save the single-use registration token in a `0600` file on the host; it expires after
-the duration shown by Core. Run, with real absolute paths:
-
-```sh
-oac-node register \
-  --config /var/lib/oac/provider.json \
-  --state-dir /var/lib/oac/node \
-  --core-url https://core.example \
-  --name worker-1 \
-  --enrollment-token-file /var/lib/oac/enrollment-token
-oac-node run \
-  --config /var/lib/oac/provider.json \
-  --state-dir /var/lib/oac/node
-```
-
-Run the second command under the host's service supervisor. The node initiates
-its connection to Core; Core does not need SSH or an exposed Docker TCP daemon.
-Registration persists the node identity before contacting Core, allowing a lost
-registration response to be recovered without replacing the identity. Keep the
-state directory on persistent storage, private to the node service account.
-One process owns it at a time. Do not copy a node identity into another state
-directory or onto another host. Core rejects duplicate connections while the
-original connection is opening, live or finishing disconnect cleanup. A half-open
-connection must reach its heartbeat timeout before a reconnect can be admitted;
-the node retries with bounded backoff. These checks do not attest physical host
-identity. The enrollment token is not the node credential. Reconnection reads the
-current capacity from the database; it never writes local limits back to Core.
-
-## Placement and recovery
-
-Session creation chooses an available node automatically; callers cannot select
-one. Placement commits with Session creation and remains fixed across creation
-retries, later Turns and resume. Administrators see each node's allocations under
-`/core/v1/sandbox/nodes`.
-
-Microsandbox suspends only after a Turn has finished, no work is pending, and the
-idle interval has passed. Core measures terminal activity from its database's
-first committed completion observation, so clock differences between hosts do not
-shorten or extend that idle interval. Public native timestamps remain unchanged;
-repeated completion observations and heartbeats do not reset the idle timer.
-Idle eligibility and its final transaction check use the database observation
-clock, including when PostgreSQL runs on a different host from Core. Snapshot
-retention starts from the same clock.
-Its full snapshot preserves guest state, files and configuration; a completed
-Agent process is not recreated as a resident process. Native restore can omit an
-explicit root-disk size because that disk is inherited from the verified snapshot.
-Core requires matching snapshot resource proof and exact target identity for this
-case; other CPU, memory and environment-disk limits must still match. This is not
-permission to resize a retained sandbox.
-Docker remains supported without promising memory snapshots. Disconnecting a
-node does not delete or move its Sessions. An hour without internal observation
-keepalives no longer authorizes cleanup of a node-managed allocation. Reconnect the original node to observe
-and continue its existing resources. Unknown creation, initialization, capture
-and restore results do not authorize request replay or a replacement sandbox.
-
-## Removal and reset
-
-There is no per-node drain switch. Online, eligible nodes participate
-automatically. A node with instances, retained snapshots, pending allocations,
-unknown operations or cleanup records cannot be removed. Resolve those resources
-through their normal lifecycle and then retry; the API reports the conflict.
-Offline resources remain owned and visible. Explicit removal permanently retires
-the node identity; adding that host again requires a fresh private state directory.
-After removal, clean up the host with the installer's `--uninstall`, which Web shows
-as **Clean up the host**; see [Remove a node](../../docs/getting-started/nodes.md#remove-a-node).
-Uninstall proceeds only when Core answers 401 to the node's credential, or with
-`--force` for a Core address that no longer answers. It never removes sandboxes,
-volumes or images. The node program exits with status 78 when Core answers 401 to its
-credential, and the installed service does not restart it. Other failures, including
-an unreachable Core or a 403 from a proxy in front of it, restart the service every
-5 seconds without a start limit. Ordinary disconnects and host restarts reuse the
-original identity.
-
-E2B same-team key/build/resource edits apply online; existing sandboxes retain their
-original generation and new allocations use the new selection. Initial setup requires
-the selected template to belong to the submitted key's team, even if another team's
-public template is readable. Online replacement verifies the current exact template
-in both the committed and candidate keys' team-owned listings. This is a shared
-ownership anchor; Core does not invent a team ID from public readability. Legacy
-selections without this anchor and revoked committed keys require reset
-(`sandbox_reset_required`); transport or unsettled ownership remains unconfirmed (503).
-Keep the old key valid until PUT returns 200, then revoke it. A rejected change keeps
-the current key, generation and resource owners. Docker/microsandbox
-resource/Runtime edits use the observed generation and the current node generation
-protocol. Installer-managed nodes advertise automatic generation preparation; manual
-fixed-configuration nodes retain their enrolled generation and require explicit
-operator preparation for a new target. Submit once and read back after uncertain responses.
-
-Deployment rollout reports old-generation resource counts separately from preparation.
-Poll frequently only while reset is active or rollout.state is preparing. E2B updates
-settle immediately; old Sessions can remain indefinitely without implying preparation.
-Offline node rollout is unknown, and ready_generation is a durable pin rather than
-proof that the node is online. Node update_required and failed states are settled.
-
-Changing backend requires an explicit reset. POST
-`/core/v1/sandbox/deployment/reset` with `expected_generation` and `clear: auto`
-(default deadline 3600 seconds, configurable from 300 to 86400) or `clear: force`
-(without a deadline). Auto archives idle, queued and suspended hosted Sessions,
-waits for work in progress/waiting and pending file writes, then escalates at its
-durable deadline. Force requests cancellation and ordinary verified cleanup.
-Self-hosted work is excluded. Fresh hosted admission closes during reset; existing
-live input, known receipts, restoration and cleanup continue.
-
-Read `reset.remaining` for busy/idle/cleanup and the authoritative offline-node
-subset. Offline or failed cleanup still blocks completion. Bring those nodes back
-for cleanup; a node with resources cannot be removed. Once verified counts reach
-zero Core clears the selection, retires nodes/tokens and advances generation while
-preserving installation identity, history and persisted Files/Artifacts. Then POST
-a new selection with the returned generation. Cancel with DELETE on the reset route
-and `expected_generation` query; it stops remaining archives, not cleanup already
-requested, and does not restore workspace or revive archived Sessions.
-
-Explicitly archive an individual hosted Session at any time through
-`POST /core/v1/projects/{project_id}/sessions/{session_id}/archive` with its current
-deployment generation. Poll GET on that path for `released`; resource release does
-not prove an active Turn has finished cancellation. History and persisted
-Files/Artifacts survive, but unpersisted workspace is lost and the original Session
-cannot resume. See the [archive contract](../../contracts/agents-api/admin-api.md#administrative-session-archive).
-
-After any uncertain mutation, refresh authoritative state before another explicit
-write; do not replay automatically. Every setup/update/reset/cancel write uses the
-observed generation, including zero for initial setup. The retired maintenance PATCH
-returns authenticated 404. See the [sandbox deployment contract](../../contracts/agents-api/sandbox-deployment.md)
-for precise reset, concurrency and error semantics. None of these requests changes
-the installation's public Core address or migrates existing Sessions.
-
-This release has one Core execution owner. It does not add Core multi-active,
-cross-node snapshot restore, automatic failover, Kubernetes or autoscaling.
-
-## Node and host failures
-
-A restarted node service reuses its saved identity and checks the original
-resources. After a host reboot, Core observes the exact instance or already
-authorized snapshot; it does not silently cold-start a replacement. Missing or
-corrupt resources remain owned and appear with a sanitized diagnostic. Restore
-the original host/storage or explicitly resolve the affected Session. Preserve
-the identity directory alongside backend storage backups: losing that directory
-is a recovery incident, not permission to register over existing resources.
-
-Each registered node has an independent serial lifecycle worker, including its
-resource scans, pending creation, initialization and direct provisioning. A slow
-or stuck helper on one node does not hold another node's lifecycle gate or scan
-page. Offline workers retain their resource records and resume observation after
-reconnection. Lifecycle concurrency is one operation per node, so its total grows
-with the registered node count; there is no fixed global provider concurrency
-limit. The single Core execution lease and atomic per-node capacity checks remain
-in force. Losing the execution lease stops every worker; an ordinary provider
-failure affects only its node. Shutdown cancels and drains workers and direct
-provisioning before releasing that lease.
-
-Connections use heartbeats and bounded reconnect backoff. Operation timeouts are
-relative budgets measured locally on receipt, so host wall-clock skew cannot
-misclassify a fresh operation as expired. Temporary database or
-network failures remain retryable; invalid credentials and identity mismatches
-require operator intervention. Old connection and execution epochs cannot
-authorize new work after replacement. These controls do not recover lost disks
-or migrate a Session to another host.
-
-Core runs node authentication, ownership and storage callbacks outside the Hub's
-connection-state mutex, with cancellation and a five-second limit. Hub shutdown
-cancels opening and live connections without waiting for database callbacks.
-A node's connection reservation remains held until its fenced disconnect cleanup
-finishes; a slow database must not allow a competing connection to take its place.
-
-## Node readiness diagnostics
-
-Each heartbeat reports whether the node's local provider is ready. When it is
-not, the node list and node detail (`GET /core/v1/sandbox/nodes` and
-`GET /core/v1/sandbox/nodes/{node_id}`) carry one fixed `diagnostic` code. The
-field is absent while the provider is ready. An offline node keeps its last
-reported value, so check `online` first.
-
-The codes, their causes and fixes are listed in the
-[nodes guide](../../docs/getting-started/nodes.md#readiness-codes).
-
-A node reports only its first failed check. Checks run from the provider platform
-(Docker daemon or KVM), through Docker limit support and host capacity, to the
-installed Runtime content. An unreachable Docker daemon therefore hides a missing
-image, and missing KVM hides missing artifacts or insufficient capacity. After a
-fix, the next heartbeat (about ten seconds) checks again and clears or replaces
-the code. Repaired Runtime artifacts, a pulled image or a started Docker daemon
-recover this way. A new Docker or KVM group membership applies only to a new
-process: restart the node service (`sudo systemctl restart
-oac-node-<installation_id>.service`; omit sudo in a root shell). The service journal's warning includes the local error behind the code;
-that text never leaves the host.
-
-Only the code crosses the node connection. Probe errors can name host paths or
-contain daemon messages; they are not sent to Core, stored or returned. Core stores
-any other reported value as `provider_unavailable`. Core and nodes must use the
-same distribution; this defensive mapping does not establish support for mixed
-program versions or an in-place upgrade sequence.
-
-## Runtime observations
-
-The existing Runtime observation and history APIs route managed reads to the
-Session's original node. Reading metrics does not wake a suspended sandbox or
-reset its idle timer. An offline node or a provider without an observation source
-returns unavailable telemetry. Provider timestamps retain their existing
-validation, so excessive node/Core clock skew can also make a sample unavailable;
-suspension eligibility continues to use database time.
-
-## Historical installations
-
-Historical upgrades and resource adoption are unsupported. Core does not verify
-old allocation receipts to bind them to a new node, manufacture placements for
-pending Sessions, or reconnect nodes whose deployment has no valid specification.
-Startup rejects an incompatible saved selection before claiming its owner epoch.
-New installations use a separate database and state directory, select a deployment
-specification, and enroll nodes through the current configuration protocol.
-
-Keep the previous Core, its database, credentials, node identities and provider
-resources together until its work and cleanup are settled. Running compute,
-retained snapshots, uncertain create/restore operations and unconfirmed cleanup
-remain that installation's responsibility. Do not point a new installation at
-those resources, erase their receipts, or treat a refused startup as cleanup.
-Operators must explicitly settle them using the original installation before
-retiring it. This release does not perform that operation during startup.
-
-Current-version reconnect, immutable placement, maintenance fencing, idempotent
-receipts, cancellation and cleanup confirmation still apply. Released allocation
-history remains stored; it is never rebound to another node.
diff --git a/services/agents-api/IMPLEMENTATION.md b/services/agents-api/IMPLEMENTATION.md
index 99738e862..b2f254778 100644
--- a/services/agents-api/IMPLEMENTATION.md
+++ b/services/agents-api/IMPLEMENTATION.md
@@ -1345,7 +1345,7 @@ Web exposes one root/sudo command; do not retain a user-service alternative. Thi
 boundary is specific to Sandbox Provider nodes, not native self-hosted daemons.
 
 Node management (Web's **Nodes** page; see the
-[operator reference](HOSTED-SANDBOX-MANAGER.md)) is a
+[nodes guide](../../docs/getting-started/nodes.md)) is a
 deployment-level admin surface, separate from Project credentials. The paired
 console's Core key stays on its server. Enrollment credentials authorize
 initial node configuration reads and registration; durable node credentials authorize
diff --git a/services/agents-api/README.md b/services/agents-api/README.md
index 14bc92f13..20177ec9a 100644
--- a/services/agents-api/README.md
+++ b/services/agents-api/README.md
@@ -266,7 +266,7 @@ explicit operator configuration. Select the qualified native image using the
 [engine profile guides](../../contracts/agents-api/README.md#public-engine-profiles),
 then follow the [Docker setup](deploy/codex/README.md#standalone-operator-configuration).
 Core-managed hosting supports deployment-selected E2B, Docker or microsandbox;
-see the [nodes and sandbox backends reference](HOSTED-SANDBOX-MANAGER.md). For the separate
+see the [nodes guide](../../docs/getting-started/nodes.md). For the separate
 user-managed E2B path, see
 [E2B Runtime packaging](deploy/e2b/README.md).
 Core remains independently deployed with its own database. Public idle and initial
@@ -469,7 +469,7 @@ V1 uses our daemon as the user-side executor. Deploy daemon, selected harness,
 local tools and protected `/workspace` together using the shared Runtime. For this caller-managed path, the user owns local or E2B allocation, renewal
 and destruction; use the official E2B SDK through the
 [E2B guide](deploy/e2b/README.md). Deployment-managed E2B, Docker and microsandbox
-are separate hosted choices in the [nodes and sandbox backends reference](HOSTED-SANDBOX-MANAGER.md).
+are separate hosted choices in the [nodes guide](../../docs/getting-started/nodes.md).
 
 Create a Session with `environment={"type":"self_hosted",
 "workspace_directory":"/workspace"}` and empty/default capability directories.
@@ -678,9 +678,8 @@ success alone establishes neither native readiness nor filesystem isolation.
 ## Hosted sandbox nodes
 
 The release includes `oac-node` for local and remote hosts. Add nodes with
-Web's one-command flow in the [nodes guide](../../docs/getting-started/nodes.md); the
-[operator reference](HOSTED-SANDBOX-MANAGER.md) covers provider selection, manual
-registration, administrator credentials, fixed Session placement and reset.
+Web's one-command flow in the [nodes guide](../../docs/getting-started/nodes.md), which
+also covers provider selection, manual registration and reset.
 
 Implementation rules for hosted sandbox nodes and optional suspension are in
 [Agents API implementation constraints](IMPLEMENTATION.md#hosted-sandbox-nodes-and-optional-suspension).
diff --git a/services/agents-api/deploy/codex/README.md b/services/agents-api/deploy/codex/README.md
index 729ca5d5a..699b2169f 100644
--- a/services/agents-api/deploy/codex/README.md
+++ b/services/agents-api/deploy/codex/README.md
@@ -96,7 +96,7 @@ Core host joins through the same command as any other host.
 Same-provider resource and Runtime edits currently require no active reset,
 the current generation and verified zero held allocations or pending Environments.
 A backend change requires explicit reset and confirmed cleanup, then a new setup.
-See the [reset procedure](../../HOSTED-SANDBOX-MANAGER.md#removal-and-reset).
+See the [reset procedure](../../../../docs/getting-started/nodes.md#change-the-sandbox-configuration).
 Stopped compute, snapshots and unknown operations remain blockers. Keep the original
 node identity, paths and credentials until cleanup is confirmed. Explicit archive
 preserves history and persisted Files/Artifacts but discards unpersisted workspace;
diff --git a/services/agents-api/deploy/microsandbox/README.md b/services/agents-api/deploy/microsandbox/README.md
index 8d9b07ed1..710fde673 100644
--- a/services/agents-api/deploy/microsandbox/README.md
+++ b/services/agents-api/deploy/microsandbox/README.md
@@ -13,9 +13,8 @@ files and configuration. Native harness startup and shutdown retain their existi
 behavior. This profile uses microsandbox v0.7.2; the helper performs one finite
 operation and exits.
 
-Start with the [installation guide](../../../../docs/getting-started/install.md),
-the [nodes guide](../../../../docs/getting-started/nodes.md) and the
-[nodes operator reference](../../HOSTED-SANDBOX-MANAGER.md). The
+Start with the [installation guide](../../../../docs/getting-started/install.md)
+and the [nodes guide](../../../../docs/getting-started/nodes.md). The
 [deployment configuration contract](../../../../contracts/agents-api/sandbox-deployment.md)
 defines the saved selection, resources, Runtime identity and node authorization.
 The [provider contract](../../tools/microsandbox-provider/README.md) describes
@@ -35,7 +34,7 @@ microsandbox; Docker and E2B retain their own supported lifecycle.
 Same-provider resource and Runtime edits currently require no active reset,
 the current generation and verified zero held allocations or pending Environments.
 A backend change requires explicit reset and confirmed cleanup, then a new setup.
-See the [reset procedure](../../HOSTED-SANDBOX-MANAGER.md#removal-and-reset).
+See the [reset procedure](../../../../docs/getting-started/nodes.md#change-the-sandbox-configuration).
 Stopped compute, snapshots and unknown operations remain blockers. Keep the original
 node identity, paths and credentials until cleanup is confirmed. Explicit archive
 preserves history and persisted Files/Artifacts but discards unpersisted workspace;
diff --git a/services/agents-api/runtime-history/README.md b/services/agents-api/runtime-history/README.md
deleted file mode 100644
index 709e34061..000000000
--- a/services/agents-api/runtime-history/README.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# Runtime history
-
-Core stores recent Runtime observations in its existing PostgreSQL database.
-No additional database or Collector is required. Apply Core migrations normally;
-the server enables 30-second periodic sampling when an execution worker is present.
-Only the execution lease owner samples, using the same provider-neutral current
-observation sources. Observation never changes Runtime lifecycle.
-
-History retains seven days and queries at most 24 hours. Writes use a bounded
-asynchronous queue; failures or overflow create gaps, never execution failures.
-CPU and memory unknowns remain null. CPU counter deltas never bridge compute
-restarts or counter resets. Providers without cumulative CPU time (E2B) store
-their reported utilization ratio, and a bucket holds the mean of those ratios. Token snapshots come from canonical Session Usage;
-the history table does not become billing or execution authority.
-
-Tenant, Session and Environment scope are mandatory on reads and writes. The
-schema stores sanitized measurements and Core identifiers, not credentials,
-provider receipts, native process identifiers, paths or raw provider errors.
-Nanosecond identity timestamps are lossless integers. Retention cleanup runs in
-bounded batches once per minute even when there are no active Runtimes. Queries
-exclude expired records before physical cleanup completes.
-
-## Optional configuration
-
-Set `OAC_HISTORY_SETTINGS_FILE` to an absolute server-only JSON file to change
-sampling or export to an existing OTLP receiver. Sampling-only example:
-
-```json
-{"sample_interval_seconds": 60}
-```
-
-Sampling accepts 5–300 seconds; omitted or zero selects 30. Queue capacity defaults
-to 256 (maximum 4096); write/export timeout defaults to two seconds (maximum 30).
-A server without an execution worker advertises on-read collection and does not
-claim periodic coverage. Retained queries remain available through Core.
-
-Optional external export:
-
-```json
-{
-  "transport": "otlp_http",
-  "endpoint": "https://collector.example.com/v1/metrics",
-  "headers": {"Authorization": "Bearer operator-secret"},
-  "sample_interval_seconds": 30,
-  "queue_capacity": 256,
-  "timeout_seconds": 2
-}
-```
-
-HTTP requires explicit `insecure: true`. Transport credentials stay server-only;
-the browser uses only Core. External export has a separate bounded queue, so its
-outage cannot starve local history. Do not commit this private configuration.
-
-Apply the standard `make check` gate with a dedicated PostgreSQL database. Real
-Runtime acceptance must include provider observations during real model execution,
-tenant isolation and retained history across Core restart; injected rows alone do
-not qualify provider sampling.
diff --git a/services/agents-api/tools/microsandbox-provider/README.md b/services/agents-api/tools/microsandbox-provider/README.md
index 0a090d0f7..27e544d82 100644
--- a/services/agents-api/tools/microsandbox-provider/README.md
+++ b/services/agents-api/tools/microsandbox-provider/README.md
@@ -23,9 +23,8 @@ container or native, is independent of the provider.
 PostgreSQL owns the provider, per-sandbox resources and immutable Runtime release.
 The node installs that specification and retains its generation and digest; local
 provider files cannot override it. See the
-[deployment contract](../../../../contracts/agents-api/sandbox-deployment.md),
-[nodes guide](../../../../docs/getting-started/nodes.md) and
-[nodes operator reference](../../HOSTED-SANDBOX-MANAGER.md). Core no longer accepts a
+[deployment contract](../../../../contracts/agents-api/sandbox-deployment.md)
+and [nodes guide](../../../../docs/getting-started/nodes.md). Core no longer accepts a
 file-managed startup selection or automatically adopts an older file-managed
 database.