Deployment Model

Nexa runs entirely inside your cloud account. DataReadyAI ships the software as container images and Infrastructure-as-Code (IaC); your platform team installs, configures, and operates it. This page explains what “customer-managed” means in practice — who owns what, what DataReadyAI can and cannot see, and which cloud/warehouse targets are supported.

The customer-managed model

DataReadyAI delivers three things and nothing that phones home with your data:

Artifact	What it is	You get it via
Container images	The Nexa services (nexa-web, nexa-backend, warehouse APIs, nexa-agents-api, workers)	Pulled into your registry (Amazon ECR or Azure ACR)
IaC	Terraform/Terragrunt for cloud infra (cluster, registry, DNS, Postgres, networking)	Git repositories you clone and apply
Kubernetes manifests	Kustomize bases + per-environment overlays, deployed by ArgoCD	Git repository ArgoCD syncs from

Everything runs on a Kubernetes cluster you own (Amazon EKS or Azure AKS). Nexa’s own metadata lives in a managed Postgres you provision. Your actual data stays in your warehouse (Snowflake or Databricks). DataReadyAI has no standing access to any of it.

Note

DataReadyAI supports the software but cannot log into your environment. When you open a support case, you (or a shared screen) run the diagnostics; DataReadyAI reads logs you provide. Plan for this — your team owns the “hands on keyboard.”

Responsibility split

Area	DataReadyAI	Your platform team
Application code & images	Builds, versions, publishes	Pulls into your registry, pins tags
IaC & manifests	Authors and maintains	Reviews, applies, and owns state
Cloud account & billing	—	Owns entirely
Cluster, networking, DNS, TLS	Provides IaC/manifests	Operates and secures
Secrets (DB, warehouse, GitHub)	Defines required keys	Creates and rotates in your secret store
Warehouse (Snowflake/Databricks)	Defines connection requirements	Owns the workspace and credentials
Upgrades	Publishes new versions + release notes	Chooses when to roll them out
Monitoring & backups	Recommends	Runs
Support	Advises, reads shared logs	Executes changes

What leaves your environment

Under normal operation, your data does not leave your cloud. The only outbound traffic is:

• Image pulls from your own registry (internal), and any base images/dependencies from public registries during build.
• Warehouse API calls to your own Snowflake or Databricks workspace (which you already run).
• Model/LLM calls for agent features — routed to the model endpoints you configure. These carry prompt/context, not bulk datasets.
• ACME (Let’s Encrypt) DNS-01 validation for TLS certificates, if you use the supplied cert-manager setup.

There is no telemetry channel back to DataReadyAI by default. See Reference architecture for the exact flows and Security & networking for controls.

Supported targets

You choose one cloud and one warehouse. The same Nexa images run in every combination; the IaC and warehouse API service differ.

Cloud

AWS

• Cluster: Amazon EKS (Kubernetes 1.34).
• Registry: Amazon ECR.
• Metadata DB: Amazon RDS for PostgreSQL 15.
• DNS: Amazon Route 53.
• Identity: EKS Pod Identity (pods assume scoped IAM roles; no static keys).
• Secrets: AWS Secrets Manager via the Secrets Store CSI driver.
• IaC: the aws-iac Terraform/Terragrunt repo (region ap-southeast-1 in the reference deployment).

Azure

• Cluster: Azure Kubernetes Service (AKS) (Kubernetes 1.34).
• Registry: Azure Container Registry (Premium SKU).
• Metadata DB: Azure Database for PostgreSQL Flexible Server 15.
• DNS: Azure DNS (a delegated az.nexa-drai.com-style subzone).
• Identity: AKS Workload Identity (OIDC-federated user-assigned managed identities).
• Secrets: Azure Key Vault via the Key Vault Secrets Provider CSI driver.
• IaC: the nexa-azure-app-iac Terraform/Terragrunt repo (region australiaeast in the reference deployment).

Warehouse

Databricks

Nexa connects to a Databricks workspace and drives Unity Catalog, SQL warehouses, jobs, and pipelines. The warehouse-facing service is nexa-databricks-api (FastAPI) plus its background worker. Nexa authenticates with a Databricks service principal (client ID/secret) scoped to a catalog you designate.

Snowflake

Nexa connects to a Snowflake account and drives databases, schemas, warehouses, and tasks. The warehouse-facing service is nexa-snowflake-api (FastAPI). Nexa authenticates with a Snowflake service account/role scoped to the databases you designate.

Caution

Mixing is not supported in a single environment: one Nexa environment targets one cloud and one warehouse. To run both Snowflake and Databricks, or both AWS and Azure, stand up separate environments.

Environments

The reference IaC and manifests model multiple environments (for example dev, test, prod) as Terragrunt *.tfvars files and Kustomize overlays, each with its own namespace prefix, image tags, and sizing. Promote images between environments by advancing tags (branch/commit tags in lower environments, semantic versions such as v1.0.0 in production).

Continue to Reference architecture for the full component and network picture, or jump to Prerequisites to start preparing.