Install pgAdmin 4 on Ubuntu 26.04 / 24.04

Copy the old pgAdmin repo line onto Ubuntu 26.04 and apt refuses to install it. The noble build of pgadmin4-server depends on python3.12, and 26.04 ships Python 3.14. The fix is one word. When the repo line reads the codename from lsb_release -cs, the same commands install pgAdmin 4 on Ubuntu 26.04 and 24.04, and you never have to touch them again on the next release.

Original content from computingforgeeks.com - post 32490

This guide runs pgAdmin 4 in web (server) mode under Apache, serves it over HTTPS, and configures the password exec allowlist that pgAdmin 9.19 introduced. That release changes how stored password commands work, so the upgrade section matters if you already run pgAdmin. Every command below was run on Ubuntu 26.04.1 LTS and Ubuntu 24.04.5 LTS with pgAdmin 4 9.19 in October 2026, and the outputs and screenshots come from those machines.

Check which Ubuntu releases the repo supports

pgAdmin’s own apt repository is the only source worth using on Ubuntu, because the distro archive does not package pgAdmin 4 at all. Each Ubuntu release gets its own suite, built against that release’s Python, and every suite is x86_64 only. On an ARM server (Graviton, Ampere, a Raspberry Pi) there is no DEB to install, so run pgAdmin from the container image there instead.

Ubuntu release	Suite (codename)	First pgAdmin build	Python the build depends on
26.04 LTS	resolute	9.15	python3.14
24.04 LTS	noble	8.7	python3.12

The first two rows were checked in the lab: apt-cache show on 26.04 lists Depends: python3.14 for the resolute 9.19 build, and the noble build fails on 26.04 because it wants python3.12. The first-build versions come from the pgAdmin apt download page, which also still lists Ubuntu 22.04 (jammy, from 6.9). The same repo line covers jammy, but 22.04 was not part of this test.

Set the shell variables

Four values repeat through the HTTPS, PostgreSQL and password exec steps, so export them once at the top of your SSH session. Change the hostname to the name you’ll put in the browser and pick your own database password. The rest of the commands then paste as they are, and they’re the same ones we ran on both lab machines.

export PGADMIN_FQDN="pgadmin.example.com"
export DB_NAME="inventory"
export DB_USER="appadmin"
export DB_PASS="ChangeMe-Str0ng-Pass"

If your session drops later, export these again before you continue. A blank variable produces a broken vhost or a role with no password, and neither fails loudly.

Add the pgAdmin 4 repository

The repo is signed with pgAdmin’s key, which apt reads from /etc/apt/keyrings. Both 26.04 and 24.04 already have that directory and ship curl and gpg, but the install line below is harmless if they’re present:

sudo apt update
sudo apt install -y curl gpg

Import the signing key in dearmored form so apt can use it directly:

curl -fsS https://www.pgadmin.org/static/packages_pgadmin_org.pub | sudo gpg --yes --dearmor -o /etc/apt/keyrings/packages-pgadmin-org.gpg

The --yes lets the same line overwrite the keyring on a re-run; without it gpg tries to prompt and fails with cannot open '/dev/tty', as it did on our second run. Now add the repo. The $(lsb_release -cs) part is the whole point: it expands to resolute on 26.04 and noble on 24.04, so this one line is correct on both.

echo "deb [signed-by=/etc/apt/keyrings/packages-pgadmin-org.gpg] https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/$(lsb_release -cs) pgadmin4 main" | sudo tee /etc/apt/sources.list.d/pgadmin4.list

Refresh the package index and ask apt which pgAdmin builds it can see. On a 26.04 box the resolute suite answered with every build from 9.15 to 9.19:

sudo apt update
apt-cache policy pgadmin4-web

The candidate should be the newest build, coming from the suite that matches your release:

pgadmin4-web:
  Installed: (none)
  Candidate: 9.19
  Version table:
     9.19 500
        500 https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/resolute pgadmin4/main all Packages
     9.18 500
        500 https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/resolute pgadmin4/main all Packages
     9.17 500
        500 https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/resolute pgadmin4/main all Packages
     9.16 500
        500 https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/resolute pgadmin4/main all Packages
     9.15 500
        500 https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/resolute pgadmin4/main all Packages

