Databases AWS

repmgr 17 on AWS User Guide

| Product: repmgr 17 on Ubuntu 24.04 on AWS

Overview

This guide covers launching and verifying repmgr 17 on Ubuntu 24.04 from cloudimg on Amazon EC2. It is one version of the cloudimg Hardened Adminer & Database Admin and Backup Tools AMIs listing on AWS Marketplace; you pick it as the software version when you subscribe and launch. The other tools in the listing are described on the listing's guide hub.

repmgr is the open-source replication manager for PostgreSQL. It sets up streaming-replication standbys (repmgr standby clone), shows and checks the state of the whole cluster, performs switchovers, and its daemon repmgrd watches the primary and promotes a standby automatically if the primary fails.

The image installs PostgreSQL 17.11 and repmgr 5.5.0 from the official PostgreSQL (PGDG) apt repository. Every instance boots as a ready primary (node 1): replication is configured, the repmgr role and database exist, the node is registered and repmgrd is monitoring it, so you can clone standbys from it straight away. The PostgreSQL and repmgr packages are not held, so apt upgrade keeps delivering PGDG minor (security) releases, and unattended security upgrades stay on for the operating system.

What is on the image:

  • PostgreSQL 17.11 (postgresql@17-main.service) on port 5432, configured for streaming replication (wal_level = replica, 10 WAL senders and slots, wal_log_hints, hot_standby, the repmgr library preloaded)
  • repmgr 5.5.0 with /etc/repmgr.conf for this node (automatic failover, promote and follow commands, monitoring history)
  • repmgrd (repmgrd.service) monitoring the cluster, started after first boot
  • A TLS certificate for PostgreSQL and the postgres and repmgr passwords, all generated on your instance's first boot
  • An egress backstop (repmgr-egress-guard.service) that controls where the postgres system user may connect, with an allow-list for your cluster's nodes
  • A self-test, sudo /usr/local/sbin/repmgr-selftest.sh, that checks logins, refusals and the cluster state end to end

Default user: ubuntu · Architecture: x86_64 · Root volume: 8 GiB gp3

Security posture

  • No default password. The image ships with no password on any PostgreSQL role and no repmgr role at all. First boot generates unique postgres and repmgr passwords and writes them to /root/repmgr-credentials.txt, readable by root only. repmgr reads its password from ~postgres/.pgpass (mode 0600), never from a command line.
  • TLS only on the network. PostgreSQL listens on 5432 on every interface, because standbys must reach the primary, but pg_hba.conf admits network clients only with hostssl and scram-sha-256; any connection without TLS is rejected. The certificate and key are generated on your instance; no key ships in the image, so no two instances share one.
  • SSH is the only open port. The listing's default security group opens 22 only. You open 5432 yourself, to your cluster's nodes and application subnet only (Step 6).
  • Egress backstop for the database. The postgres system user (PostgreSQL, repmgr and repmgrd) cannot connect to instance metadata, link-local or reserved ranges, IPv6, or any address inside your VPC except this instance's own PostgreSQL and the nodes you add to /etc/cloudimg/repmgr-egress-allow.conf (Step 6). A compromised database session therefore cannot scan your VPC.
  • No metadata access for the database. PostgreSQL, repmgrd and the first-boot service are also blocked by systemd from reaching the instance metadata service (169.254.169.254 and fd00:ec2::254). Amazon Time Sync (169.254.169.123) still works.
  • IMDSv2 required. The AMI is registered with ImdsSupport v2.0, so instances launched from it refuse token-less (IMDSv1) metadata requests.
  • Fails closed. If first boot cannot finish, it stops PostgreSQL and leaves repmgrd unstarted rather than leave a half-configured node, and tries again on the next boot.
  • No secrets in logs. Passwords are set over standard input with statement logging switched off, so they do not appear in the PostgreSQL log, /var/log/auth.log or the journal.
  • Per-instance identity. SSH host keys and the machine ID are generated fresh on every instance; SSH accepts keys only (no passwords, no root login).

Prerequisites

  1. An AWS account and permission to launch EC2 instances and create security groups
  2. An EC2 key pair in the Region you launch in
  3. A VPC subnet, with a public IP on the instance if you connect over the internet
  4. For a replicated cluster: two or more instances of this image in the same VPC

