Connections

One system you can talk to — source, sink, trigger or alert.

A Connection is a single system BARRY can talk to — a database, an object store, a warehouse, a message broker, or a notification channel. You configure a system once as a Connection, then reference it (capability-filtered) wherever it fits: as a transport's source or sink, as a trigger's message broker, or as an alert's channel.

Connections are managed on the Connections page. They replace the separate Sources, Destinations, and Event Connections pages of earlier releases — one unified list, one create flow.

Capabilities

Every connection has up to four capabilities, derived automatically from the connector kind you pick — you never set them by hand:

• Source — can be read from (a transport's read side).
• Sink — can be written to (a transport's write side).
• Trigger — can be subscribed to for inbound messages that start a run (see Triggers).
• Alert — can be notified when a run reaches an outcome (see Alerts).

A connection can carry several capabilities at once. For example, one Apache Kafka connection is Sink + Trigger + Alert; SQL Server is Source + Sink; Microsoft Teams is Alert only; Oracle is Source only. The Connections list shows a connection's capabilities as chips, and the capability filter (and the Source / Sink / Trigger / Alert dropdown in the New connection picker) lets you narrow to the systems that fit the job at hand.

When you reference a connection from a transport, trigger, or alert, the picker only offers connections that have the matching capability — a Source-only connection never appears as a sink option, and so on.

Placement — Cloud-direct vs Client

Every connection is reached from one of two places, chosen with the Run location field when you create or edit it:

• Cloud-direct (the server connects) — the server opens the connection itself. Use this for systems the cloud server can reach directly (cloud object stores, warehouses, internet-facing APIs).
• Via a BARRY Client — the system is reached through an on-prem client you pick from the list. Use this for systems inside your network (on-prem databases, file shares). See Clients.

The placement determines who opens the connection and therefore where the credentials are used — and it applies to both sides of a transport:

• A client-placed source is read by that client, which ships the rows onward. On-prem source databases are almost always client-placed.
• A client-placed sink is written by that client: the write runs in-process on the client, composing the same storage / format / partition building blocks the server would, so the result is identical and the destination only ever needs to be reachable from inside your network. Cloud sinks are almost always cloud-direct, but a sink that lives on-prem — a file share, an on-prem warehouse, or any destination you do not want the server to reach — is placed on a client instead.

Run topologies and data locality

A run's shape falls out automatically from the source's and sink's placements when it is enqueued; you never pick it. The combinations, and where the data physically travels, are:

• client → server (client-placed source, cloud sink) — the client reads and pushes to the server, which writes. Locality: client-to-cloud.
• server → server (both cloud-direct) — the server reads and writes in-process. Locality: cloud.
• server → client (cloud source, client-placed sink) — the server reads the source; the sink's client pulls the rows and writes them. Locality: server-relayed.
• client → client, same client (one client owns both sides) — that client reads and writes in a single in-process run; the data never leaves the machine. Locality: in-process.
• client → client, relay (two different clients) — the source client pushes to the server, the sink client pulls and writes. Locality: server-relayed.

Client-side writes cover finite runs to every sink family. The one continuous shape that reaches a client-placed sink today is the cross-client relay, where each change-feed micro-batch becomes a fresh finite write on the sink client.

Creating a connection

Click + New Connection and pick the system type. The picker groups every connector kind with its capability chips and a product logo; the search box and the capability dropdown narrow the list. Each connection has:

• a name and optional description;
• the connector-specific configuration (host, account, endpoint, …);
• the credentials for that system;
• for client-placed connections, the client that owns it.

The connector kind is fixed for the life of the connection — to point at a different kind of system, create a new connection (or Duplicate an existing one and change its settings).

Credentials and security

Connection secrets (passwords, keys, tokens, service-principal secrets) are encrypted at rest on the server and are never returned to the browser once saved. When you edit a connection, leave a secret field blank to keep the stored value; type a new value only to replace it. Duplicating a connection clears its secret fields so you must re-enter them.

For client-placed connections, decrypted credentials are delivered to the owning client per run, over TLS, and held in memory only — never written to disk on the client.

Testing a connection

Use Test connection from a connection's row to verify it works:

• Cloud-direct connections are probed directly by the server.
• Client-placed connections are probed by the owning client and the result is reported back — so a green result proves the client can reach the system, which is exactly what a run needs.

The last test result (success/failure, time, and any error) is shown on the connection and surfaced in the transport wizard.

What each connector can do

See the Connector Catalogue for every supported connector, its capabilities, how it is configured, and its key properties.

Roles

Creating, editing, testing, and deleting connections requires the Admin role. Read-only users can see the list but not change it. See Authentication & Roles.