If the URL in that table says noble on a 26.04 machine, an old hardcoded line is still in /etc/apt/sources.list.d/. Remove it before you install, or apt ends in the dependency error covered at the end of this guide.

Install pgAdmin 4 in web mode

The repo publishes three install targets, and which one you pick decides whether you get a browser UI, a desktop window or both:

• pgadmin4-web: server mode under Apache, for a headless server
• pgadmin4-desktop: the desktop app, for an Ubuntu workstation
• pgadmin4: both of the above

A server has no desktop session to run the desktop app in, so install the web package. It pulls in Apache, mod_wsgi, pgadmin4-server (the Python application with its own bundled venv) and the PostgreSQL client tools (18 on 26.04, 16 on 24.04):

sudo apt install -y pgadmin4-web

On 26.04 apt resolved 17 packages and a 123 MB download, almost all of it the 119 MB pgadmin4-server DEB. The install finished in 31 seconds:

Installing:
  pgadmin4-web

Installing dependencies:
  apache2                  libaprutil1-dbd-sqlite3  postgresql-client
  apache2-bin              libaprutil1-ldap         postgresql-client-18
  apache2-data             libaprutil1t64           postgresql-client-common
  apache2-utils            liblua5.4-0              ssl-cert
  libapache2-mod-wsgi-py3  libpq5
  libapr1t64               pgadmin4-server

Suggested packages:
  apache2-doc              www-browser    postgresql-doc-18
  apache2-suexec-pristine  libpq-oauth
  | apache2-suexec-custom  postgresql-18

Summary:
  Upgrading: 0, Installing: 17, Removing: 0, Not Upgrading: 2
  Download size: 123 MB
  Space needed: 14.8 MB / 16.5 GB available

Notice that libpq5 comes from the pgAdmin repo (18.6-1.pgdg26.04+2) rather than the Ubuntu archive. That is expected: the pgAdmin repo carries its own libpq5 build for each release. The package lands under /usr/pgadmin4 and takes about 367 MB once unpacked.

Run setup-web.sh to create the admin login

Installing the package does not finish the job. Until setup-web.sh runs there is no configuration database, no admin account and no Apache config, and a request to /pgadmin4/login returned a 404 on the 24.04 test machine. The script asks for the email and password of the first pgAdmin user, then offers to enable mod_wsgi and restart Apache:

sudo /usr/pgadmin4/bin/setup-web.sh

Answer y to both Apache questions. The run on 26.04 looked like this:

Setting up pgAdmin 4 in web mode on a Debian based platform...
Creating configuration database...
NOTE: Configuring authentication for SERVER mode.

Enter the email address and password to use for the initial pgAdmin user account:

Email address: [email protected]
Password:
Retype password:
/usr/pgadmin4/venv/lib/python3.14/site-packages/alembic/operations/batch.py:298: UserWarning: Unnamed CHECK constraint on reflected table 'sharedserver' is being omitted from the table recreate; pass the constraint explicitly using batch_alter_table.table_args.  Naming CHECK constraints avoids this going forward.
  util.warn(
pgAdmin 4 - Application Initialisation
======================================

Creating storage and log directories...
We can now configure the Apache Web server for you. This involves enabling the wsgi module and configuring the pgAdmin 4 application to mount at /pgadmin4. Do you wish to continue (y/n)? y
The Apache web server is running and must be restarted for the pgAdmin 4 installation to complete. Continue (y/n)? y
Apache successfully restarted. You can now start using pgAdmin 4 in web mode at http://127.0.0.1/pgadmin4

The UserWarning about an unnamed CHECK constraint comes from Alembic while it builds the SQLite config database, and it is harmless. The email you type is the login name for the web UI. The password needs at least six characters: a shorter one prints Password must be at least 6 characters. Please try again. and asks again.

For automation (Ansible, cloud-init), the script also runs unattended. This form was used on the 24.04 machine and skips both prompts:

sudo [email protected] PGADMIN_SETUP_PASSWORD='Your-Admin-Pass' /usr/pgadmin4/bin/setup-web.sh --yes

Either way, the login page now answers on plain HTTP at /pgadmin4. Don’t log in yet: the next two sections switch it to HTTPS first, so the admin password never crosses the network in clear text.

Install PostgreSQL and create a login role

pgAdmin manages PostgreSQL but contains none, so it needs a server to point at. Skip this section if your database already runs elsewhere, because the connection steps work the same against a remote host. For a local server, the Ubuntu archive is enough. It installed PostgreSQL 18.6 on 26.04 and PostgreSQL 16.15 on 24.04:

sudo apt install -y postgresql
sudo -u postgres psql -c "SELECT version();"

On 26.04 the version string reads:

 PostgreSQL 18.6 (Ubuntu 18.6-0ubuntu0.26.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0, 64-bit

Never connect pgAdmin as the postgres superuser for day-to-day work. Create a role with a password and a database it owns. This is the account we’ll have pgAdmin log in as:

sudo -u postgres psql -c "CREATE ROLE ${DB_USER} LOGIN PASSWORD '${DB_PASS}';" -c "CREATE DATABASE ${DB_NAME} OWNER ${DB_USER};"

Ubuntu’s default pg_hba.conf already allows password logins over TCP from localhost, so nothing else changes when pgAdmin and PostgreSQL share the box. For a separate database server, the PostgreSQL on Ubuntu guide covers listen_addresses and the pg_hba.conf rule you need, and the PostgreSQL 18 on Debian guide does the same when the database lives on a Debian box.

Configure the 9.19 password exec allowlist

pgAdmin 9.19 no longer runs free-text “password exec” commands in server mode. A password exec command is a program pgAdmin runs to fetch a database password at connect time, so the password never sits in pgAdmin’s own database. Before 9.19 any pgAdmin user could type a shell command into that field once the admin had switched the feature on. The 9.19 release notes replace that with SERVER_PASSEXEC_COMMANDS: the administrator names the allowed commands in config, and users pick a name from a drop-down.

On a fresh install you don’t have to set it. The default is an empty dictionary, which simply turns the feature off, and the fresh 26.04 install logged nothing about it in /var/log/pgadmin/pgadmin4.log. Configure it when you want pgAdmin to pull passwords from a secret store, or before upgrading an install that already uses password commands (see the upgrade section below).

pgAdmin reads /etc/pgadmin/config_system.py last on Linux, after its own config.py and config_distro.py. Settings there survive package upgrades, which is not true of edits inside /usr/pgadmin4/web. Start with the secret the command will read. It must be readable by www-data, because Apache’s mod_wsgi process is what runs the command:

sudo mkdir -p /etc/pgadmin/secrets
echo "${DB_PASS}" | sudo tee /etc/pgadmin/secrets/${DB_USER} >/dev/null
sudo chown root:www-data /etc/pgadmin/secrets /etc/pgadmin/secrets/${DB_USER}
sudo chmod 0750 /etc/pgadmin/secrets
sudo chmod 0640 /etc/pgadmin/secrets/${DB_USER}

Then define the allowlist. Each entry maps a name to the executable and its arguments as a list. pgAdmin runs it without a shell, so pipes, globs and $VARS in the arguments are passed literally:

echo "SERVER_PASSEXEC_COMMANDS = {
    \"${DB_NAME}-db\": [\"/usr/bin/cat\", \"/etc/pgadmin/secrets/${DB_USER}\"],
}" | sudo tee /etc/pgadmin/config_system.py

pgAdmin imports this file as Python, so a typo breaks the import when Apache starts the application. Check the syntax with pgAdmin’s own Python before restarting:

sudo /usr/pgadmin4/venv/bin/python3 -c "import ast; ast.parse(open('/etc/pgadmin/config_system.py').read()); print('syntax ok')"
sudo systemctl restart apache2

A cat of a root-owned file is the simplest command that proves the mechanism. In production, point the entry at a small script that asks Vault, AWS Secrets Manager or your password manager’s CLI instead. Two more settings ship alongside it in 9.19, and both default to empty:

Setting (9.19)	Default	What it controls
SERVER_PASSEXEC_COMMANDS	{}	Named commands users may pick for a server’s password
SERVER_PASSEXEC_ENV_PASSTHROUGH	[]	Extra environment variables passed to those commands, such as VAULT_ADDR
SERVER_MODE_ALLOWED_SERVICES	[]	libpq service names a server may use; an empty list allows none
ENABLE_SERVER_PASS_EXEC_CMD	False	Deprecated and ignored in 9.19

The commands get a stripped environment (PATH, HOME, locale and temp variables) plus six variables describing the request. The comments in pgAdmin’s config.py split them into two groups, and a script that fetches secrets has to treat them differently:

• Trusted, set by pgAdmin: PGADMIN_PASSEXEC_PGADMIN_USER, PGADMIN_PASSEXEC_AUTH_SOURCE
• Untrusted, set by whoever edits the server: PGADMIN_PASSEXEC_HOST, _PORT, _USERNAME, _DATABASE

So authorise on the pgAdmin user, and never build a file path or a vault query from the untrusted four without checking them. If you register servers that use a service= entry from pg_service.conf, list those names in SERVER_MODE_ALLOWED_SERVICES, or 9.19 refuses to connect them.

Serve pgAdmin over HTTPS

setup-web.sh mounts pgAdmin at /pgadmin4 through a global Apache conf, which means it answers on every vhost, including the plain HTTP default site. The steps below add a TLS vhost, turn port 80 into a redirect, and mark the session cookie Secure. Keep pgAdmin off the public internet even with TLS: it holds credentials to your databases, so a VPN, an SSH tunnel or a firewall rule limited to your admin network is the right exposure.

The lab used a self-signed certificate for ${PGADMIN_FQDN}, which encrypts the traffic but makes browsers warn until you trust it. If you have a certificate from your internal CA or from Let’s Encrypt, skip the openssl line and put your own paths in the two SSLCertificate lines. Enable the modules and create the certificate:

sudo a2enmod ssl headers
sudo openssl req -x509 -nodes -newkey rsa:2048 -days 825 -keyout /etc/ssl/private/pgadmin.key -out /etc/ssl/certs/pgadmin.crt -subj "/CN=${PGADMIN_FQDN}" -addext "subjectAltName=DNS:${PGADMIN_FQDN}"

Next, write the vhost. Port 80 only redirects, and the 443 side sends the bare hostname straight to /pgadmin4/:

echo "<VirtualHost *:80>
    ServerName ${PGADMIN_FQDN}
    Redirect permanent / https://${PGADMIN_FQDN}/
</VirtualHost>

<VirtualHost *:443>
    ServerName ${PGADMIN_FQDN}
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/pgadmin.crt
    SSLCertificateKeyFile /etc/ssl/private/pgadmin.key
    Header always set Strict-Transport-Security \"max-age=31536000\"
    RedirectMatch ^/\$ /pgadmin4/
</VirtualHost>" | sudo tee /etc/apache2/sites-available/pgadmin.conf

Disabling 000-default matters more than it looks. While it is enabled, requests to the server’s IP address over plain HTTP land on it, and the global pgAdmin conf serves the login form there unencrypted. With it gone, the port 80 vhost catches those requests too and redirects them. Enable the new site, drop the default one, and tell pgAdmin to send its session cookie over HTTPS only. Neither the packages nor setup-web.sh create /etc/pgadmin, so the mkdir covers readers who skipped the password exec section:

sudo a2ensite pgadmin
sudo a2dissite 000-default
sudo mkdir -p /etc/pgadmin
echo "SESSION_COOKIE_SECURE = True" | sudo tee -a /etc/pgadmin/config_system.py
sudo apache2ctl configtest
sudo systemctl restart apache2

configtest prints Syntax OK; the AH00558 line about the server’s fully qualified name that appears above it is cosmetic. Ubuntu’s UFW ships an Apache Full profile for ports 80 and 443. Allow SSH (or your custom SSH port) before you enable the firewall, or you lock yourself out of a remote box:

sudo ufw allow OpenSSH
sudo ufw allow "Apache Full"
sudo ufw --force enable
sudo ufw status

Both rules should be listed for IPv4 and IPv6:

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Apache Full                ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Apache Full (v6)           ALLOW       Anywhere (v6)

Once you know where you’ll connect from, narrow it to your admin subnet with sudo ufw allow from 10.0.1.0/24 to any app "Apache Full" and drop the open rule with sudo ufw delete allow "Apache Full". To confirm the redirect and the HSTS header, query both ports from the server itself. The name has to resolve, so add it to DNS or /etc/hosts first:

curl -sI http://${PGADMIN_FQDN}/pgadmin4/ | grep -E "^HTTP|^Location"
curl -skI https://${PGADMIN_FQDN}/pgadmin4/login | grep -E "^HTTP|^Strict"

Port 80 returns a 301 to the HTTPS URL, and the HTTPS login page returns 200 with the HSTS header:

The pga4_session cookie in the HTTPS response now carries the Secure, HttpOnly and SameSite=Lax flags, so the browser never sends it back over plain HTTP.

Log in and register the PostgreSQL server

Browse to https://pgadmin.example.com/pgadmin4 (your own hostname) and accept the certificate warning if you used the self-signed one. Sign in with the email and password you gave setup-web.sh:

pgAdmin locks an account after MAX_LOGIN_ATTEMPTS failed logins, which is 3 in the default config.py, so type carefully. On the dashboard, click Add New Server. On the General tab, name the server inventory-db. On Connection, set Host name to localhost and Username to your ${DB_USER} (ours is appadmin), and leave Password empty. If you skipped the password exec section, type ${DB_PASS} here instead and ignore the next tab. Then open the tab where 9.19 keeps the allowlisted commands:

1. 1Advanced
2. 2Password exec command
3. 3Save

1. Advanced holds the password settings in server mode.
2. Password exec command lists None plus each name from SERVER_PASSEXEC_COMMANDS. Pick your ${DB_NAME}-db entry (inventory-db here).
3. Save registers the server and connects straight away.

The drop-down only appears populated when the config loaded cleanly. If it shows nothing but None, pgAdmin did not read config_system.py, so check the file’s syntax and restart Apache. After Save, the server shows up under Servers and the dashboard starts drawing live activity. No password was stored and no prompt appeared, which proves the command ran:

Expand the server, select the inventory database and open Tools > Query Tool. The lab database had a three-row items table, and F5 runs the query against it:

Under 1 second per query over HTTPS on a 2 vCPU VM is what we saw: the status bar reported 512 ms for this one. The Apache conf that ships in pgadmin4-web (and setup-web.sh enables) runs one mod_wsgi process with 25 threads, which is plenty for a handful of admins. If you’d rather keep everything in containers, the PostgreSQL and pgAdmin in Podman guide runs the same UI from the official image.

Upgrade an existing pgAdmin install to 9.19

The upgrade itself is an ordinary package upgrade, but the first start of 9.19 rewrites stored password commands and cannot be undone. On that start, every free-text command that exactly matches an entry in SERVER_PASSEXEC_COMMANDS becomes that entry’s name, and every other command is cleared. If the setting is still empty, pgAdmin postpones the conversion and warns at each start instead. Write the allowlist before you upgrade if any server uses a password command.

To see exactly what happens, we installed pgAdmin 9.18 on the 24.04 machine (an LXD system container on the lab VM) with ENABLE_SERVER_PASS_EXEC_CMD = True and one server whose command was /usr/bin/cat /etc/pgadmin/secrets/appadmin. Then we upgraded it without touching the config:

sudo apt update
sudo apt install --only-upgrade pgadmin4-web pgadmin4-server
sudo systemctl restart apache2

Both packages moved from 9.18 to 9.19, and on the first request the pgAdmin log (/var/log/pgadmin/pgadmin4.log) recorded two warnings:

2026-10-31 05:37:20,044: WARNING	pgadmin:	ENABLE_SERVER_PASS_EXEC_CMD is deprecated and no longer has any effect; define the permitted commands in SERVER_PASSEXEC_COMMANDS instead.
2026-10-31 05:37:20,053: WARNING	pgadmin:	SERVER_PASSEXEC_COMMANDS is not configured, but 1 row(s) in the server table still hold a password exec command from before the upgrade. They are not run in server mode. Configure SERVER_PASSEXEC_COMMANDS before the next start: commands that match a configured entry are then converted to its name, and the rest are cleared.

As the warning says, the stored command is not run in server mode until you act. The fix is the same allowlist as above, with the arguments matching the old command exactly when joined by single spaces. Write it, remove the deprecated line, and restart:

echo "SERVER_PASSEXEC_COMMANDS = {
    \"inventory-db\": [\"/usr/bin/cat\", \"/etc/pgadmin/secrets/appadmin\"],
}" | sudo tee /etc/pgadmin/config_system.py
sudo systemctl restart apache2