Recommended instance type: m5.large. Size the instance and its EBS volume for your PostgreSQL workload; every node in a cluster should have the same size.

Connecting to your instance

Version Operating system SSH user
repmgr 17 on Ubuntu 24.04 Ubuntu 24.04 LTS ubuntu

Step 1: Launch the instance

Option A: AWS Marketplace console

  1. Open the cloudimg Hardened Adminer & Database Admin and Backup Tools AMIs listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
  2. Once the subscription is active, choose Launch your software.
  3. Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for the full launch wizard). In Version, choose repmgr 17 on Ubuntu 24.04, then choose your Region.
  4. Pick an instance type (m5.large recommended; the software charge is $0.04 per vCPU per hour) and your key pair.
  5. Security group: the listing's default group allows SSH (22) only. Restrict it to your own IP address. Step 6 adds the PostgreSQL rule for your cluster.
  6. Choose your VPC and subnet, leave the metadata defaults (the image already requires IMDSv2), then choose Launch.

Option B: AWS CLI

Run this on your own workstation. Replace the AMI ID with the one shown for your Region on the Marketplace launch page, and the VPC, subnet, key pair and CIDR with your own. Launch one instance for a single primary, or --count 2 for a primary and a standby:

SG=$(aws ec2 create-security-group --group-name repmgr-cluster \
  --description "repmgr PostgreSQL cluster" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --count 2 \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=repmgr-node}]'

You do not need --metadata-options: the AMI already makes IMDSv2 required.

Step 2: Connect and read your credentials

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a minute of launch. It creates this instance's TLS certificate, sets the passwords, creates the repmgr role and database, registers this node as the primary and then writes the credentials file. Show the connection details (the two password lines are left out here; read them with sudo cat /root/repmgr-credentials.txt and keep them in your secrets manager):

sudo grep -vE '^(POSTGRES_PASSWORD|REPMGR_PASSWORD)=' /root/repmgr-credentials.txt

# repmgr 5.5 + PostgreSQL 17 - generated on first boot by repmgr-firstboot.service.
# These values are unique to this instance. Store them somewhere safe.

POSTGRES_HOST=<private-ip>
POSTGRES_PORT=5432
POSTGRES_USER=postgres
POSTGRES_SSLMODE=require

REPMGR_USER=repmgr
REPMGR_DATABASE=repmgr
REPMGR_NODE_ID=1
REPMGR_NODE_NAME=ip-172-31-80-193

TLS_CERTIFICATE=/etc/postgresql/17/main/tls/server.crt
TLS_CERTIFICATE_SHA256=<certificate-sha256-fingerprint>

# PostgreSQL listens on 5432 on every interface but admits network clients over TLS (scram-sha-256) only.
# The security group opens SSH 22 only: open 5432 to your standby and application subnets yourself.
# Standbys and the other cluster nodes must also be listed in /etc/cloudimg/repmgr-egress-allow.conf
# (then: sudo systemctl reload repmgr-egress-guard).
# Cluster:   sudo -u postgres repmgr -f /etc/repmgr.conf cluster show
# Self-test: sudo /usr/local/sbin/repmgr-selftest.sh
# User guide: https://www.cloudimg.co.uk/guides/repmgr-17-on-ubuntu-24-04-aws/

POSTGRES_PASSWORD is the postgres superuser's password for network logins; REPMGR_PASSWORD is the replication and management account repmgr uses between nodes. On the instance itself, sudo -u postgres psql logs in without a password.

Step 3: Confirm PostgreSQL, repmgr and repmgrd are running

psql --version
sudo -u postgres repmgr --version
systemctl is-active postgresql@17-main.service repmgrd.service repmgr-egress-guard.service
sudo ss -Hltn

psql (PostgreSQL) 17.11 (Ubuntu 17.11-1.pgdg24.04+2)
repmgr 5.5.0
active
active
active
LISTEN 0      200          0.0.0.0:5432 0.0.0.0:*
LISTEN 0      4096         0.0.0.0:22   0.0.0.0:*
LISTEN 0      4096   127.0.0.53%lo:53   0.0.0.0:*
LISTEN 0      4096      127.0.0.54:53   0.0.0.0:*
LISTEN 0      200             [::]:5432    [::]:*
LISTEN 0      4096            [::]:22      [::]:*

