Choose the sandbox backend at install time so Add node is ready after install

CONTRIBUTING.md

@@ -831,9 +831,9 @@ initial node configuration reads and registration; durable node credentials auth
 retained configuration reads and node transport. Project keys cannot read nodes,
 placement or allocations.
 
-One execution owner manages local and remote nodes through the same finite
-Provider protocol. Local opt-in uses the same standalone node installer and
-service as a remote host, with a guest-reachable, non-loopback HTTPS origin.
+One execution owner manages every node through the same finite Provider protocol.
+The Core host joins through the same standalone node installer and service as any
+other host; every node needs a guest-reachable, non-loopback HTTPS origin.
 All managed nodes actively connect over authenticated TLS. Persist private node
 identity and highest owner epoch; refuse another process using the same identity
 or a changed backend namespace. Reserve each NodeID before transport upgrade and
@@ -1730,7 +1730,7 @@ environment and has no config loader; it serves the non-secret snapshot at
 (`config_model.py`), the generator and the generated reference table in
 `docs/configuration.md` (`scripts/config-reference.py`) in step. Do not add a
 second operator configuration file, loader precedence, hot reload, compatibility
-reading of retired names, or an embedded Core node. Explicit local-node flags call
+reading of retired names, or an embedded Core node. `install.sh --sandbox` calls
 the ordinary administrator API once; PostgreSQL owns the resulting selection.
 Administrator-issued enrollment approves capacity (default two active/eight
 retained); a node cannot supply or overwrite those limits. Downloaded specification
@@ -1835,14 +1835,15 @@ The first installer targets a trusted Linux amd64 Docker host. It installs a
 private dedicated PostgreSQL service and separate Core and console services in
 Compose by default, with zero execution nodes. The default requires neither KVM
 nor systemd user services, imports no Runtime image, mounts neither the Docker
-socket nor host devices into Core, and generates no managed Provider configuration.
-Local sandbox placement is opt-in: `--sandbox-provider true --provider microsandbox`
-or `--sandbox-provider true --provider docker`. Enabling the option without naming
-a provider selects microsandbox; `--provider` without enabling the option is an
-error. Local opt-in requires a non-loopback HTTPS `--public-url` reachable from
-sandbox guests. Web-only mode cannot enable a sandbox provider. Core-only mode retains the
-same opt-in rule. Missing KVM fails when microsandbox is selected without changing
-that choice.
+socket nor host devices into Core, and never adds its own host as a node.
+`--sandbox docker|microsandbox|e2b|none` (default `docker`; `none` and nothing else
+with `--web-only`) is a one-time install action: once the services are healthy, the
+installer POSTs `/core/v1/sandbox/deployment` as Web's setup would, and never on a
+repair or conversion. It is not written to `config.json`; PostgreSQL owns the
+selection. E2B needs a non-loopback HTTPS `public_url`, `--e2b-api-key-file` and
+`--e2b-template`, and is refused before anything is installed. A loopback Docker or
+microsandbox selection is saved, but no node can serve it until `public_url` is
+guest-reachable HTTPS. `--sandbox-provider` and `--provider` are retired and fail.
 The thin distribution supplies native Core binaries. Provider helpers, the node
 agent, Runtime launcher and pinned msb runtime/firmware are separate, same-revision
 assets. Nodes obtain them only from the console's payload, so a console serves
@@ -1866,21 +1867,21 @@ The basic API image and binary builds remain independent artifacts.
 The standalone API release and Core distribution both include the Hosted Sandbox
 Manager guide at the relative path used by their packaged README. Include the
 guide in each artifact checksum list so extracted documentation matches its build.
-The node asset includes the sandbox-node binary. Local opt-in initializes an empty
-deployment through the same administrator API, then invokes the ordinary node
-installer. Its initial size matches Web's setup proposal: 2 CPUs with 2048 MiB for
-Docker, or 4096 MiB and 8192 MiB for each disk for microsandbox. An existing
-database selection is never overwritten by installer defaults. Node configuration and identity live under
+The node asset includes the sandbox-node binary. The installer's Docker and
+microsandbox selections use Web's Standard size from
+`apps/web/src/features/sandbox/standard-sizes.json`, which the distribution build
+copies into the bundle; keep no second copy of those values. An existing database
+selection is never overwritten by installer defaults. Node configuration and identity live under
 `~/.parsar/nodes/<installation-id>/`; microsandbox uses its separate short private
 Runtime home. Zero-node installs create no node identity state but retain the paired
 Core key for first setup.
 
 One Runtime image contains the existing daemon, shared helpers and three native
 harness packages. Their differences remain in the adapters. Core keeps exclusive
 ownership of Session allocation, initialization, cancellation, snapshots and
-cleanup. When a sandbox provider is enabled, the installer imports its Runtime
-image and prepares running conditions; it never creates an execution Session or
-supplies a model credential. Applications use the
+cleanup. The node installer imports the Runtime image and prepares running
+conditions; neither installer creates an execution Session or supplies a model
+credential. Applications use the
 existing write-only model execution extension, with the installation's persistent
 credential encryption key. Provider identity/backend namespace and native history
 must not change on a repeated install.

