Secret Sync
Nexa never stores connection passwords in its own database. Instead, secrets live in your GitHub repository secrets and are copied into the data platform’s secret store by the CI/CD pipeline when a connector deploys. This page explains that flow and the GitHub integration it depends on. It matters because a connector cannot authenticate until its secret has been synced.
Why secrets live in GitHub
Section titled “Why secrets live in GitHub”When you create a connection, Nexa stores only its non-sensitive config (host, port, database, bootstrap servers, and so on). The password, SASL credential, or service credential goes into a GitHub repository secret named CONN_<UPPER_SNAKE_CASE>, derived from the connection name. Keeping secrets in your own repository means DataReadyAI, which operates the customer-managed platform without access to your environment, never handles them.
The sync flow
Section titled “The sync flow”-
Store the secret. Create the GitHub repository secret under the derived name (Settings > Secrets and variables > Actions). See the per-type instructions on the PostgreSQL, Kafka, and connection pages.
-
Create and deploy a connector that references the connection. See Creating a connector.
-
Codegen emits a
connection.yml. When the connector is generated, Nexa produces aconnection.ymldescribing which connection (and therefore whichCONN_*secret) the connector needs. -
CI/CD syncs the secret. On deploy, the pipeline reads
connection.yml, pulls the matching GitHub secret, and writes it into the data platform’s secret store — where the connector’s job reads it at runtime.
Where the secret lands
Section titled “Where the secret lands”On Databricks, the pipeline writes the value into a Databricks secret scope. The connector’s job references it there, so the password is resolved at runtime and never appears in code or config. File-system (Storage) connections have no secret to sync — access is governed by Unity Catalog grants on the volume.
On Snowflake, the pipeline provisions the credential into the platform’s managed secret store and the connector’s task reads it at runtime. As on Databricks, object-storage access is governed by the platform’s grants rather than a synced secret.
GitHub integration
Section titled “GitHub integration”The sync relies on Nexa being connected to your repository, configured under Settings > GitHub. The integration authenticates with a GitHub App rather than a personal token. The tab shows and tests:
| Field | Purpose |
|---|---|
| Repository | The repo holding the secrets and generated code (owner/name). |
| Branch | The branch the pipeline targets. |
| GitHub App ID | The App used for authentication. |
| Installation ID | The App installation on your repository. |
Use Test Connection to confirm the App is installed and the repository is reachable before relying on secret sync. A connected, configured state is required for deploys to pick up secrets.