Cross-Repo Map

Nexa spans many repositories. This page maps ownership and the wiring between them so you can trace any request or artifact to the repo that owns it. For the running topology see Platform Architecture; for a grouped inventory of every repo see the repository catalog.

The connective tissue is three things: the HTTP call chain (web → backend → FastAPI services), the shared Postgres schemas, and Git (the control-plane APIs write artifacts that CI deploys to the data platform).

The call chain

The frontend calls only the backend; the backend proxies to the FastAPI services using per-target env-var URLs. Nothing else talks directly to a FastAPI service.

From	To	Wiring (env var)	Path / notes
`nexa-web`	`nexa-backend`	`VITE_API_URL`	all UI calls go to `/api/*`
`nexa-backend`	`nexa-databricks-api`	`NEXA_DATABRICKS_API_URL`	proxy `POST /api/fast-api`; ingress `/platform`
`nexa-backend`	`nexa-snowflake-api`	`SNOWFLAKE_API_URL`	proxy `POST /api/snowflake-api`
`nexa-backend`	`nexa-agents-api`	`AGENT_API_HOST`	ingress `/agentapi`
`nexa-backend`	`actg-ai`	`ACTG_AI_URL`	ingress `/llm`; async webhook back to backend
`actg-ai`	`nexa-backend`	`RAW_TO_TDM_WEBHOOK_URL`	in-cluster call to `/api/schema-master/raw-to-tdm-mapping-webhook`

Each backend→FastAPI hop mints a short-lived service token against the target’s /api/v1/auth/token using NEXA_CLIENT_ID/NEXA_CLIENT_SECRET (agents-api can also use a static NEXA_SERVICE_AUTH_TOKEN).

Repository ownership

Repository	Language / stack	Owns	Connects to
`nexa-web`	React 18 + Vite (JS)	The entire UI; no database	`nexa-backend` via `/api/*`
`nexa-backend`	Node/TS, Express 4, Sequelize	API gateway + all web-domain data (Postgres `web`)	all FastAPI services; GitHub App; Postgres RDS
`nexa-databricks-api`	FastAPI (Poetry), `databricks-sdk`	Databricks control/data plane (catalog, pipelines, jobs, codegen)	Databricks workspace/Unity Catalog; Postgres `platform`
`nexa-snowflake-api`	FastAPI (uv), `snowflake-connector`	Snowflake control/data plane (twin of the above)	Snowflake account; Postgres `sf_platform`
`nexa-agents-api`	FastAPI (Poetry), Delta	Agent & automation lifecycle (Databricks) — materializes to Git	`nexa-databricks-agents`, `nexa-workflow-automations` repos; Delta; Postgres `agents`
`nexa-snowflake-agents-api`	FastAPI (uv), Snowpark/Cortex	Agent & automation lifecycle (Snowflake twin)	`nexa-snowflake-agents`, `nexa-snowflake-automations` repos; Snowflake; Postgres `agents`
`actg-ai`	FastAPI + worker (pip)	Raw→Curated→TDM mapping, conflict resolution, tagger/mapper	Databricks Vector Search + model serving; Postgres `llm`
`nexa-workflow-automations`	Python, Databricks Asset Bundle	Automation runtime on Databricks (jobs/notebooks)	Deployed by CI from Git; writes to Delta
`nexa-snowflake-automations`	Python, hatchling	Automation runtime on Snowflake (Tasks + stored procs)	Deployed by CI from Git; writes to Snowflake
`nexa-deployments`	Kustomize + ArgoCD	GitOps source of truth for all k8s manifests	Watched by ArgoCD; pulls images from ECR
`aws-iac`	Terraform/Terragrunt	AWS platform infra (EKS, RDS, ECR, IAM)	Provisions the AWS runtime
`nexa-azure-app-iac`	Terraform/Terragrunt	Azure platform infra (AKS, ACR, Postgres, Databricks workspace)	Provisions the Azure runtime
`nexa-azure-databricks-iac`	Terraform (databricks provider)	Unity Catalog governance on the Azure Databricks workspace	Applied after the workspace exists
`drai-customer-databricks-iac`	Terraform (databricks provider)	Full AWS Databricks E2/MWS workspace + UC (SRA-based)	Peers with the app VPC

The three variant pairs

The Databricks and Snowflake stacks are parallel implementations that share route/module shape and contracts. There are three pairs, and nexa-web + nexa-backend sit above both (the backend swaps which FastAPI URL each proxy targets):

Concern	Databricks variant	Snowflake variant
Platform data/control API	`nexa-databricks-api` (`/platform`)	`nexa-snowflake-api`
Agent/automation control plane	`nexa-agents-api` (`/agentapi`)	`nexa-snowflake-agents-api`
Automation runtime plane	`nexa-workflow-automations` (Asset Bundle)	`nexa-snowflake-automations` (Tasks + procs)

Shared Postgres schemas

One RDS Postgres database (nexa-db) backs the whole platform, partitioned by schema so each service owns its own tables:

Schema	Owner repo	Env var
`web`	`nexa-backend`	`PG_SCHEMA_WEB`
`platform` / `sf_platform`	platform APIs	`PG_SCHEMA_PLATFORM`
`agents`	agents APIs	`PG_SCHEMA_AGENTS`
`llm`	`actg-ai`	`PG_SCHEMA_LLM`

Analytical data never lands in Postgres — it stays in Unity Catalog/Delta (Databricks) or Snowflake.

Git as an integration point

The control-plane APIs integrate with the runtime planes through GitHub, not HTTP. nexa-agents-api writes agent artifacts to dataready-ai/nexa-databricks-agents and automation artifacts to dataready-ai/nexa-workflow-automations; CI in those repos deploys the bundle/tasks to the data platform. The image CI also dispatches release events to drai-customer-releases and nexa-aws-sf-deployments. See CI/CD and GitOps & Deployments for the mechanics.