PostgreSQL listens on 5432 and SSH on 22; port 53 on 127.0.0.53/127.0.0.54 is the operating system's local DNS stub. repmgrd opens no port of its own.

Step 4: Show the cluster

repmgr runs as the postgres system user. cluster show lists every registered node, service status adds whether repmgrd is running on each, and node check runs repmgr's health checks on this node:

sudo -u postgres repmgr -f /etc/repmgr.conf cluster show
sudo -u postgres repmgr -f /etc/repmgr.conf service status
sudo -u postgres repmgr -f /etc/repmgr.conf node check

 ID | Name             | Role    | Status    | Upstream | Location | Priority | Timeline | Connection string
----+------------------+---------+-----------+----------+----------+----------+----------+------------------------------------------------------------------------------------------
 1  | ip-172-31-80-193 | primary | * running |          | default  | 100      | 1        | host=172.31.80.193 port=5432 user=repmgr dbname=repmgr connect_timeout=5 sslmode=require
 ID | Name             | Role    | Status    | Upstream | repmgrd | PID   | Paused? | Upstream last seen
----+------------------+---------+-----------+----------+---------+-------+---------+--------------------
 1  | ip-172-31-80-193 | primary | * running |          | running | 13308 | no      | n/a
Node "ip-172-31-80-193":
    Server role: OK (node is primary)
    Replication lag: OK (N/A - node is primary)
    WAL archiving: OK (0 pending archive ready files)
    Upstream connection: OK (N/A - node is primary)
    Downstream servers: OK (this node has no downstream nodes)
    Replication slots: OK (node has no physical replication slots)
    Missing physical replication slots: OK (node has no missing physical replication slots)
    Configured data directory: OK (configured "data_directory" is "/var/lib/postgresql/17/main")

The node name is the instance's hostname and the connection string is its private IP address. repmgr's own connections use sslmode=require.

Step 5: Log in over TLS and run the self-test

Log in to PostgreSQL as postgres over the instance's private address. The password is read from the credentials file at run time, so it never appears on screen:

export PGPASSWORD="$(sudo sed -n 's/^POSTGRES_PASSWORD=//p' /root/repmgr-credentials.txt)"
H="$(sudo sed -n 's/^POSTGRES_HOST=//p' /root/repmgr-credentials.txt)"
psql "host=$H port=5432 dbname=postgres user=postgres sslmode=require" \
  -c "SELECT current_user, current_setting('server_version') AS server_version, pg_is_in_recovery();" \
  -c '\conninfo'
unset PGPASSWORD

 current_user |           server_version           | pg_is_in_recovery
--------------+------------------------------------+-------------------
 postgres     | 17.11 (Ubuntu 17.11-1.pgdg24.04+2) | f
(1 row)

You are connected to database "postgres" as user "postgres" on host "172.31.80.193" at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off, ALPN: postgresql)

A connection without TLS is rejected by pg_hba.conf before any password is checked, and a wrong password is refused:

H="$(sudo sed -n 's/^POSTGRES_HOST=//p' /root/repmgr-credentials.txt)"
for mode in disable require; do
  OUT="$(PGPASSWORD=wrong-password psql "host=$H port=5432 dbname=postgres user=postgres sslmode=$mode" -c 'SELECT 1' 2>&1 || true)"
  echo "${OUT#*failed: }"
done

FATAL:  pg_hba.conf rejects connection for host "172.31.80.193", user "postgres", database "postgres", no encryption
FATAL:  password authentication failed for user "postgres"

The shipped self-test checks the whole node in one go: the credentials file and .pgpass agree, both accounts log in over TLS (including a replication connection for repmgr), wrong passwords and plaintext are refused, node 1 is the running primary and repmgrd is monitoring it. It prints REPMGR_SELFTEST_OK on success:

sudo /usr/local/sbin/repmgr-selftest.sh

