Architecture

How the server and client fit together.

This chapter explains how the parts of BARRY fit together — useful background when you reason about networking and security, though you do not need it to use the product.

The big picture

• The server is cloud-hosted and containerized. It holds all metadata, serves the admin UI, answers client polls, receives data, and — for cloud-direct destinations — writes it to the configured sinks.
• The client runs on a machine inside your network. It reads from on-prem sources and ships the data to the server, and it can also write the destination itself when the sink is placed on that client.

Client-initiated only

The single most important rule: the server never opens a connection to the client. All traffic flows from on-prem outward to the cloud over HTTPS, on a port that is almost always open for outbound traffic — so no inbound firewall changes are needed on-prem.

This has direct operational consequences:

• There are no inbound rules to open on the on-prem network.
• Schedules, configuration changes, and client updates are pulled by the client, never pushed by the server.
• A client that is offline simply stops polling; nothing on the server side breaks.

A Run now in the UI still reaches the client within a second or two — it feels like a push, while remaining strictly client-initiated.

How data travels

Structured data — table rows and API responses — streams over the connection in an efficient, columnar format, compressed for the wide-area link so your on-prem uplink does not become the bottleneck. Binary files stream in chunks. Live run metrics (rows/sec, bytes/sec, progress) travel on a separate, lightweight channel, never mixed into the data. See Monitoring & Runs.

Destinations

BARRY can land data in a range of backends and formats:

• Object stores — Azure Data Lake Gen2, Azure Blob, Amazon S3, Google Cloud Storage and Microsoft OneLake.
• File and table formats — Parquet, CSV, Delta and DuckLake, plus Apache Iceberg as a self-contained sink.
• Managed platforms — Databricks managed Delta and Microsoft Fabric, which stage the data and run their own load step to land a registered, query-ready table.

You configure these when you create destinations and output formats.

Where the write runs

A destination write runs in one of two places, following the placement of the sink connection (see Connections):

• Cloud-direct sink — the server writes it. On-prem clients that read a source push their batches to the server.
• Client-placed sink — the write runs on that client. When one client owns both the source and the sink, the data never leaves your network at all.

Either way the result is identical; placement simply decides where the bytes are written.

Metadata storage

The server stores all of its state — clients, connections, transports, triggers, alerts, run history and metrics — in PostgreSQL. Live metrics are also held in memory for the dashboard, so the live tiles stay responsive regardless of database load.

Security summary

• All transport is over HTTPS, client-initiated.
• A client authenticates with a connection string (an endpoint plus a key) bound to a server-side client identity. Keys can be rotated. See Clients.
• UI access is protected by OpenID Connect with role-based access control. See Authentication & Roles.
• Connection credentials are encrypted at rest on the server and never returned to the browser once saved.