The platform installs inside your own cloud account.

Nexa Intelligence runs as a set of workers, queues, object stores, and Durable Objects inside infrastructure you own. Cloudflare is the default substrate because the entire platform is Cloudflare-native. AWS, Azure, and on-premise follow the same model on a different vendor. Your IT team installs the Cloud Harness. We operate inside it. Data never leaves your perimeter to be processed.

This page covers what gets installed, who runs what, what crosses your perimeter, and how the deployment differs per vendor.

The Cloud Harness is the package of infrastructure that becomes your deployment. On Cloudflare it is seven workers, two R2 buckets, several Durable Object classes, and a small set of queues. On AWS it is the same topology mapped onto Lambda, S3, DynamoDB, and SQS. On Azure it is Functions, Blob Storage, Cosmos DB, and Service Bus. On-premise it is the same topology on Kubernetes with Postgres, MinIO, and NATS.

Your team provisions the account. We provide the deployment scripts, the Wrangler or Terraform configuration, and the installation runbook. Once the Harness is up, your account holds every piece of infrastructure the platform touches. There is no separate Nexa-controlled environment that your data passes through.

We operate the Harness under a signed contract. Your IT keeps the keys. We get the access we need to run enrichment, dashboards, and agent surfaces, scoped to the environments we operate.

Two services live outside your account: the LLM provider (Anthropic) and the voice provider (ElevenLabs). Every other piece of the system runs inside your account, including the datalake, the enrichment workers, the fact store, the dashboards, and the agent endpoints.

The Anthropic call is bound by a no-training contract on every plan. Enterprise additionally runs no-retention: no customer content persists at Anthropic beyond the request. ElevenLabs runs no-retention on every plan and every tier. The original audio leaves no trace at the voice provider after the call ends. See the subprocessor list for the exact data each partner sees.

Inbound calls are auth-gated at the edge. Webhooks carry an HMAC signature that is verified against a secret stored in your account. Operator surfaces carry a bearer token whose scope is encoded in the credential. There is no shared secret between Nexa and your account beyond the credentials your IT issues us.

Cloudflare is the default substrate because the platform is Cloudflare-native. The Harness deploys as seven workers (operations, canvas, ingestion, engine, query, r2ops, docs), two R2 buckets (the datalake and the matrix artifact store), and a set of Durable Object classes that hold per-matrix state. Queues carry asynchronous work between the ingestion worker and the enrichment engine.

Every wrangler.toml sets workers_dev = false so the *.workers.dev URLs return 404. Only the custom domains in your account serve traffic. The engine worker has no public surface at all. It is reached through queue consumers and service bindings from other workers in your account. There is no inbound path from the internet to the LLM-calling worker.

Cloudflare-native means regional pinning is a configuration change rather than a re-architecture. R2 buckets can be pinned to eu or fedramp jurisdictions through the bucket binding. Durable Objects accept location hints that place them in a specified region. See section 06 for the data residency configuration.

The AWS deployment maps the Harness topology onto the equivalent AWS primitives. Workers become Lambda functions. R2 buckets become S3 buckets with bucket-policy isolation between the datalake and the matrix artifact store. Durable Objects become DynamoDB tables with row-level scope keys. Queues become SQS, with EventBridge handling fan-out.

Secrets live in AWS Secrets Manager, scoped per function. KMS keys are issued per environment. The IAM policy on each Lambda restricts it to the buckets, tables, and queues it actually needs. The Lambda that calls Anthropic cannot write to the datalake. The Lambda that ingests webhooks cannot overwrite matrix artifacts. The same separation of credentials that holds on Cloudflare holds on AWS.

We provide the Terraform module. Your IT runs the apply. Account ownership, billing, and the IAM root sit with you.

The Azure deployment uses Azure Functions for the worker tier, Blob Storage for the datalake and matrix artifact store, Cosmos DB for the per-matrix state tables, and Service Bus for the queue layer. Key Vault holds the secrets. Managed identities scope each Function's access to the resources it operates against.

Azure deployments are common in regulated verticals. The Harness ships with the Azure Policy templates needed for Loi 25 Quebec and GDPR-residency configurations. Resource groups can be pinned to a region, and Cosmos DB accounts can be locked to a single region with no cross-region replication.

On-premise customers run the Harness on Kubernetes. Workers become container deployments. Storage becomes MinIO with the same two-bucket separation as the cloud variants. Per-matrix state becomes a Postgres schema with row-level security keyed on the matrix identifier. Queues become NATS JetStream.

On-premise is the configuration for customers with explicit data residency requirements that no public cloud can meet, or who already operate a private Kubernetes platform their security team has audited. The same partner calls apply: outbound HTTPS to Anthropic and ElevenLabs under the same no-training and no-retention contracts. If those calls are also forbidden by policy, the deployment runs in air-gapped mode with on-premise inference and on-premise voice synthesis. The trade-off is the quality of the interview agent and the cost per conversation.

Storage and compute can be pinned to a jurisdiction at deployment time. On Cloudflare this is the R2 bucket jurisdiction flag plus Durable Object location hints. On AWS this is the region of the S3 bucket and the Lambda function. On Azure this is the resource group region. On premise this is the physical location of the cluster.

For customers with EU residency requirements, every piece of infrastructure can be pinned to EU regions. For customers in the Canadian public sector or in Quebec under Loi 25, the Canadian regions of each vendor are available. The deployment runbook lists the exact region IDs we use per jurisdiction.

Inside your account, Nexa operates the Harness. That means we deploy releases, run incident response, watch observability, tune the enrichment pipeline against your corpus, calibrate the per-dimension half-lives, and ship patches. We do not export your data. We do not run training against it. The data path stays inside the perimeter you own.

The operating boundary is named in the contract. Your IT controls the keys, the billing, and the root credentials. Our access is scoped to the operational surfaces we need. Audit logs of operator actions sit in your account, where your security team reviews them.

If you end the vendor relationship, the deployment keeps running on your account without us. See Data Independence for the continuity guarantee.