Deploy and Host self hosted Postgres HA (Open-Source Highly Available PostgreSQL) on Railway

This template deploys a three-node Patroni Postgres 18.6 cluster with pgvector, PostGIS, and pg_cron, fronted by an HAProxy router on ports 5432 (read/write), 5433 (read-only), and 8080 (health).

About Hosting Postgres HA open-source software on Railway (self hosted Patroni Postgres template)

This template runs three Postgres 18.6 nodes (pg-1, pg-2, pg-3), each managed by Patroni with etcd holding cluster state, plus an HAProxy router.

You own the data. Railway handles containers, private networking, and the TCP proxy. Backups, major upgrades, and tuning are still yours.

Why Deploy Postgres HA, the managed Postgres alternative on Railway (Railway Free Trial)

Managed Postgres trades control for convenience: the provider picks the failover behavior and read routing, and the bill climbs with instance size.

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Postgres HA on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Railway vs Other Hosting Providers and VPS for Postgres HA self hosting

Three nodes plus an etcd quorum means picking where they live, and each provider trades convenience for control.

Provider	What You Get with Railway	What You Get with the Other Provider
DigitalOcean	Three Patroni nodes and the HAProxy router from one template, with private networking and no droplets to patch.	Root access on droplets, cheap block storage, and a managed option if you skip Patroni.
AWS	RW, RO, and health ports wired through the router with no VPC or security group work.	Fine-grained instance and EBS tuning, multi-AZ placement, and the wider AWS ecosystem.
Hetzner	Fast provisioning with no server administration, so your time goes to failover testing.	Low cost per core and RAM, plus dedicated hardware you can tune down to the kernel.

Pick Railway when you want the cluster running fast, and a VPS when cost per resource and kernel tuning matter more.

Common Use Cases for hosted Postgres HA

Primary app database with failover: Point your app at the RW port 5432 on the router. If the leader fails, Patroni promotes a replica and your app reconnects through the same hostname.
Read replicas via RO port: Send dashboards and reports to port 5433 to spread reads across the standbys and keep analytics off the primary.
pgvector RAG workloads: Keep embeddings in pgvector next to your relational data, so vector search and source tables share one HA cluster.
PostGIS location features: Run geofencing, nearest-neighbor, or spatial joins with PostGIS, which ships in the node image.
pg_cron scheduled jobs: Schedule cleanup and rollups inside the database with pg_cron, and check job status after a failover since jobs run on the primary.

Dependencies for Postgres HA Docker hosted on Railway

This template runs three Postgres nodes managed by Patroni, with etcd handling leader election, plus one HAProxy router in front.

Deployment Dependencies for Managed Postgres HA Service (Patroni Cluster)

The cluster needs four services: pg-1, pg-2, and pg-3 as the Patroni and etcd nodes, and a Postgres router running HAProxy.

Implementation Details for Postgres HA (Using onepush-dev postgres-ha-node and postgres-ha-router images)

The router listens on 5432 for read/write traffic to the primary, 5433 for read-only traffic to the replicas, and 8080 for the HTTP health check.

How does Postgres HA compare against other Postgres hosting options

Postgres HA vs single Railway Postgres (Single Node Railway Postgres Alternative)

Failover: Postgres HA runs three Patroni-managed nodes, so a crashed primary gets replaced automatically. A single node has no standby, so you wait for it to restart.
Read scaling: The RO port (5433) sends reads to the replicas. A single node is one server for everything.
Where single wins: It is simpler and has fewer moving parts. If brief downtime is acceptable, it is the better default.

Postgres HA vs AWS RDS Multi-AZ (AWS Managed HA Postgres Alternative)

Control: You run the Patroni cluster yourself, so you can inspect the REST API and tune shared_buffers. RDS hides most of that.
Extensions: pgvector, PostGIS, and pg_cron ship in the image, with versions pinned by digest.
Where RDS wins: Multi-AZ handles patching, backups, and failover for you. For most teams, that operational load is worth offloading.

Postgres HA vs Cloud SQL HA (Google Cloud Regional Postgres Alternative)

Standby model: Cloud SQL keeps a zonal standby with managed failover. Postgres HA uses Patroni and etcd quorum, which you can see and debug.
Routing: The HAProxy router gives separate RW and RO endpoints on fixed ports. Cloud SQL exposes one connection name and leaves read routing to you.
Where Cloud SQL wins: Google handles upgrades, maintenance windows, and point-in-time recovery.