That tee overwrites the file, so re-add SESSION_COOKIE_SECURE = True or any other line you keep there. The next start converted the row silently. The sqlite3 CLI is not on a stock Ubuntu server, so install it with sudo apt install -y sqlite3 if you want to check. Reading the pgAdmin SQLite database before and after shows the old command moved into the new passexec_name column:

sudo sqlite3 /var/lib/pgadmin/pgadmin4.db "select id,name,passexec_cmd,passexec_name from server;"

Before the allowlist existed the command was still in passexec_cmd and the name was empty. After the restart we got:

1|inventory-db||inventory-db

A command with any difference in spacing or arguments would have been cleared instead, with a Cleared the password exec command warning naming the server. Back up /var/lib/pgadmin/pgadmin4.db before the upgrade if you have many of them, because that file is the only copy of the old strings. The same upgrade applies on Debian, which the pgAdmin 4 on Debian guide covers.

Fix “Depends: python3.12” on Ubuntu 26.04

This is the error the old hardcoded repo line produces. It was reproduced on a clean 26.04.1 system with apt/noble in the sources file:

The following packages have unmet dependencies:
 pgadmin4-web : Depends: pgadmin4-server (= 9.19) but it is not going to be installed
                Depends: apache2 but it is not going to be installed
                Depends: libapache2-mod-wsgi-py3 but it is not going to be installed
