Getting started

BARRY has two halves — a server you run in your cloud and a client you run next to your data. Getting started is getting those two talking, and then moving one table end to end.

The server is a container. You deploy it to infrastructure you control — Azure, AWS, Google Cloud or a European provider, on Kubernetes or a single container host — backed by a PostgreSQL database you own and operate. It serves the admin UI and answers client polls, and it never reaches into your network. Everything it knows about your data, a client told it.

On a machine that can see your data, you install the client. On Windows that is a native service from an MSI installer; on Linux it is a container image. Either way it registers with a connection string — an endpoint and a key you copy from the UI. From that moment the client dials out to the server, and it appears as online on the Clients page. There is nothing to open inbound and nothing to expose.

Next you create a Connection: one system you can talk to, such as a SQL Server or a storage account, configured once. A Transport then wires a source connection to a destination connection, with a partition layout that decides how the data lands. A transport is deliberately simple to describe — a source, a destination, and the shape of the output.

Finally you press Run now. The client picks up the queued run on its next heartbeat, reads the source and writes the result — Parquet to a data lake to begin with, or a governed Delta or Iceberg table when you are ready. The Monitor page shows the run live: rows, bytes, duration. That is the whole loop — install the server, register a client, create a connection and a transport, and run it — and every heavier feature in BARRY builds on those same five steps.

← All documentation