Deployment / Data & Model Boundary
NexusClaw supports managed SaaS, hybrid, and private deployment. All three run the same governance chain, but business data location, model inference, and infrastructure ownership differ.
Choose the boundary before sizing. Every resource figure on this page belongs only to its named topology—build memory, model VRAM, and another deployment shape are not interchangeable.
01 / Topology Choice
Governance, audit, and Agent runtime remain consistent. Infrastructure ownership, data residency, and inference location change.
Platform-managed application with cloud models
For teams that want rapid launch, managed database and cache, and cloud model APIs. The application node needs no GPU.
Cloud business system + customer AI PC
Enterprise applications and governance stay in the cloud while local inference runs on a customer AI PC through a customer-initiated tunnel.
Application, data, and optional local model in customer environment
For customer-owned network and infrastructure boundaries. Sizing depends on data, concurrency, and the selected local model.
Customer environment
02 / Data & Model Boundary
The cloud node runs Web, API, mobile, data services, and tunnel service. The AI PC carries the local model and GPU. The customer side initiates the tunnel, so the AI PC need not be publicly exposed.
Cloud business & governance plane
LOCAL_MOE_ENABLED = false
Customer AI PC model plane
Customer-initiated · no public AI PC exposure
Resides in cloud data services or the customer environment by project contract; model context remains permissioned and audited.
Local model files and GPU remain on the customer AI PC and are not copied to the cloud application node.
Health and timeouts must be monitored. Any provider failover follows explicit routing policy—not a silent promise.
03 / Release & Operations
Production release starts with an exact commit and immutable image, then database migration, same-version service cutover, strict health checks, and permission smoke tests. Failures roll back at behavior, code, or data level.
Record commit SHA, image digest, and configuration version.
Bind migration to the application version and preserve results.
Backend, Web, and Mobile use the same version.
Strict health, permission, and critical-record smoke checks pass.
Feature flags, prior images, and database recovery paths stay explicit.
04 / Sizing & Responsibility
These are starting points for controlled trials and verified shapes, not topology-free promises. Formal projects validate capacity after the shape is selected.
4 vCPU / 8 GiB app ECS
Managed database, cache, and object storage; cloud inference; starting point for ≤20 invited users and 3–5 concurrent AI tasks.
8 vCPU / 16 GiB app ECS
More headroom for pre-production operation, still using managed data services and cloud models.
About 3–4 GiB total
Backend about 1.5–2 GiB; no local model in cloud. The AI PC carries model memory and GPU.
Size by model and concurrency
Application, database, and local model may share a host; hybrid cloud-node figures do not apply.
Confirm the actual location of business data, logs, model weights, and secrets.
Disconnect model endpoint or cache and verify health, alerts, and recovery.
Migrate, cut over, smoke test, and return to a prior version.
Return from one Agent outcome to execution, tools, approval, and owner evidence.
A deployment shape is not a compliance certification and does not define your data-residency policy. Hardware, cloud resources, model licenses, network conditions, and backup ownership belong in project scope; private sizing is accepted against the chosen model, data volume, and concurrency.
We will lock the topology first, map data and model boundaries, then provide topology-specific sizing, go-live evidence, and rollback acceptance.
