repmgr

Prerequisites

You need the following:

• An active Azure subscription, an SSH public key, and a VNet with a subnet in the target region
• A subscription to this listing on Azure Marketplace
• A Network Security Group that allows TCP 22 (administration) and TCP 5432 (PostgreSQL and repmgr replication)

Standby nodes and application clients reach the primary on 5432. In production, restrict 5432 to your database and application subnets.

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM) for development and light workloads. For production databases, choose a larger size such as Standard_E2s_v5 or above.

Deploy the virtual machine

Create the VM from the image, and open SSH and the PostgreSQL port to your own network:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:repmgr-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-rg \
  --name repmgr-primary \
  --image sac1647283583153:repmgr-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
az vm open-port --resource-group my-rg --name repmgr-primary --port 5432 --priority 900

Retrieve your per-VM credentials

On first boot, the VM generates its own passwords and TLS certificate, writes the .pgpass for the repmgr role, and re-registers the primary with this VM's address. SSH in and read the root-only credentials file. When you connect from a client, replace <public-ip> with your VM's public IP.

# On the primary VM — the secrets are unique to each VM, generated on first boot.
sudo cat /root/repmgr-credentials.txt
# Use postgres.password as <POSTGRES_PASSWORD> and repmgr.password as <REPMGR_PASSWORD>
# when you connect from a client or a standby at <public-ip>.

The file is mode 0600, owned by root, and lists the postgres superuser password, the repmgr role password, the resolved host, and a ready-to-follow standby join walkthrough. Nothing is baked into the image, so every deployed VM has its own passwords and certificate.

Confirm the services are healthy

SSH into the VM and confirm that PostgreSQL 17 and repmgr are installed and running:

sudo systemctl is-active postgresql
sudo -u postgres psql -tAc "SELECT version();" /usr/lib/postgresql/17/bin/repmgr -V

You should see active, the PostgreSQL 17.10 server banner, and repmgr 5.5.0. On a VM that has completed first boot, repmgrd.service is also active. It starts once first boot has written the per-VM credentials.

Confirm the replication configuration

repmgr requires PostgreSQL to be configured for streaming replication. This image is already configured for it. Confirm the settings:

sudo -u postgres psql -tAc "SHOW shared_preload_libraries;"
sudo -u postgres psql -tAc "SHOW wal_level;"
sudo -u postgres psql -tAc "SHOW max_wal_senders;"

shared_preload_libraries includes repmgr (required for repmgrd), wal_level is replica, and max_wal_senders is 10, which leaves headroom for multiple standby nodes.

Show the cluster

repmgr keeps a record of every node in the cluster. On the primary, repmgr cluster show lists them. Run it as the postgres user, which authenticates as the repmgr role through the .pgpass that first boot wrote:

# Run on the primary (node at <public-ip>).
sudo -u postgres /usr/lib/postgresql/17/bin/repmgr -f /etc/repmgr.conf cluster show

With only the primary deployed, you see a single row: node 1, role primary, status * running. Standby nodes appear here as you add them.

Check node health

repmgr node check reports the replication readiness of a node, including its role, WAL archiving, replication slots and data directory:

# Run on the primary (node at <public-ip>).
sudo -u postgres /usr/lib/postgresql/17/bin/repmgr -f /etc/repmgr.conf node check

Every line reads OK. On the primary, the replication lag, upstream connection and downstream server checks report N/A or none, which is expected for a node with no standbys yet.

Add a standby node

To build a highly available cluster, deploy a second SecureAnyCloud repmgr VM and clone it from this primary. On the primary, read the repmgr role password from /root/repmgr-credentials.txt.

Then, on the new standby VM, authenticate to the primary and clone it. Replace <public-ip> with the primary's public IP and <REPMGR_PASSWORD> with the primary's repmgr password:

# On the STANDBY VM. Give this node a unique node_id (e.g. 2) in /etc/repmgr.conf first.
echo "<public-ip>:5432:*:repmgr:<REPMGR_PASSWORD>" | sudo -u postgres tee -a /var/lib/postgresql/.pgpass
sudo -u postgres chmod 600 /var/lib/postgresql/.pgpass
# Preview first, then clone and register:
sudo -u postgres /usr/lib/postgresql/17/bin/repmgr -h <public-ip> -U repmgr -d repmgr -f /etc/repmgr.conf standby clone --dry-run sudo -u postgres /usr/lib/postgresql/17/bin/repmgr -h <public-ip> -U repmgr -d repmgr -f /etc/repmgr.conf standby clone
sudo systemctl start postgresql
sudo -u postgres /usr/lib/postgresql/17/bin/repmgr -f /etc/repmgr.conf standby register

Run repmgr cluster show on the primary again. The standby appears as a second row with role standby, following node 1. Repeat the procedure for further standbys.

Connect application clients over TLS

Application clients connect to the primary as the postgres superuser over TLS. Replace <public-ip> with the primary's public IP and <POSTGRES_PASSWORD> with the value from the credentials file:

PGPASSWORD='<POSTGRES_PASSWORD>' psql "host=<public-ip> port=5432 dbname=postgres user=postgres sslmode=require" -c "SELECT now();"

The connection is encrypted with the per-VM certificate that first boot generated. Point your application's read/write traffic at the primary. Once you add standby nodes, direct read-only reporting traffic at them.

Automatic failover with repmgrd

repmgrd is already running on the primary and is configured for automatic failover (failover = automatic in /etc/repmgr.conf).

Once you have registered one or more standby nodes, repmgrd monitors the primary. If the primary fails, repmgrd promotes the most suitable standby and tells the remaining standbys to follow the new primary. Inspect repmgrd's decisions in its log:

sudo journalctl -u repmgrd --no-pager -n 50

For production, review the repmgr documentation on witness nodes, location and priority to tune promotion behavior. Place standbys in a different Azure availability zone from the primary.

Security notes

• No baked credential. Both the postgres superuser and the repmgr role ship with no password, and each VM generates its own on first boot. The credentials file is 0600 root:root.
• TLS for all off-box traffic. pg_hba.conf accepts standby replication, the repmgr database and application clients from the network only over TLS (hostssl) with scram-sha-256. A per-VM self-signed certificate is generated on first boot. For production, replace it with a certificate from your own CA.
• Network. Keep the Azure NSG tight and allow 5432 only from your database, application and standby subnets. The NSG is the first layer, and TLS and the per-VM password are the second and third.
• Rotating a password. To rotate the repmgr role password, run ALTER ROLE repmgr WITH PASSWORD '...' on the primary, update each node's .pgpass, and reload repmgrd.

Troubleshooting

repmgr cluster show cannot connect. Confirm that /var/lib/postgresql/.pgpass exists (mode 600, owned postgres) with the repmgr password, and that ssl = on in postgresql.conf. First boot writes both, so check /var/log/sac/sac-firstboot.log.

A standby will not clone. Confirm that the primary's NSG allows 5432 from the standby and that the standby's .pgpass has the primary's repmgr password. Then run standby clone --dry-run to surface the exact failure.

repmgrd is inactive. On a fresh VM, repmgrd starts only after first boot has written the credentials. Check systemctl status repmgrd and /var/log/sac/sac-firstboot.log. The daemon is gated on /var/lib/sac/data/repmgr-ready.

Support

SecureAnyCloud maintains this image and provides 24/7 support. For assistance, contact us through the SecureAnyCloud listing on Azure Marketplace.

Deploy on Azure

Launch repmgr PostgreSQL Replication Manager on Ubuntu 24.04 on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com