Connections

A connection is how Data Sync reaches one system. You create it once, and every sync that needs that database, warehouse or bucket points at the same connection — so a host change or a credential rotation happens in one place rather than in every sync that touches it.

What a connection is

A connection is a named, reusable, environment-scoped configuration of exactly one connector. It holds the addressing details for a system — host, port, database, project, dataset — plus a reference to a credential.

That last part is the important one. A connection never stores a secret value in its own configuration. It stores which credential provider to ask and which identifier to ask for, and the runner resolves that reference at run time. This is what lets you hand a connection to a teammate who has viewer access without also handing them the password.

Connections are reused across many syncs. One prod Postgres connection can be the source of a dozen syncs writing to different sinks, and the same connection object is what each of them resolves. A connection is not tied to a sync and does not have a state machine of its own; it is configuration.

The Connections page is the workspace inventory. For each connection it shows the role, which decides where the connection may be used, and whether its secret is held by Blunox or lives in your own store.

The four steps

Adding a connection is a four-step wizard: 1 Connector → 2 Configure → 3 Credentials → 4 Test & save. You can move backwards at any point without losing what you have entered.

1  Connector

The first step is the catalog — every connector Data Sync ships, with a search box and an All / Source / Sink / Both filter. Search matches the connector name, so typing post narrows to PostgreSQL immediately.

The catalog is grouped by category: Databases, Warehouses, Lakes & storage, Streaming & events and Utility. The grouping is presentational; the filter is not. Filtering by Source hides connectors that can only act as sinks, which is the fastest way to answer "can I replicate out of this system?"

A connector’s role badges are declared by the connector itself, not by your configuration, so they are the ground truth for where the resulting connection can be used.

Role badges matter more than they look. A connector marked Source only — SQL Server and Elasticsearch, for example — can never be selected as a sink, no matter how it is configured. A connector marked Sink only, like BigQuery, is the mirror image. Choosing the wrong one here is the most common reason a connection later fails to appear in the picker you expected.

2  Configure

Step two asks for a connection name, then the fields specific to the connector you picked.

The connector-specific fields are the ones documented on each connector page — host, port, database and sslmode for PostgreSQL; project_id and dataset_id for BigQuery; hosts or cloud_id for Elasticsearch. Required fields are marked; the rest carry defaults that are correct for most installations.

Below the required fields is an Advanced settings section, collapsed by default, holding the tuning options for that connector — timeouts, heartbeats, reconnect limits, batch ceilings. Leave them alone until you have a measured reason to change them. The defaults are what Data Sync is tested against.

3  Credentials

This step decides who holds the secret. There are two models, and the choice is per connection.

Choose the provider first; the fields that follow change to match it.

Blunox-managed

You type the secret into the console and Blunox stores it. It is encrypted at rest with a per-record AES-256-GCM data key, and that data key is itself wrapped by a per-workspace key held in KMS. The wrapping binds the ciphertext to its workspace and to the specific resource it belongs to, so a ciphertext lifted out of one workspace cannot be decrypted in another.

Deleting a workspace revokes its key, which permanently renders every ciphertext under it unreadable — cryptoshredding, rather than a best-effort row delete. Every access to a managed credential is written to the audit log.

This is the right default. It is one field, there is no external system to keep available, and the security properties are strong enough for production.

Bring your own secret store

Instead of a value, you give a typed reference into a store you already run: HashiCorp Vault, AWS Secrets Manager or GCP Secret Manager. You pick the provider and supply the identifier it expects — a Vault path, a Secrets Manager ARN or name, a Secret Manager resource name.

The form checks the shape of the reference, not the secret behind it. Data Sync cannot tell you whether the path resolves until a runner tries.

Choosing between them. The question is not which is more secure in the abstract — both are. It is who you want to be responsible for the secret's lifecycle.

You can mix models freely across a workspace — a Vault-backed prod connection alongside a Blunox-managed dev one is a normal arrangement, and often the right one.

4  Test & save

The final step runs a reachability check: Data Sync dispatches a connection attempt to a runner in the connection's environment, which resolves the credential, opens a connection to the system, and reports back. It proves three things at once — that the address is right, that the credential resolves and authenticates, and that a runner in that environment can actually reach the host.

The check runs from a runner in the connection’s environment, so a pass also confirms the network path from where the sync will actually run.

The test is optional. You can save an untested connection and it will work fine if the details are correct. It is worth running anyway, because a failure here has a short, obvious cause, whereas the same failure discovered when a sync starts arrives as a run that will not leave starting.

Environments

Every connection is bound to exactly one environment: dev, staging or prod. There is no "any" option, and this is deliberate.

The binding does two jobs. First, it scopes execution: a runner is registered against an environment, and its permissions are checked against that scope, so a prod connection is only ever resolved and opened by a runner that is entitled to prod. A dev runner cannot be used to reach production, even by accident, even if someone has the host and the credential reference.

Second, it scopes authorisation. RBAC scopes nest — org, then workspace, then project, then environment — and a grant at a higher tier applies to every descendant. Granting someone editor on the staging environment lets them create and edit staging connections while leaving production untouched, without needing a separate workspace.

The practical consequence: if you need the same database reachable from two environments, create two connections. It is not duplication for its own sake — it is what keeps the runner and permission boundaries meaningful.

Editing and rotation

A connection can be edited after it is created. Changing addressing fields — a host that moved, a port, an SSL mode — takes effect for runs dispatched after the edit; a run already in flight keeps the configuration it started with.

Rotation depends on which credential model you chose, and the difference is the main day-to-day reason to prefer one over the other.

Editing a connection does not restart the syncs that use it. If a rotation has already broken an in-flight run, restart the sync once the connection is correct — see Monitoring & runs for how failed and terminated syncs are restarted.

Roles: source, sink, or both

A connector declares which sides of a sync it can serve, and that declaration is fixed in the implementation. It is not a setting. Of the five connectors documented in depth here:

The full catalog, including the connectors these docs do not cover in depth, is on the connectors page and is always visible in step one of the wizard.