Deploy and Host PeerDB on Railway

PeerDB is an open-source data movement engine built for Postgres. It streams a Postgres database into ClickHouse (and other warehouses and queues) with change data capture, so your analytics copy stays seconds behind production instead of a nightly dump behind it. You create peers and mirrors from a web UI or from plain SQL over the Postgres wire protocol.

About Hosting PeerDB

PeerDB is not one container. A working install is a catalog Postgres, a Temporal server that runs the replication workflows, an object store for staging files, an API, two workers, the SQL server on port 9900 and the web UI. The upstream docker-compose file wires those together and publishes the UI on a port with no login at all (authentication is disabled in the API log). Copy that to a public host and anyone who finds the URL can add peers holding your database credentials.

This template deploys the whole stack as nine Railway services with private networking already wired, and puts a basic-auth proxy in front of the UI:

peerdb is the only service with a public URL. Username peerdb, password generated per deploy (PASSWORD in that service's variables). Without credentials you get a 401.
peerdb-server speaks the Postgres protocol on a Railway TCP proxy. Connect with psql using the ready-made PEERDB_CONNECT variable and run CREATE PEER / CREATE MIRROR as SQL.
catalog is Postgres with wal_level=logical and a volume, so peers and mirror definitions survive redeploys.
temporal runs on the same catalog Postgres, with the MirrorName search attribute PeerDB needs created automatically on boot, and dynamic config applied.
minio (a community fork of MinIO, with a volume) provides the staging bucket that ClickHouse mirrors use; the peerdbbucket bucket is created for you.
flow-api, flow-worker, flow-snapshot-worker and peerdb-ui are the upstream images, pinned to stable-v0.35.5. The Temporal UI and the admin-tools sidecar from the compose file are left out; the sidecar's one job is done by the Temporal start command.

Verified on a live deploy of this template: unauthenticated requests get 401, authenticated requests to the UI and the REST API return 200, psql over the TCP proxy runs queries, a Postgres peer is created (which exercises the SQL server, the API and the catalog), and that peer was still there after the catalog service was redeployed.

What this template does not include is your data. Bring a source Postgres with logical replication enabled (wal_level=logical) and a ClickHouse destination, then add them as peers.

Why Deploy PeerDB on Railway?

Five of the nine services are plumbing you would otherwise wire by hand: private hostnames between the workers, Temporal and the catalog, a staging bucket, a volume on the right path, and a start order that waits for Temporal before the workers dial it. Railway gives each service a private address and one project to look at, so there is no compose file and no reverse proxy to write. The login on the UI is on from the first boot, not something you remember to add later.

Common Use Cases

Stream a production Postgres into ClickHouse for dashboards without running queries on the primary
Keep a real-time analytics copy of an application database in sync with change data capture
Run an initial snapshot of large tables, then switch to continuous replication
Move data between Postgres databases or into a queue such as Kafka with SQL-defined mirrors
Replace a nightly export job with a pipeline you can inspect in a UI

Dependencies for PeerDB Hosting

PostgreSQL with logical replication, as the source you replicate from (yours; not included)
A ClickHouse server as the destination for the main use case (yours; not included)
A catalog PostgreSQL, Temporal and an S3-compatible bucket are all included

Deployment Dependencies

What you get

Web UI at the public URL, behind basic auth (peerdb / generated password).
SQL interface on a Railway TCP proxy, with the psql command in PEERDB_CONNECT.
Catalog Postgres on a volume, staging bucket on a volume.
Pinned images (stable-v0.35.5), so a redeploy does not change the version underneath you.