Connections

A connection is a saved, reusable set of coordinates for an external system Nexa reads from or publishes to — a database endpoint, a Kafka cluster, or an object-storage volume. You define connections once under Settings > Connection, then a connector references a connection by name to move data. Separating the two means one connection (for example, a production Postgres) can back many connectors.

What a connection stores

A connection is split into two halves so that credentials never sit in the platform database:

Half	Contents	Where it lives
Non-sensitive config	Host, port, database name, username, bootstrap servers, security protocol, region, volume path	Platform database (the Nexa app’s own store)
Secret	Password, SASL password/JAAS config, or service credential	Your GitHub repository secrets, under a derived name

When you create a connection, Nexa derives the GitHub secret name from the connection name using the convention CONN_<UPPER_SNAKE_CASE> — for example, a connection named prod orders db maps to CONN_PROD_ORDERS_DB. The Add New Setting panel shows this name live and reminds you to store your password under it in GitHub before you build a connector. Object-storage (file-system) connections have no secret because access is handled by the data platform’s grants.

Note

Nexa is customer-managed: DataReadyAI ships the images and IaC, but the customer’s platform team operates it. Because your secrets stay in your own GitHub repository and data platform, DataReadyAI never sees them.

Connection types

Each connection has a target system, which fixes the fields you fill in and the connectors that can use it.

Target system	UI label	Supported types
RDS	JDBC Connection	PostgreSQL, MySQL, Oracle, SQL Server, SQLite, DB2, MariaDB
Message Queue	Message Queue	Kafka, Kinesis, Event Hubs
File System	Storage	S3, ADLS, GCS

PostgreSQL / RDSHost, port, database, and credentials for a JDBC database.

Kafka / Message QueueBootstrap servers and SASL/SCRAM for streaming targets.

S3 & UC VolumesFile-system paths backed by Unity Catalog volumes.

Test reachability

Before you rely on a connection, Nexa can check that its host and port are reachable from the platform. The check opens a TCP connection to host:port (for Kafka and Event Hubs it uses the first broker in the bootstrap-server list, defaulting to port 9092) and reports whether the endpoint answers.

Reachability confirms only that the network path is open. Credentials are never verified at this stage — the password is validated at connector runtime, when the CI/CD pipeline has synced it into the data platform’s secret store. If reachability fails, check security-group/firewall rules and that the endpoint is routable from where Nexa runs.

From connection to running connector

1. Create the connection under Settings > Connection and store its secret in GitHub.
2. Create a connector that references the connection and selects tables to move.
3. On deploy, the secret-sync pipeline copies the GitHub secret into the data platform’s secret scope so the connector can authenticate.

Connectors overviewHow connectors use connections to publish data, and their lifecycle states.