Introduction

What BARRY is and the core concepts.

BARRY — Batch And Realtime Replication Yard — is a self-hosted data integration runtime. It pulls data from on-premises enterprise sources — SQL Server, REST APIs, OData services and more — and lands it in cloud storage and modern table formats, without ever requiring an inbound connection into your network.

This documentation explains how to operate the runtime: how to register clients, define connections, build transports, automate them with triggers and alerts, and monitor data movement.

What BARRY does

At its core, BARRY moves a table (or an API response, or a file) from a system inside your network to a destination in the cloud, in a chosen format, on a chosen schedule. Everything in the product is built around composing and running these data movements.

• Pull, never push. A lightweight on-prem client initiates every connection to the cloud server. The server never reaches into your network. No inbound firewall rules are required.
• Governed landing. Data lands as Parquet files in a data lake, or directly as managed Delta tables governed by Unity Catalog, or in Microsoft Fabric — your choice per destination.
• Operated from one UI. Registering clients, defining connections, building transports, triggering runs, and watching live throughput all happen in the admin web UI.

Deployment model

The server runs as a containerized application on any cloud (Azure, AWS, or GCP) and uses PostgreSQL for its own metadata. The on-prem client runs inside your network as a native Windows service or a container. See Architecture for how the two communicate.

Core concepts

A few terms appear throughout the product and this documentation:

• Client — the on-prem agent, installed inside your network. It initiates all communication with the server and executes the data movements assigned to it. See Clients.
• Server — the cloud-hosted control plane. It holds all metadata, serves the admin UI, and answers the clients' polls. See Architecture.
• Connection — a system BARRY can talk to: a source to read from, a sink to write to, a trigger broker to start runs, or an alert channel to notify. Configured once, referenced everywhere. See Connections.
• Transport — a configured data movement: this table, from this source connection, into this sink connection, in this format. The transport is the central runtime object. See Transports.
• Trigger — an inbound event that starts a transport run (a schedule, a web request, a message, a file arrival, a chain, or a data sensor). See Triggers.
• Alert — an outbound notification when a run reaches an outcome. See Alerts.
• Run — a single execution of a transport. Runs are tracked, measured live, and kept in a history. See Monitoring & Runs.

How to read this documentation

If you are setting up the runtime for the first time, start with Getting Started, which walks through the whole flow end to end. For a conceptual overview of how the pieces fit together, read Architecture. The remaining chapters are reference material for each building block — read them as you reach the matching step in the UI.