Deployment / Data & Model Boundary
NexusClaw supports shared cloud, isolated cloud, government cloud, and flexible deployment paths. All use the same governance chain, while data, model, network, key, and operations boundaries 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, network zones, and inference location change.
Standard SaaS experience with tenant boundaries
For teams that want rapid launch, managed database and cache, and cloud model APIs. The application node needs no GPU.
Dedicated resource, network, and key boundaries
An independent runtime unit for teams with stronger network, resource, or data requirements. Isolation and operations ownership are agreed in the solution.
Customer environment
Dedicated public-sector trust path
A delivery checklist for residency, network zones, identity, audit, supply chain, and continuity; provider qualifications and controls are accepted per project.
Government cloud boundary
Managed, hybrid, private, and customer-side models
Choose a combination around data, model, network, and operations ownership; customer-side models can participate through a controlled path.
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.