Postgres HA vs self-managed Patroni on VMs (DIY Patroni Cluster Alternative)

Setup time: The template wires three nodes, etcd, and the router together. A hand-built cluster takes real time to get the DCS and HAProxy config right.
Consistency: Pinned digests mean every node runs the same Postgres 18.6 build. On VMs you keep packages in sync yourself.
Where DIY wins: On your own VMs you control the kernel, disks, network, and backup tooling. If you already run Patroni well, this template adds little.

How to use Postgres HA (the OSS highly available PostgreSQL)?

Deploy the template and let all four services come up. Patroni needs a minute or two to elect a primary.
Check /health on the router's port 8080 for a 200 with "Service ready". Then check /status for primary_up=1 and replicas_up=2.
Connect to read/write port 5432 with sslmode=require. The cert is self-signed, so verify-full will fail.
Run a write to confirm you're on the primary. pg_is_in_recovery should return false on 5432.
Point read-heavy traffic at port 5433 for the replicas. Replicas lag slightly, so keep read-after-write paths on 5432.

psql "host=your-router-domain port=5432 dbname=railway user=postgres sslmode=require" \
  -c "SELECT pg_is_in_recovery();"

psql "host=your-router-domain port=5433 dbname=railway user=postgres sslmode=require" \
  -c "SELECT pg_is_in_recovery();"

How to self host Postgres HA on other VPS Services (Patroni Postgres self hosting guide)

Run the same three-node cluster on any VPS, wiring the pieces yourself. You'll need Docker and Docker Compose on each host.

Clone the Repository

Grab the source from the onepush-dev repo.

git clone https://github.com/onepush-dev/postgres-ha.git
cd postgres-ha

Install Dependencies

Install Docker and Docker Compose on each VPS. Nodes need to reach each other on 5432 and 8008, and the router host needs 5432, 5433, and 8080 open.

docker --version
docker compose version

Configure Environment Variables

Set the same superuser, replication, and REST API credentials on all three nodes.

export PATRONI_SUPERUSER_PASSWORD=your-superuser-secret
export PATRONI_REPLICATION_PASSWORD=your-replication-secret
export PATRONI_RESTAPI_PASSWORD=your-restapi-secret
export PGHA_NODES=10.0.0.11,10.0.0.12,10.0.0.13

Start the Postgres HA Application

Start the nodes, then the router, and confirm a leader is elected before sending traffic.

docker compose up -d pg-1 pg-2 pg-3
docker compose up -d router
curl -s http://your-domain:8080/status

Railway handles the private networking, service wiring, and restarts that you'd otherwise rebuild by hand on a VPS.

Official Pricing of Postgres HA (Postgres pricing)

Postgres HA is open source, so there is no license fee to pay. You pay only for the infrastructure it runs on.

Postgres HA cloud vs self hosted comparison (Pricing, features, costs, and more)

Running Postgres HA on Railway is one way to get a three-node Patroni cluster, but it isn't the only way.

Monthly cost of self hosting Postgres HA on Railway

You pay for three Postgres service instances plus the router, and each one bills for its CPU, memory, and disk usage.

System Requirements for Hosting Postgres HA on a VPS

If you move the cluster to your own VPS, plan for three separate machines so a single host failure doesn't take out quorum.

Frequently Asked Questions (FAQs)

Which endpoint should I use to check health?

Hit GET /health on port 8080 and expect a 200 with "Service ready". For a deeper check, GET /status should show primary_up=1 and replicas_up=2.

What is the difference between port 5432 and port 5433?

Port 5432 is read/write and always routes to the current primary.

Why does verify-full fail?

The certificates are self-signed, so sslmode=require works while sslmode=verify-full rejects the connection. Full verification needs your own CA and certificates on the nodes.

What happens to connections during failover?

Patroni promotes a healthy replica and HAProxy moves port 5432 traffic to the new primary. Clients should retry on connection errors, since in-flight transactions on the old primary are lost.

Are pgvector, PostGIS, and pg_cron included?

Yes, the node image ships Postgres 18.6 with all three. You still need to run CREATE EXTENSION in each database where you want them.

When is three nodes overkill?

For dev, staging, or low-traffic apps that can tolerate a short restart, a single Railway Postgres instance is simpler and cheaper.