== repmgr primary self-test ==
  OK: credentials file 0600 root; ~postgres/.pgpass (0600) holds the same repmgr password
  OK: PostgreSQL listens on 0.0.0.0:5432 and [::]:5432
  OK: postgres: per-VM password logs in over TLS; a wrong password and a plaintext connection are refused (and the right one still works)
  OK: repmgr: logs in over TLS for a normal and a replication connection; a wrong password is refused
  OK: repmgr: node 1 is registered as the running primary
  OK: repmgrd is active and monitoring node 1
REPMGR_SELFTEST_OK: per-VM postgres and repmgr passwords log in over TLS (normal and replication), wrong passwords and plaintext are refused, node 1 is the running primary and repmgrd is monitoring it.

Step 6: Open PostgreSQL to your cluster's nodes

Two layers decide who can reach PostgreSQL, and a standby needs both:

  1. The security group. Allow 5432 between the cluster's nodes only. If every node uses the same security group, a rule that names the group itself does exactly that. Run on your workstation:

text aws ec2 authorize-security-group-ingress --group-id <your-sg-id> \ --protocol tcp --port 5432 --source-group <your-sg-id>

Add a second rule for your application subnet if applications connect from outside the cluster (--cidr <your-app-cidr>). Never open 5432 to 0.0.0.0/0.

  1. The egress allow-list on every node. The postgres system user may connect only to the addresses listed in /etc/cloudimg/repmgr-egress-allow.conf, so each node must list every other node: a standby connects to its primary to replicate, and repmgr cluster show and repmgrd's failover connect to every node. On the primary, add the standby's private IP; on the standby, add the primary's:

bash echo '<standby-private-ip>' | sudo tee -a /etc/cloudimg/repmgr-egress-allow.conf sudo systemctl reload repmgr-egress-guard sudo nft list set inet cloudimg_repmgr_egress allow4

text 172.31.93.192 table inet cloudimg_repmgr_egress { set allow4 { type ipv4_addr flags interval auto-merge elements = { 172.31.93.192 } } }

The reload applies the list without restarting PostgreSQL. Until a node is listed, a connection to it from the postgres user is refused (Connection refused), even when the security group allows it.

No pg_hba.conf change is needed: the shipped rules already admit repmgr replication connections from any address over TLS with scram-sha-256:

hostssl   replication     repmgr          0.0.0.0/0               scram-sha-256
hostssl   all             all             0.0.0.0/0               scram-sha-256
hostnossl all             all             0.0.0.0/0               reject

To narrow them to your VPC, replace 0.0.0.0/0 (and ::/0) with your VPC CIDR in /etc/postgresql/17/main/pg_hba.conf on every node and run sudo systemctl reload postgresql@17-main.service.

Step 7: Add a standby

Launch a second instance of this image in the same VPC and security group, and complete Step 6 on both instances. Every instance boots as its own primary, so you turn the second one into a standby of the first: give it node ID 2, give repmgr the primary's repmgr password, and clone the primary's data over it.

