Optional deployment, after local verification

01 · Verify the installed CLI

The reviewed published/installed @2server/cli version is 0.2.16. Its package README and source help define the examples below. Check your own installation before using them; other releases may differ. Requires Bun ≥ 1.3 and Node ≥ 20; provisioning also requires Terraform, and GCP IAP requires gcloud.

# Install only with the operator's reviewed permission.
npm install -g @2server/[email protected]
npm list -g @2server/cli --depth=0
2srv help
2srv help legacy

2srv is preferred; 2server is the compatibility alias. Installed 0.2.16 supports init server|app|extension|service NAME -o FILE. These generate authored starting files, not an installed Soot system. See the 2server README and operator guide; review the installed version's contract if upstream changes.

02 · Existing managed VM or fresh VM?

Existing VM already managed by 2server: confirm its published state, owner, access, capacity, network and current service lifecycle. From the owning project, connect using reviewed SSH input. Host/user are placeholders; the private key path is a reference, not key material.

2srv connect --ssh user@host --identity /absolute/private/ssh-key

Connect contacts the VM and saves private ignored connection metadata; it is not an offline check. For GCP IAP/structured SSH, use --connection FILE as documented. Do not bootstrap a managed VM or use new-VM Terraform roots to take it over.

Fresh VM: prepare account/project, billing, provider login and permissions before planning. Review region, VM/CPU/memory, disk, public address, SSH/IAP access, restricted ingress and recurring charges. Costs for VM/storage/network and model usage are separate; use the provider's current estimate, not guessed cloud prices.

• 2server provisioning — GCP/AWS inputs and private Terraform state ownership.
• GCP project and billing and local authentication.
• AWS account setup and CLI authentication.

For GCP, review project/region/zone/machine/disk and API, compute, IAM, OS Login and IAP permissions. For AWS, review region, verified Debian/Ubuntu amd64 AMI, SSH public-key reference and restricted SSH CIDRs. Follow the provisioning guide to plan with a reviewed absolute private tfvars path. Stop for operator review before provider apply. Do not recreate resources because a response was lost.

After a fresh VM exists—or for an existing but unmanaged compatible VM—prepare an empty server manifest. Supported prerequisites are Debian 12/13 or Ubuntu 22.04/24.04, Python 3, trusted key-based SSH, passwordless sudo and root registry pull access.

2srv init server my-server -o server.local.json
# Edit/review SSH or GCP IAP settings; keep this file private and ignored.
2srv server bootstrap -f server.local.json
# Only after reviewing the target and explicit infrastructure approval:
2srv server bootstrap -f server.local.json --apply

Bootstrap installs Docker/Caddy, publishes initial VM control state and saves the connection. It requires an empty manifest and no published 2server state. The no-apply form is offline intent, not a live access check. This guide does not provision or bootstrap a VM for you; staying local is a valid choice.

03 · Review the Soot Service inputs

This route uses an authored custom `kind: Service`, not a turnkey admitted Soot closure. It is a deliberate compatibility path, not native C1/C3 admission; the compiled Data Pool runner is outside that admitted closure. Do not bypass validators or fabricate admission receipts. Installed 0.2.16 accepts legacy Service while recommending App templates for reusable extensions. A stateful Service does not inherit App blue/green traffic rollback.

2srv init service soot-runtime -o soot-service.yaml

The generated Service is only a starting point. Before validate/plan, review these inputs:

--image is App-only; declare the digest in your reviewed Service spec. Image replacement must not seed over existing writable config or durable state. One runtime process owns a conversation store. Search data needs separate persistence/backup.

2srv validate -f soot-service.yaml
2srv plan -f soot-service.yaml
# Only after operator review and explicit infrastructure permission:
2srv deploy -f soot-service.yaml --apply

validate is offline. plan contacts the VM/registry and may pull image layers, so it needs appropriate permission. A plan is not approval; apply recomputes against current state.

04 · Keep the two browser trust boundaries clear

A product backend authenticates users, selects allowed Soots and keeps its trusted runtime/client key server-side. Never embed that key in the public product frontend or bundle. End-user browsers cannot assert trusted runtime identity. See product integration.

Nest is different: the operator browser uses its operator key in page memory only, with reauthentication after refresh. Native Nest uses its private connection store. Direct browser Nest needs trusted TLS and an exact allowed origin, or a fixed loopback same-origin proxy that forwards the caller's authorization without injecting a master key. Provider vaults, operator keys and Data Pool UI/agent credentials have separate scopes.

05 · Verify the deployed work, not just health

1. Readiness and dependency health through the supported lifecycle.
2. A real-model Test at the acknowledged active revision, with correct source citations.
3. Permitted read, denied pool write and denied Support read with all other layers configured.
4. Protected unauthenticated requests return 401, not just a public health response.
5. Conversation/config/Data Pool state survives a controlled replacement.
6. Reviewed state backup/restore, private credential lifecycle and recovery plan.

A healthy container does not prove a provider call; a restart does not prove persistence. Record what each check observed and what remains unverified.

06 · Backups and uncertain outcomes

Back up state separately from source/images. Conversation storage needs a stopped owner or supported database snapshot, not arbitrary live copying. Search data and private secrets need separate recovery.

If apply/replacement loses its response, inspect the original receipt and actual resource state before retry. Image rollback does not undo data writes or external actions.