E: Unable to satisfy dependencies. Reached two conflicting assignments:
   1. pgadmin4-server:amd64=9.19 is selected for install because:
      1. pgadmin4-web:amd64=9.19 is selected for install
      2. pgadmin4-web:amd64=9.19 Depends pgadmin4-server (= 9.19)
   2. pgadmin4-server:amd64 Depends python3.12
      but none of the choices are installable:
      [no choices]

The Apache lines are a side effect, and the real cause is the last one. Each pgAdmin suite bundles a venv built for its release’s Python, and 26.04 has no python3.12 package. Don’t try to install an older Python to satisfy it. If you followed an older version of this guide, the key also lives at /usr/share/keyrings/pgadmin-keyring.gpg, so import it to the current path first, then point the repo at the right suite and install again:

curl -fsS https://www.pgadmin.org/static/packages_pgadmin_org.pub | sudo gpg --yes --dearmor -o /etc/apt/keyrings/packages-pgadmin-org.gpg
echo "deb [signed-by=/etc/apt/keyrings/packages-pgadmin-org.gpg] https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/$(lsb_release -cs) pgadmin4 main" | sudo tee /etc/apt/sources.list.d/pgadmin4.list
sudo apt update
sudo apt install -y pgadmin4-web

Check for this after moving a 24.04 server to 26.04 too: once you re-enable the third-party sources that do-release-upgrade disables, pgadmin4.list still says noble. The noble and resolute builds share the version string 9.19, so apt may report the package as already the newest version; sudo apt install --reinstall pgadmin4-server pgadmin4-web forces the resolute build. We did not run a release upgrade in the lab. Builds before 9.19 had a separate 26.04 problem, a stray Python copy in the venv that the release notes say stopped the DEB installing, so stay on 9.19 or newer there. For deeper work once pgAdmin is running, our PostgreSQL book picks cover administration beyond the GUI.