Run these on the standby instance. First stop repmgrd and PostgreSQL and set the node ID (the node name and connection string are already this instance's own):

sudo systemctl stop repmgrd.service postgresql@17-main.service
sudo sed -i 's/^node_id=1$/node_id=2/' /etc/repmgr.conf
sudo grep -E '^(node_id|node_name|conninfo)=' /etc/repmgr.conf

node_id=2
node_name='ip-172-31-93-192'
conninfo='host=172.31.93.192 port=5432 user=repmgr dbname=repmgr connect_timeout=5 sslmode=require'

Put the primary's REPMGR_PASSWORD (from /root/repmgr-credentials.txt on the primary) into this node's ~postgres/.pgpass. read -rs keeps it off the screen and out of your shell history:

read -rs -p 'Primary REPMGR_PASSWORD: ' P; echo
printf '*:5432:*:repmgr:%s\n' "$P" | sudo -u postgres tee /var/lib/postgresql/.pgpass >/dev/null; unset P
sudo stat -c '%a %U' /var/lib/postgresql/.pgpass

Check that the clone can run, then clone. -F replaces this instance's own (empty) database with the primary's, and -c asks the primary for an immediate checkpoint:

sudo -u postgres repmgr -d 'host=<primary-private-ip> user=repmgr dbname=repmgr sslmode=require' -f /etc/repmgr.conf standby clone --dry-run
sudo -u postgres repmgr -d 'host=<primary-private-ip> user=repmgr dbname=repmgr sslmode=require' -f /etc/repmgr.conf standby clone -F -c

INFO: connecting to source node
DETAIL: connection string is: user=repmgr dbname=repmgr host=172.31.80.48 sslmode=require
DETAIL: current installation size is 29 MB
...
INFO: all prerequisites for "standby clone" are met
...
NOTICE: starting backup (using pg_basebackup)...
NOTICE: standby clone (using pg_basebackup) complete

The dry run also prints "config_directory" set in repmgr.conf, but --copy-external-config-files not provided. That is intended: the standby keeps its own configuration in /etc/postgresql/17/main, including its own TLS certificate.

Start PostgreSQL, register the standby and start repmgrd:

sudo systemctl start postgresql@17-main.service
sudo -u postgres repmgr -f /etc/repmgr.conf standby register
sudo systemctl start repmgrd.service

INFO: connecting to local node "ip-172-31-93-192" (ID: 2)
INFO: connecting to primary database
WARNING: --upstream-node-id not supplied, assuming upstream node is primary (node ID: 1)
INFO: standby registration complete
NOTICE: standby node "ip-172-31-93-192" (ID: 2) successfully registered

The standby now holds a copy of the primary's database, including its roles, so the primary's postgres and repmgr passwords apply to it; the passwords in the standby's own /root/repmgr-credentials.txt no longer do. The shipped self-test checks a primary, so run it on the primary.

Step 8: Check replication

On the primary, both nodes are listed, repmgrd runs on both, and the standby streams over TLS:

sudo -u postgres repmgr -f /etc/repmgr.conf service status
sudo -u postgres psql -X -c "SELECT client_addr, usename, state, sync_state, ssl FROM pg_stat_replication JOIN pg_stat_ssl USING (pid);"

 ID | Name             | Role    | Status    | Upstream        | repmgrd | PID  | Paused? | Upstream last seen
----+------------------+---------+-----------+-----------------+---------+------+---------+--------------------
 1  | ip-172-31-80-48  | primary | * running |                 | running | 1188 | no      | n/a
 2  | ip-172-31-93-192 | standby |   running | ip-172-31-80-48 | running | 2714 | no      | 0 second(s) ago
  client_addr  | usename |   state   | sync_state | ssl
---------------+---------+-----------+------------+-----
 172.31.93.192 | repmgr  | streaming | async      | t
(1 row)

A row written on the primary appears on the standby, which is read-only:

-- on the primary
sudo -u postgres psql -c "CREATE TABLE repl_check (id int PRIMARY KEY, note text); INSERT INTO repl_check VALUES (1, 'written on the primary');"
-- on the standby
sudo -u postgres psql -c "SELECT note, pg_is_in_recovery() FROM repl_check;"
          note          | pg_is_in_recovery
------------------------+-------------------
 written on the primary | t
(1 row)

Step 9: Automatic failover and bringing the old primary back

repmgrd on the standby checks the primary continuously. If the primary stops answering, repmgrd tries to reconnect 6 times, 10 seconds apart, and then promotes the standby. In cloudimg's test, stopping PostgreSQL on the primary promoted the standby about 50 seconds later:

[WARNING] unable to reconnect to node "ip-172-31-80-48" (ID: 1) after 6 attempts
[NOTICE] this node is the only available candidate and will now promote itself
[NOTICE] promoting standby to primary
[DETAIL] promoting server "ip-172-31-93-192" (ID: 2) using pg_promote()
[DETAIL] server "ip-172-31-93-192" (ID: 2) was successfully promoted to primary

Read the history with sudo -u postgres repmgr -f /etc/repmgr.conf cluster event and journalctl -u repmgrd.service. Point your applications at the new primary (or use a connection string that lists both nodes with target_session_attrs=read-write).

The failed primary must not start again as a primary. To bring it back as a standby of the new primary, run Step 7 on it, cloning from the new primary's private IP, and register it with standby register --force (its node ID stays 1):

sudo systemctl stop repmgrd.service postgresql@17-main.service
sudo -u postgres repmgr -d 'host=<primary-private-ip> user=repmgr dbname=repmgr sslmode=require' -f /etc/repmgr.conf standby clone -F -c
sudo systemctl start postgresql@17-main.service
sudo -u postgres repmgr -f /etc/repmgr.conf standby register --force
sudo systemctl start repmgrd.service

The image manages PostgreSQL with systemd and configures no service_* commands for repmgr, so use systemctl to start and stop PostgreSQL; repmgr's node rejoin, which starts PostgreSQL itself with pg_ctl, is not used on this image.

Step 10: Check the security controls

Every PostgreSQL and repmgr unit carries the metadata block, only postgres and repmgr have passwords, and the egress backstop is loaded:

systemctl show -p IPAddressDeny postgresql@17-main.service repmgrd.service repmgr-firstboot.service
sudo -u postgres psql -tAc "SELECT rolname, rolsuper, rolreplication, rolpassword IS NOT NULL AS has_password FROM pg_authid WHERE rolcanlogin ORDER BY 1;"
sudo nft list chain inet cloudimg_repmgr_egress output | grep -c cloudimg-backstop

IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128

IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128

IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128
postgres|t|t|t
repmgr|t|t|t
6

Maintenance

  • Change a password. Run sudo -u postgres psql, then \password postgres or \password repmgr (it prompts and never puts the password on a command line). After changing the repmgr password, update the repmgr line in /var/lib/postgresql/.pgpass on every node of the cluster, and update /root/repmgr-credentials.txt and your secrets manager.
  • PostgreSQL configuration. cloudimg's settings are in /etc/postgresql/17/main/conf.d/10-cloudimg.conf (listener, replication settings, password encryption) and 20-cloudimg-tls.conf (TLS, written by first boot). Client access rules are in /etc/postgresql/17/main/pg_hba.conf. Apply changes with sudo systemctl reload postgresql@17-main.service (or restart for settings that need it).
  • Your own certificate. Replace /etc/postgresql/17/main/tls/server.crt and server.key (owner postgres, key mode 0600) and run sudo systemctl reload postgresql@17-main.service.
  • repmgr configuration. /etc/repmgr.conf (owner root, group postgres, mode 0640). After changing it run sudo systemctl restart repmgrd.service. The promote_command and follow_command use repmgr's own standby promote and standby follow.
  • Pause failover during maintenance. sudo -u postgres repmgr -f /etc/repmgr.conf service pause stops repmgrd on every node from acting on a failure; service unpause resumes it.
  • Backups. Replication is not a backup. Take EBS snapshots or pg_dump/pg_basebackup backups regularly.
  • Updates. sudo apt update && sudo apt upgrade installs PostgreSQL 17 minor releases and repmgr updates from PGDG and Ubuntu security updates. Upgrade standbys first, then switch over and upgrade the old primary.
  • Logs. /var/log/postgresql/postgresql-17-main.log, journalctl -u repmgrd.service, and sudo -u postgres repmgr -f /etc/repmgr.conf cluster event for repmgr's event history; first boot logs to journalctl -u repmgr-firstboot.service.

What cloudimg changed from the upstream defaults

  • PostgreSQL and repmgr come from PGDG with the repository's signing key pinned to the published PostgreSQL fingerprint.
  • The cluster is configured for replication and repmgr is preloaded; every instance boots as a registered primary with repmgrd running as a systemd service (the package's default is a disabled SysV script).
  • PostgreSQL listens on every interface (the Debian default is localhost) but pg_hba.conf admits network clients only over TLS with scram-sha-256; the Debian "snakeoil" certificate is not used, and each instance generates its own.
  • The postgres and repmgr passwords are generated on your instance's first boot; the image contains no password at all.
  • The postgres system user is confined by an nftables egress backstop with an allow-list for your cluster's nodes, and PostgreSQL, repmgrd and first boot cannot reach the instance metadata service.

Support

cloudimg supports this image by email at support@cloudimg.co.uk. Include the instance ID, the version (repmgr 17 on Ubuntu 24.04) and what you were doing.

PostgreSQL is a trademark of the PostgreSQL Community Association of Canada. repmgr is developed by EnterpriseDB and the repmgr contributors and is licensed under the GNU General Public License v3. Ubuntu is a trademark of Canonical Ltd. cloudimg is not affiliated with or endorsed by these organisations.