README.md

@@ -12,9 +12,8 @@ Parsar product.
 Core and its administrator Web console ship together. Projects own assets; multiple
 API keys in one Project share its assets and execution principal. Projects and API
 keys live in the database. Management credentials cannot call the Agent API. The
-default installation runs Core, Web
-and PostgreSQL with zero execution nodes. Add execution nodes through Web when
-you are ready. Core creates each required sandbox from the shared Runtime image. Model
+default installation runs Core, Web and PostgreSQL and selects Docker sandboxes,
+with zero execution nodes. Add execution nodes through Web when you are ready. Core creates each required sandbox from the shared Runtime image. Model
 credentials are supplied through the existing write-only API extension.
 
 Hosted deployments select E2B cloud or one provider across their own local/remote
@@ -32,7 +31,9 @@ retain their node across disconnects and resume.
    ./install.sh --public-url https://core.example
    ```
 
-   This starts Core, Web and PostgreSQL with zero execution nodes. Release
+   This starts Core, Web and PostgreSQL and selects Docker sandboxes at Web's
+   Standard size, with zero execution nodes; `--sandbox` chooses microsandbox, E2B
+   or none instead. The installer never adds this host as a node. Release
    bundles are tied to a source revision; an older published bundle does not include
    current management changes. See the [installation guide](docs/getting-started/install.md)
    for obtaining/building a matching bundle and the host/network prerequisites.
@@ -43,14 +44,14 @@ retain their node across disconnects and resume.
    issue a key within it for your application. Save the one-time plaintext
    response privately; Core stores its digest. Rotate by issuing another key in the
    same Project and revoking the old one.
-3. **Add a node.** Open **Nodes** and choose E2B cloud or your own machines with
-   Docker/microsandbox. E2B needs its account credentials and qualified Runtime
-   template, with no node installation; your own machines also need a sandbox size.
-   Either way, finish setup with **Save configuration**. The paired console address
-   is used by default; advanced network settings allow a different reachable HTTPS
-   origin. For your own machines, then select **Add node**, and copy and run the
-   command on a prepared Linux host. Web shows when the node is online and its
-   provider is ready. All nodes in a deployment use the same provider.
+3. **Add a node.** Open **Nodes**, select **Add node**, and copy and run the
+   command on a prepared Linux host, this one included. Web shows when the node is
+   online and its provider is ready. All nodes in a deployment use the same
+   provider. Nodes need the HTTPS public URL: a loopback installation keeps its
+   sandbox selection but can't add nodes until `public_url` is set. After
+   `--sandbox none`, **Nodes** first asks for E2B cloud (its account key and a ready
+   template build, with no node installation) or your own machines with
+   Docker/microsandbox and a sandbox size; finish with **Save configuration**.
 
 Installation and node enrollment do not call a model. Once a node is ready,
 run an optional API example with your own model credentials.
@@ -71,14 +72,17 @@ local console/API access. For node enrollment, use the reachable origin describe
 above. Flags only seed the installation's `config.json`; later changes go there
 and take effect with `~/.parsar/core/parsar apply`, and `parsar status`, `start`
 and `stop` replace `install.sh --status` and `--stop`.
-Installing a local provider is optional, needs that HTTPS `--public-url`, and is not
-required for adding nodes in Web.
+`--sandbox` is a one-time choice of the sandbox backend, saved in the database like
+Web's setup; change it later in Web. `--sandbox-provider` and `--provider` are
+retired: the installer no longer adds its own host as a node.
 
 ```sh
-./install.sh                    # Core + Web + PostgreSQL, loopback access, zero nodes
-./install.sh --core-only        # Core + PostgreSQL, zero nodes
-./install.sh --sandbox-provider true --provider microsandbox --public-url https://core.example
-./install.sh --sandbox-provider true --provider docker --public-url https://core.example
+./install.sh                    # Core + Web + PostgreSQL, loopback access, Docker sandboxes, zero nodes
+./install.sh --core-only        # Core + PostgreSQL, Docker sandboxes, zero nodes
+./install.sh --sandbox microsandbox --public-url https://core.example
+./install.sh --sandbox e2b --e2b-api-key-file "$HOME/e2b-api-key" \
+  --e2b-template '<template-id>:<build-uuid>' --public-url https://core.example
+./install.sh --sandbox none     # choose the sandbox backend in Web later
 ```
 
 Web-only installation connects the console server to an existing Core; see the

deploy/install/convert.py

@@ -386,7 +386,7 @@ def preflight(root, bundle_manifest, images, public_url_override, run):
         "source_commit": bundle_manifest["source_commit"], "images": images,
         "secrets_sha256": {Path(target).name: configuration.sha256((root / source).read_bytes())
                            for source, target in plan.moves if target != "secrets/core.key"},
-        "core_installation_id": None, "generated": {}, "local_node": None,
+        "core_installation_id": None, "generated": {},
         "converted_from": {"source_commit": old["source_commit"],
                            "at": datetime.datetime.now(datetime.timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ"),
                            "remove": [name for name in plan.deletions if name.startswith(("config/", "state/"))]}}