The Ultimate Guide to Simple pgAdmin Deployment with Docker

Unlock the Power of PostgreSQL Management with Containerization

PostgreSQL is one of the world’s most advanced and popular open-source relational database systems, renowned for its robustness, feature set, and reliability. Managing PostgreSQL databases, however, often requires a dedicated tool that provides a graphical interface for tasks ranging from writing SQL queries to managing users, permissions, and server configurations. This is where pgAdmin shines. pgAdmin is the de facto open-source administration and development platform for PostgreSQL.

Traditionally, installing pgAdmin involved downloading platform-specific installers, managing dependencies, and potentially dealing with conflicts or complex setup procedures, especially when managing multiple versions or instances. Enter Docker, the revolutionary containerization platform that simplifies application deployment and management by packaging applications and their dependencies into lightweight, portable containers.

Deploying pgAdmin using Docker offers numerous advantages:

Isolation: Run pgAdmin in a self-contained environment, isolated from your host operating system and other applications, preventing dependency conflicts.
Consistency: Ensure pgAdmin runs the same way across different environments (development, testing, production) and different host machines (Linux, macOS, Windows).
Simplicity: Deploying with Docker often involves just a few simple commands, abstracting away the underlying installation complexities.
Portability: Easily move your pgAdmin setup between machines or cloud providers.
Version Management: Effortlessly run specific versions of pgAdmin or test new releases without affecting your main installation.
Resource Efficiency: Containers generally consume fewer resources than full virtual machines.
Scalability (Less relevant for pgAdmin itself, but benefits the ecosystem): While pgAdmin isn’t typically scaled horizontally, using Docker aligns with modern scalable infrastructure practices.

This comprehensive guide will walk you through various methods for deploying pgAdmin using Docker, starting from the absolute simplest approach and progressing to more robust and recommended configurations using Docker Compose. We will cover persistence, security considerations, common configurations, and troubleshooting tips, providing you with the knowledge to confidently manage your PostgreSQL databases with a containerized pgAdmin instance.

Prerequisites: Getting Your Environment Ready
- Installing Docker
- Basic Docker Concepts Refresher
The Simplest Deployment: Quick & Ephemeral (docker run)
- Understanding the Core Command
- Accessing Your Ephemeral Instance
- The Major Downside: Lack of Persistence
Adding Persistence: Saving Your Configuration (docker run with Volumes)
- Why Persistence Matters for pgAdmin
- Introducing Docker Volumes
- Using Named Volumes (Recommended)
- Using Bind Mounts (Alternative)
- The Updated docker run Command
Configuring Credentials and Ports (docker run)
- Setting the Default Login Email and Password
- Understanding Port Mapping
- Putting It All Together: A Practical docker run Command
The Recommended Approach: Using Docker Compose
- Why Docker Compose?
- Creating the docker-compose.yml File
- Defining the pgAdmin Service
- Specifying the Image
- Setting Environment Variables (Credentials)
- Mapping Ports
- Configuring Volumes for Persistence
- Running pgAdmin with docker-compose up
- Stopping and Removing with docker-compose down
- Managing the Container Lifecycle
Accessing and Using Your Dockerized pgAdmin
- Finding Your Host IP Address or Using localhost
- Logging In
- Adding Your First PostgreSQL Server Connection
- Navigating the Interface (Brief Overview)
Advanced Configuration and Best Practices
- Persistence Deep Dive:
  - Named Volumes vs. Bind Mounts: Pros and Cons
  - Locating Volume Data on the Host
  - Backup Strategies for pgAdmin Data
- Security Considerations:
  - Strong Credentials (Mandatory!)
  - Running as a Non-Root User (Image Default)
  - Securing Network Access (Firewalls, VPNs)
  - HTTPS/SSL Encryption (Crucial!)
    - Why Plain HTTP is Risky
    - Using a Reverse Proxy (Nginx, Traefik, Caddy)
    - Example Concept with Nginx Proxy Manager
    - Self-Signed Certificates (Development Only)
  - Docker Network Isolation
  - Regular Updates
- Networking Nuances:
  - Handling Port Conflicts
  - Understanding Docker Networks (Bridge, Host, Custom)
- Resource Management:
  - Limiting CPU and Memory (Optional)
- Upgrading pgAdmin:
  - The Upgrade Process with docker run
  - The Upgrade Process with Docker Compose
- Custom pgAdmin Configuration (config_local.py)
Troubleshooting Common Issues
- Container Fails to Start
- Cannot Access pgAdmin Web Interface
- Login Failed
- Configuration Not Persisted
- Connection Errors to PostgreSQL Server
- Checking Container Logs (docker logs)
- Inspecting Container Details (docker inspect)
Alternative Scenarios
- Running pgAdmin and PostgreSQL Together (Docker Compose)
- Using Specific pgAdmin Versions (Image Tags)
Conclusion: Embracing Containerized Database Management

1. Prerequisites: Getting Your Environment Ready

Before diving into deploying pgAdmin, ensure your system meets the following requirements:

Installing Docker

Docker needs to be installed and running on your host machine. Docker provides native installers for major operating systems:

Docker Desktop for Windows: Download from the official Docker website. Requires Windows 10/11 (64-bit Pro, Enterprise, or Education) or Windows 10/11 Home with WSL 2 (Windows Subsystem for Linux 2) enabled.
Docker Desktop for Mac: Download from the official Docker website. Requires a recent version of macOS.
Docker Engine for Linux: Installation varies by distribution (Ubuntu, Debian, CentOS, Fedora, etc.). Follow the official Docker documentation for your specific Linux distribution. Typically involves adding Docker’s repository and installing the docker-ce (Community Edition) package.

Verification: After installation, open a terminal or command prompt and run the following commands to ensure Docker is installed and running correctly:

“`bash
docker –version
docker ps

For Docker Desktop, ensure the Docker engine is running (usually indicated by a whale icon in the system tray/menu bar).

For Linux, check the service status:

sudo systemctl status docker # (or equivalent for your init system)
“`

You might need to add your user to the docker group on Linux to run Docker commands without sudo:

“`bash
sudo usermod -aG docker $USER

Log out and log back in for the group change to take effect.

“`

Basic Docker Concepts Refresher

While this guide aims for simplicity, a basic understanding of these Docker concepts is helpful:

Image: A read-only template containing the application (pgAdmin), its dependencies, and configuration. Images are used to create containers. The official pgAdmin image is typically dpage/pgadmin4.
Container: A runnable instance of an image. It’s an isolated process running on your host machine.
Volume: A mechanism for persisting data generated by and used by Docker containers. Essential for saving pgAdmin configurations and server definitions.
Port Mapping: Allows you to access services running inside a container (like the pgAdmin web server) from your host machine’s network.
Environment Variables: Used to pass configuration settings (like default credentials) into a container when it starts.
Docker Hub: The default public registry where Docker images (like dpage/pgadmin4) are stored and shared.

2. The Simplest Deployment: Quick & Ephemeral (`docker run`)

Let’s start with the absolute minimum required to get a pgAdmin container running. This method is great for a quick test drive but not suitable for regular use because any configuration you make will be lost when the container stops.

Understanding the Core Command

Open your terminal or command prompt and execute the following command:

bash docker run --rm -p 8080:80 dpage/pgadmin4

Let’s break down this command:

docker run: The fundamental command to create and start a new Docker container.
--rm: This flag is crucial here. It automatically removes the container (and its filesystem) when it stops. This ensures cleanup but also causes the data loss mentioned earlier.
-p 8080:80: This maps port 8080 on your host machine to port 80 inside the container. pgAdmin’s web server runs on port 80 by default within the container. You can choose a different host port if 8080 is already in use (e.g., -p 5050:80). The format is HOST_PORT:CONTAINER_PORT.
dpage/pgadmin4: This is the name of the official pgAdmin 4 Docker image available on Docker Hub. Docker will automatically download this image if it’s not already present on your system.

When you run this command, you’ll see output in your terminal as pgAdmin starts up within the container.

Accessing Your Ephemeral Instance

Once you see log messages indicating the server has started (look for lines mentioning listening on port 80 or server startup complete), open your web browser and navigate to:

http://localhost:8080

(If you used a different host port, replace 8080 accordingly. If running Docker on a remote machine or VM, replace localhost with the machine’s IP address).

You should be greeted by the pgAdmin login screen. Since we didn’t specify any credentials, the image uses default (but often randomly generated or documented defaults that must be changed). Check the container logs or the image documentation for the initial credentials if they aren’t immediately obvious or prompted. However, for this ephemeral setup, the focus is just on getting it running.

The Major Downside: Lack of Persistence

Play around with the interface. Try adding a server connection (though you might not have credentials readily available). Now, go back to the terminal where docker run is executing and press Ctrl+C. This stops the container. Because we used the --rm flag, the container is immediately deleted.

If you try running the docker run command again and access http://localhost:8080, you’ll get a fresh pgAdmin instance. Any server connections or settings you configured previously are gone. This is clearly impractical for any real work.

3. Adding Persistence: Saving Your Configuration (`docker run` with Volumes)

To make pgAdmin useful, we need to ensure its configuration data (like server connections, user preferences, query history, etc.) persists even if the container is stopped, removed, and recreated. This is achieved using Docker Volumes.

Why Persistence Matters for pgAdmin

pgAdmin stores critical information within its container filesystem, typically in directories like /var/lib/pgadmin. This includes:

pgadmin4.db: An SQLite database holding server definitions, user preferences, query history snippets, etc.
sessions: Session management data.
storage: User-specific files, like query history files or backups initiated through the interface.
Configuration files (though often managed via environment variables initially).

Without persisting these locations, all your setup work vanishes when the container is removed.

Introducing Docker Volumes

Docker Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. They are managed by Docker itself and stored in a dedicated area on the host filesystem (often within /var/lib/docker/volumes/ on Linux).

Key advantages of volumes:

Easier to back up or migrate than bind mounts.
Managed by Docker CLI commands (docker volume create, docker volume ls, docker volume rm, docker volume inspect).
Work seamlessly across Linux, macOS, and Windows.
Can be pre-populated by a container.
Can be shared safely among multiple containers.

Using Named Volumes (Recommended)

Named volumes are the most straightforward and recommended way. You give the volume a name, and Docker handles the underlying storage location.

To use a named volume, we modify the docker run command using the -v or --volume flag:

-v <volume-name>:<container-path>

For pgAdmin, the primary path to persist is /var/lib/pgadmin. Let’s create a named volume called pgadmin-data:

“`bash

You can optionally create the volume beforehand, though `docker run` will create it if it doesn’t exist.

docker volume create pgadmin-data

Now run the container, mounting the named volume:

docker run -d \
-p 8080:80 \
-v pgadmin-data:/var/lib/pgadmin \
–name my-pgadmin \
dpage/pgadmin4
“`

Changes Explained:

-d: Runs the container in “detached” mode (in the background). Your terminal is freed up.
-v pgadmin-data:/var/lib/pgadmin: This is the key part. It mounts the named volume pgadmin-data to the /var/lib/pgadmin directory inside the container. Any data written to /var/lib/pgadmin by the pgAdmin process will now be stored in the pgadmin-data volume on the host.
--name my-pgadmin: Assigns a recognizable name (my-pgadmin) to the container. This makes it easier to manage (e.g., docker stop my-pgadmin, docker rm my-pgadmin, docker logs my-pgadmin). If you don’t provide a name, Docker assigns a random one.
We removed --rm: Since we want the data to persist between container runs, we don’t want the container (and its link to the volume) automatically removed on stop. We will manage removal manually when needed.

Now, access http://localhost:8080, configure some server connections, and change some settings. Then, stop and remove the container (not the volume):

bash docker stop my-pgadmin docker rm my-pgadmin

Verify the volume still exists:

“`bash
docker volume ls

You should see ‘pgadmin-data’ listed.

“`

Now, run the exact same docker run command again:

bash docker run -d \ -p 8080:80 \ -v pgadmin-data:/var/lib/pgadmin \ --name my-pgadmin \ dpage/pgadmin4

Access http://localhost:8080. Your previously configured server connections and settings should still be there! The new container attached to the existing pgadmin-data volume, restoring its state.

Using Bind Mounts (Alternative)

Bind mounts map a directory or file from your host machine’s filesystem directly into the container.

Syntax: -v /path/on/host:/path/in/container

Example:

“`bash

Create a directory on your host first

mkdir ~/pgadmin-data-host

Run the container using the bind mount

docker run -d \
-p 8080:80 \
-v ~/pgadmin-data-host:/var/lib/pgadmin \
–name my-pgadmin-bind \
dpage/pgadmin4
“`

Pros of Bind Mounts:

Easy to access/edit the persisted data directly from the host filesystem.

Cons of Bind Mounts:

Less portable, as the host path is hardcoded.
Can lead to permission issues, especially on Linux, if the user running Docker doesn’t have proper permissions for the host directory, or if the user ID (UID) / group ID (GID) inside the container doesn’t match the host directory ownership. The pgAdmin container runs as a non-root user (pgadmin, typically UID/GID 5050), which might not have write access to an arbitrary host directory created by your user.
Host filesystem structure “leaks” into the container configuration.

Recommendation: Use named volumes unless you have a specific reason to use bind mounts and understand the potential permission complexities.

4. Configuring Credentials and Ports (`docker run`)

Running pgAdmin without setting default credentials relies on potentially insecure defaults or requires looking them up. It’s much better to define your initial login user (email) and password explicitly. This is done using environment variables passed to the container.

Setting the Default Login Email and Password

The official dpage/pgadmin4 image uses specific environment variables to configure the initial administrative user:

PGADMIN_DEFAULT_EMAIL: Sets the email address (username) for the initial user account.
PGADMIN_DEFAULT_PASSWORD: Sets the password for this initial user account. Choose a strong, unique password.

We pass these using the -e or --env flag in the docker run command.

Understanding Port Mapping

We already used -p 8080:80. Let’s reiterate:

The format is -p HOST_PORT:CONTAINER_PORT.
CONTAINER_PORT for the default pgAdmin image is almost always 80 (HTTP).
HOST_PORT is the port you will use in your browser to access pgAdmin. Choose any available port on your host machine (e.g., 5050, 8888, 8080). Avoid ports already used by other services.

Putting It All Together: A Practical `docker run` Command

Combining persistence with named volumes and custom credentials, here is a robust docker run command for deploying pgAdmin:

“`bash

1. Define your desired credentials (use strong values!)

export MY_PGADMIN_EMAIL=”[email protected]”
export MY_PGADMIN_PASSWORD=”YourSecurePassword123!”

2. (Optional) Create the volume explicitly

docker volume create pgadmin-data

3. Run the container

docker run -d \
–name pgadmin-service \
-p 8080:80 \
-e PGADMIN_DEFAULT_EMAIL=”${MY_PGADMIN_EMAIL}” \
-e PGADMIN_DEFAULT_PASSWORD=”${MY_PGADMIN_PASSWORD}” \
-v pgadmin-data:/var/lib/pgadmin \
dpage/pgadmin4

Note: Using environment variables like ${MY_PGADMIN_EMAIL} is a good practice

to avoid embedding secrets directly in scripts or command history.

Make sure these variables are set in your current shell session before running.

Alternatively, you can hardcode them directly in the command (less secure):

# -e PGADMIN_DEFAULT_EMAIL=”[email protected]” \
# -e PGADMIN_DEFAULT_PASSWORD=”YourSecurePassword123!” \
“`

Explanation of this Recommended docker run command:

-d: Run detached (background).
--name pgadmin-service: Give the container a descriptive name.
-p 8080:80: Map host port 8080 to container port 80.
-e PGADMIN_DEFAULT_EMAIL=...: Set the initial login email.
-e PGADMIN_DEFAULT_PASSWORD=...: Set the initial login password. CRITICAL: Use a strong password.
-v pgadmin-data:/var/lib/pgadmin: Use the named volume pgadmin-data to persist configuration under /var/lib/pgadmin inside the container.
dpage/pgadmin4: Use the official pgAdmin 4 image.

With this command, you have a pgAdmin instance that:
1. Runs in the background.
2. Is accessible via http://localhost:8080.
3. Uses your specified email and password for login.
4. Persists all its configuration and server definitions in the pgadmin-data volume.

5. The Recommended Approach: Using Docker Compose

While the docker run command works perfectly well, it can become lengthy and harder to manage as configurations grow more complex (e.g., adding networks, dependencies, more volumes). Docker Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file (docker-compose.yml) to configure your application’s services, networks, and volumes.

Why Docker Compose?

Declarative Configuration: Define your entire pgAdmin setup (and potentially other related services like PostgreSQL itself) in a single, version-controllable YAML file.
Readability: YAML is generally easier to read and understand than long docker run commands.
Reproducibility: Easily recreate the exact same environment by simply running docker-compose up.
Simplified Management: Use simple commands like docker-compose up, docker-compose down, docker-compose logs, docker-compose pull to manage the entire stack defined in the file.
Networking: Compose automatically sets up a dedicated network for your application’s services, improving isolation.

Creating the `docker-compose.yml` File

Create a new directory for your pgAdmin deployment, for example, my-pgadmin-compose. Inside this directory, create a file named docker-compose.yml. Paste the following content into the file:

“`yaml
version: ‘3.8’ # Specify the Compose file version (use a recent one)

services:
pgadmin:
image: dpage/pgadmin4:latest # Use the official image, ‘:latest’ or specify a version like ‘:6.15’
container_name: pgadmin_container # Optional: Define a specific container name
environment:
PGADMIN_DEFAULT_EMAIL: [email protected] # CHANGE THIS
PGADMIN_DEFAULT_PASSWORD: YourSecurePassword123! # CHANGE THIS TO A STRONG PASSWORD
ports:
– “8080:80” # Map host port 8080 to container port 80
volumes:
– pgadmin_data:/var/lib/pgadmin # Mount the named volume for persistence
restart: unless-stopped # Optional: Restart policy (e.g., always restart if it crashes)

volumes:
pgadmin_data: # Define the named volume used by the service
name: pgadmin_app_data # Optional: Specify a custom name for the volume on the host
“`

Explanation of the docker-compose.yml file:

version: '3.8': Defines the version of the Docker Compose file syntax being used. Version 3.x is common.
services:: This is the main section where you define your application’s containers (services).
pgadmin:: This is the logical name of our service within Compose.
image: dpage/pgadmin4:latest: Specifies the Docker image to use. Using latest pulls the most recent stable version. For production, it’s often better to pin to a specific version tag (e.g., dpage/pgadmin4:7.8) for predictability.
container_name: pgadmin_container: Sets a specific name for the container created by this service. If omitted, Compose generates a name like my-pgadmin-compose_pgadmin_1.
environment:: Defines environment variables passed into the container.
- PGADMIN_DEFAULT_EMAIL: Your desired login email. Remember to change this.
- PGADMIN_DEFAULT_PASSWORD: Your desired login password. Remember to change this to something strong.
ports:: Defines port mappings.
- - "8080:80": Maps port 8080 on the host to port 80 in the container. The quotes are important in YAML.
volumes:: Defines volume mappings for the service.
- - pgadmin_data:/var/lib/pgadmin: Maps the named volume pgadmin_data (defined below) to /var/lib/pgadmin inside the container.
restart: unless-stopped: Optional but recommended policy. Tells Docker to restart the container automatically if it stops for any reason (e.g., crash), unless it was explicitly stopped by the user (docker stop or docker-compose down). Other options include no, on-failure, always.
volumes: (Top-level): This section defines the named volumes used by the services.
pgadmin_data:: Declares a named volume called pgadmin_data. Compose will manage this volume.
- name: pgadmin_app_data: Optionally gives the Docker volume on the host a specific name (pgadmin_app_data in this case). If omitted, Compose usually creates a volume named <project-directory-name>_pgadmin_data (e.g., my-pgadmin-compose_pgadmin_data).

Important Security Note: Avoid committing docker-compose.yml files with hardcoded passwords directly into version control (like Git) if the repository is public or shared. Use environment variable substitution or secrets management tools (like Docker Secrets or external configuration files) for sensitive data in production environments. For simple local setups, hardcoding might be acceptable, but be aware of the risk. A common practice is to use environment variables referenced in the Compose file:

“`yaml

Example using environment variables in docker-compose.yml

version: ‘3.8’

services:
pgadmin:
image: dpage/pgadmin4:latest
environment:
PGADMIN_DEFAULT_EMAIL: ${PGADMIN_EMAIL:[email protected]} # Uses env var PGADMIN_EMAIL, falls back to default
PGADMIN_DEFAULT_PASSWORD: ${PGADMIN_PASSWORD?Variable PGADMIN_PASSWORD is required} # Requires env var PGADMIN_PASSWORD to be set
ports:
– “${PGADMIN_PORT:-8080}:80” # Uses env var PGADMIN_PORT, falls back to 8080
volumes:
– pgadmin_data:/var/lib/pgadmin
restart: unless-stopped

volumes:
pgadmin_data:
name: pgadmin_app_data_compose
“`

You would then set the environment variables (PGADMIN_EMAIL, PGADMIN_PASSWORD, PGADMIN_PORT) in your shell before running docker-compose up, or use a .env file in the same directory.

Running pgAdmin with `docker-compose up`

Navigate your terminal to the directory containing your docker-compose.yml file (my-pgadmin-compose).
Run the command:

bash docker-compose up -d
- docker-compose up: Reads the docker-compose.yml file, creates/starts the defined services, networks, and volumes.
- -d: Runs the containers in detached mode (background). Without -d, logs will stream to your terminal, and Ctrl+C will stop the containers.

Docker Compose will:
* Pull the dpage/pgadmin4 image if needed.
* Create the pgadmin_data named volume (if it doesn’t exist).
* Create a default network for this Compose project.
* Create and start the pgadmin container according to the configuration.

You should see output indicating the network, volume, and container are being created or started.

Stopping and Removing with `docker-compose down`

To stop and remove the containers, networks, and (optionally) volumes defined in your docker-compose.yml:

Navigate to the directory containing the docker-compose.yml file.
Run:

bash docker-compose down

This command stops and removes the containers and the network created by docker-compose up.

Important: By default, docker-compose down does not remove named volumes defined in the volumes: top-level section. This is intentional to prevent accidental data loss. Your pgadmin_data volume will persist.

If you want to remove the named volumes along with the containers, use the -v flag:

bash docker-compose down -v

Use docker-compose down -v with caution, as it will delete the volume containing your pgAdmin configuration.

Managing the Container Lifecycle

Docker Compose provides other useful commands:

docker-compose ps: List the containers managed by the current Compose project.
docker-compose logs: View the logs from the service(s).
- docker-compose logs pgadmin: View logs specifically for the pgadmin service.
- docker-compose logs -f pgadmin: Follow log output in real-time.
docker-compose stop: Stop the services without removing them.
docker-compose start: Start previously stopped services.
docker-compose restart: Restart the services.
docker-compose pull: Pull the latest images for the services defined in the docker-compose.yml file (useful for upgrades).

Using Docker Compose is highly recommended for managing pgAdmin deployment due to its simplicity, clarity, and reproducibility, especially as your needs evolve.

6. Accessing and Using Your Dockerized pgAdmin

Once your pgAdmin container is running (either via docker run or docker-compose up), you need to access its web interface.

Finding Your Host IP Address or Using `localhost`

If Docker is running directly on your local machine (Linux, Docker Desktop on Mac/Windows): You can usually access it using localhost or 127.0.0.1.
If Docker is running inside a VM (e.g., older Docker Toolbox, custom Linux VM): You need the IP address of that VM.
If Docker is running on a remote server: You need the public or private IP address of that server.

The port is the host port you specified during mapping (e.g., 8080 in our examples).

So, the URL will typically be: http://localhost:8080 or http://<Your_Docker_Host_IP>:8080

Logging In

Open the URL in your web browser. You should see the pgAdmin login page.

Enter the credentials you configured:

Email/Username: The value you set for PGADMIN_DEFAULT_EMAIL.
Password: The value you set for PGADMIN_DEFAULT_PASSWORD.

Click “Login”.

Adding Your First PostgreSQL Server Connection

pgAdmin itself doesn’t include a database; it’s a tool to connect to existing PostgreSQL servers. The first thing you’ll likely want to do is add a connection.

On the Dashboard: Click on “Add New Server”.
General Tab:
- Name: Give your connection a descriptive name (e.g., “Local Dev DB”, “Production Read Replica”). This name is just for display within pgAdmin.
Connection Tab: This is the crucial part.
- Host name/address: The IP address or hostname of the machine where your PostgreSQL server is running.
  - If connecting to a PostgreSQL server running on your host machine from the pgAdmin container, you typically cannot use localhost or 127.0.0.1. These refer to the container itself. Instead, use the special hostname host.docker.internal (on Docker Desktop Mac/Windows) or find your host’s IP address on the Docker bridge network (often 172.17.0.1 on Linux, check with ip addr show docker0).
  - If connecting to another Docker container running PostgreSQL (e.g., in the same Docker Compose network), use the service name of the PostgreSQL container as the hostname (e.g., postgres if the service is named postgres in docker-compose.yml). Docker’s internal DNS will resolve it.
  - If connecting to a remote PostgreSQL server (cloud, different machine), use its public or private IP address or DNS hostname.
- Port: The port PostgreSQL is listening on (default is 5432).
- Maintenance database: Usually postgres (the default database created with PostgreSQL).
- Username: The PostgreSQL user you want to connect as (e.g., postgres or a specific application user).
- Password: The password for that PostgreSQL user. pgAdmin securely stores this password (encrypted) within its configuration database (which is why persisting the volume is vital). You can choose to save the password or be prompted each time.
Other Tabs (Optional): Explore SSL, SSH Tunnel, Advanced settings if needed for your specific connection requirements (e.g., requiring SSL, connecting through a bastion host).
Save: Click the “Save” button.

If the connection details are correct and the pgAdmin container can reach the PostgreSQL server (check network connectivity and firewalls), the server will appear in the browser tree on the left-hand side.

Navigating the Interface (Brief Overview)

Once connected, you can explore your PostgreSQL server:

Browser Tree (Left Panel): Navigate through Databases, Login/Group Roles, Tablespaces, and individual database objects (Schemas, Tables, Views, Functions, etc.).
Query Tool (Top Menu > Tools > Query Tool): Open an SQL editor to write and execute queries against the selected database.
Object Properties (Right Panel): View and edit properties of selected objects (e.g., table columns, constraints, user permissions).
Dashboard: Provides overview statistics and graphs for the selected server or database.

Explore the menus and right-click options on objects in the browser tree to discover the vast array of management features pgAdmin offers.

7. Advanced Configuration and Best Practices

While the basic Docker Compose setup is functional, several areas deserve attention for improved robustness, security, and maintainability.

Persistence Deep Dive

Named Volumes vs. Bind Mounts: Pros and Cons
- Named Volumes (Recommended):
  - Pros: Managed by Docker, platform-agnostic paths, easier backups/migration, better performance (on some platforms), avoids host permission issues.
  - Cons: Data location on the host is managed by Docker (less direct access, though inspectable).
- Bind Mounts:
  - Pros: Direct access to data on the host filesystem, familiar paths.
  - Cons: Potential permission problems (UID/GID mismatches between host and container), host path dependency (less portable), potential performance issues (especially on Mac/Windows due to filesystem translation).
- When to use Bind Mounts for pgAdmin? Perhaps for injecting custom configuration files (like config_local.py, see later) or if direct host access is a strict requirement and you understand how to manage permissions. For the primary /var/lib/pgadmin data, named volumes are generally superior.
Locating Volume Data on the Host
- You can find where Docker stores a named volume using docker volume inspect:
  “`bash
  # For the volume ‘pgadmin_data’ created by docker run
  docker volume inspect pgadmin-data
  
  For the volume ‘pgadmin_app_data_compose’ created by docker-compose
  
  docker volume inspect pgadmin_app_data_compose
  `` * Look for the“Mountpoint”field in the JSON output. This shows the path on the host machine where the volume data resides (e.g.,/var/lib/docker/volumes/pgadmin_app_data_compose/_data`). You typically need root/administrator privileges to browse this directory.
Backup Strategies for pgAdmin Data
- Since all your crucial pgAdmin configuration (server definitions, user settings) lives in the persistent volume, backing it up is important.
- Method 1: Backup the Volume Directory:
  1. Stop the pgAdmin container (docker stop pgadmin-service or docker-compose down). This ensures data consistency.
  2. Find the volume’s Mountpoint using docker volume inspect <volume_name>.
  3. Use standard backup tools (tar, rsync, graphical tools) to copy the entire contents of the Mountpoint directory to your backup location. Remember to preserve permissions if possible (e.g., using tar -p).
  4. Restart the pgAdmin container.
- Method 2: Using a Temporary Container:
  1. Keep the pgAdmin container running.
  2. Run a temporary container (e.g., based on alpine or ubuntu) that mounts the same pgAdmin data volume and also mounts a host directory for the backup target.
    “`bash
  Example: Backup ‘pgadmin_app_data_compose’ volume to the host’s current directory
  
  docker run –rm \
  -v pgadmin_app_data_compose:/pgadmin-data \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/pgadmin-backup-$(date +%Y%m%d).tar.gz -C /pgadmin-data .
  `` This command: * Runs a temporary Alpine Linux container (–rm). * Mounts thepgadmin_app_data_composevolume to/pgadmin-datainside the container. * Mounts the current host directory ($(pwd)) to/backupinside the container. * Runstarto create a compressed archive (.tar.gz) of the contents of/pgadmin-data(the volume) and saves it to the/backup` directory (which is the host directory).
  * The container exits and is removed.
- Restoring: To restore, stop pgAdmin, clear the volume’s contents (or delete/recreate the volume), and extract your backup archive into the volume’s Mountpoint (Method 1) or use a similar temporary container with tar xzf ... (Method 2).

Security Considerations

Running any web-accessible service requires careful security attention.

Strong Credentials (Mandatory!)
- The PGADMIN_DEFAULT_PASSWORD must be strong and unique. Avoid common or easily guessable passwords.
- Consider using a password manager to generate and store complex passwords.
Running as a Non-Root User (Image Default)
- The official dpage/pgadmin4 image is well-designed and runs the pgAdmin process as a dedicated, non-root user (pgadmin). This is a crucial security best practice, limiting the potential damage if the application itself were compromised. Do not override this unless you have a very specific, understood reason.
Securing Network Access (Firewalls, VPNs)
- Do not expose the pgAdmin port (e.g., 8080) directly to the public internet unless absolutely necessary and secured with HTTPS and strong authentication/authorization.
- Best Practice: Keep pgAdmin accessible only within a private network (e.g., your local machine, a company VPN, a private cloud network).
- Use host firewalls (like ufw on Ubuntu, firewalld on CentOS, Windows Firewall) to restrict access to the pgAdmin port (the host port, e.g., 8080) only from trusted IP addresses or networks.
- If remote access is needed, consider placing it behind a VPN or using SSH tunneling.
HTTPS/SSL Encryption (Crucial!)
- Why Plain HTTP is Risky: By default, our setup uses plain HTTP. This means your login credentials (email, password) and potentially sensitive database credentials (when adding servers) are transmitted unencrypted over the network. Anyone eavesdropping on the network (e.g., on public Wi-Fi, or even within a compromised corporate network) could potentially intercept them. Database query results are also sent unencrypted.
- Using a Reverse Proxy (Recommended): The standard way to add HTTPS to web applications running in Docker (including pgAdmin) is to use a reverse proxy. The reverse proxy handles the HTTPS termination (decrypting incoming requests, encrypting outgoing responses) and forwards plain HTTP traffic to the pgAdmin container on the internal Docker network. Popular reverse proxies suitable for Docker include:
  - Nginx: A powerful, widely used web server and reverse proxy.
  - Traefik: A cloud-native edge router designed with Docker integration in mind (can automatically detect containers and configure routing/SSL).
  - Caddy: A modern web server known for its automatic HTTPS configuration using Let’s Encrypt.
  - Nginx Proxy Manager: A user-friendly Docker image that provides a web UI for managing Nginx reverse proxy configurations, including SSL certificate generation (Let’s Encrypt) and access lists.
- Example Concept with Nginx Proxy Manager (NPM):
  1. Set up Nginx Proxy Manager (NPM) as another Docker container (using its own Docker Compose file is common). Expose ports 80 and 443 from NPM to the host.
  2. Modify your pgAdmin docker-compose.yml:
    - Do not map the pgAdmin port (8080:80) to the host anymore. It only needs to be accessible within the Docker network.
    - Ensure both NPM and pgAdmin are on the same custom Docker network (defined in both Compose files or using networks: default: external: name: my_shared_network).
  3. In the NPM web UI:
    - Add a new Proxy Host.
    - Set the Domain Name (e.g., pgadmin.yourdomain.com).
    - Set the Scheme to http.
    - Set the Forward Hostname / IP to the pgAdmin container’s service name (e.g., pgadmin as defined in its docker-compose.yml).
    - Set the Forward Port to 80 (the port pgAdmin listens on inside its container).
    - Go to the SSL tab, request a new Let’s Encrypt certificate for your domain, and enable “Force SSL”.
  4. Ensure your DNS for pgadmin.yourdomain.com points to the public IP address of the machine running the Nginx Proxy Manager container.
  5. Now, access pgAdmin securely via https://pgadmin.yourdomain.com. NPM handles the SSL, and traffic between NPM and pgAdmin happens over the internal Docker network.
- Self-Signed Certificates (Development Only): For local development where Let’s Encrypt isn’t feasible, you could generate self-signed certificates and configure pgAdmin or a reverse proxy to use them. However, browsers will show security warnings, and this is not suitable for production or shared environments.
Docker Network Isolation
- When using Docker Compose, it automatically creates a dedicated bridge network for the services defined in the docker-compose.yml file. Containers on this network can communicate with each other using their service names, but are isolated from containers in other Compose projects or the default Docker bridge network unless explicitly configured otherwise. This provides a good level of network segmentation.
- Avoid using the --network host mode for pgAdmin unless absolutely necessary, as it bypasses Docker’s network isolation, making the container listen directly on the host’s network interfaces.
Regular Updates
- Keep both Docker and the pgAdmin image (dpage/pgadmin4) updated to benefit from the latest features, bug fixes, and crucially, security patches. See the “Upgrading pgAdmin” section below.

Networking Nuances

Handling Port Conflicts: If the host port you choose (e.g., 8080) is already in use by another application on your host machine, the docker run or docker-compose up command will fail with a “port is already allocated” error. Simply choose a different, unused host port (e.g., -p 5051:80 or ports: - "5051:80").
Understanding Docker Networks:
- Bridge (Default): When you run a container without specifying a network, it usually attaches to the default bridge network. Containers on this network can communicate with each other via IP address, but DNS resolution by container name might not work reliably without manual linking (an older, less preferred method). Compose creates its own custom bridge networks.
- Host: Container shares the host’s network stack. No port mapping needed, but loses isolation.
- Custom Bridge Networks: Created by Docker Compose or manually (docker network create). Provide better isolation and reliable service discovery via DNS (containers can reach each other using their service names). This is the standard for Compose applications.

Resource Management

Limiting CPU and Memory (Optional): While pgAdmin is generally not resource-intensive, you can limit the CPU and memory resources a container can consume. This can be useful in shared environments or to prevent a runaway process from impacting the host.
- docker run: Use flags like --cpus="0.5" (limit to 50% of one CPU core) and --memory="512m" (limit to 512 MB RAM).
- Docker Compose: Use the deploy key (requires a slightly newer Compose version and might behave differently depending on whether you’re using Swarm mode, but often works for single-node deployments too):
“`yaml

docker-compose.yml example with resource limits

version: ‘3.8’

services:
pgadmin:
image: dpage/pgadmin4:latest
environment:
# … credentials …
ports:
– “8080:80”
volumes:
– pgadmin_data:/var/lib/pgadmin
restart: unless-stopped
deploy:
resources:
limits:
cpus: ‘0.75’
memory: 1G
reservations: # Optional: Guarantee minimum resources
cpus: ‘0.25’
memory: 256M

volumes:
pgadmin_data:
name: pgadmin_app_data_limited
“`

Upgrading pgAdmin

Keeping pgAdmin updated is important. Docker makes this relatively straightforward.

The Upgrade Process with docker run:
1. Stop and Remove the Existing Container: Make sure you used a named volume for persistence!
  bash docker stop pgadmin-service docker rm pgadmin-service
2. Pull the Latest (or Specific) Image:
  bash docker pull dpage/pgadmin4:latest # Or pull a specific newer version: # docker pull dpage/pgadmin4:8.0
3. Run the Container Again with the Same Parameters: Use the exact same docker run command you used initially, ensuring you map the same volume (-v pgadmin-data:/var/lib/pgadmin) and use the same environment variables and port mappings.
  bash # Re-run the command from section 4, ensuring the image pulled is the new one docker run -d \ --name pgadmin-service \ -p 8080:80 \ -e PGADMIN_DEFAULT_EMAIL="${MY_PGADMIN_EMAIL}" \ -e PGADMIN_DEFAULT_PASSWORD="${MY_PGADMIN_PASSWORD}" \ -v pgadmin-data:/var/lib/pgadmin \ dpage/pgadmin4:latest # Or the specific version tag
  The new container will start using the updated image code but will attach to your existing pgadmin-data volume, preserving your configurations and server connections. pgAdmin usually handles any internal database schema migrations automatically on startup.
The Upgrade Process with Docker Compose: This is generally simpler.
1. Navigate to your docker-compose.yml directory.
2. (Optional but Recommended) Update the Image Tag: Edit your docker-compose.yml file to specify the new version tag if you want a specific version (e.g., change image: dpage/pgadmin4:7.8 to image: dpage/pgadmin4:8.0). If you use latest, you skip this step but rely on pulling the newest image in the next step. Pinning versions is safer for production.
3. Pull the New Image:
  bash docker-compose pull pgadmin # Pulls the image specified for the 'pgadmin' service
4. Recreate the Service:
  bash docker-compose up -d --no-deps pgadmin
  - docker-compose up -d: Tells Compose to bring the stack up, ensuring services match the docker-compose.yml definition.
  - --no-deps: Prevents Compose from restarting other unrelated services defined in the same file (if any).
  - pgadmin: Specifies that we only want to update/recreate the pgadmin service.
    Compose will detect that the image for pgadmin has changed (or is latest and was just pulled), stop the old container, create a new one using the new image, and attach it to the existing pgadmin_data volume.
Always check the pgAdmin release notes for any specific upgrade instructions or potential breaking changes between versions.

Custom pgAdmin Configuration (`config_local.py`)

For more advanced tuning beyond environment variables, pgAdmin supports a config_local.py file. You can create this file on your host and mount it into the container at /pgadmin4/config_local.py. This allows you to override many default settings found in the main config.py.

Example: Disabling the “Getting Started” video splash screen.

Create a file named my_config_local.py on your host with the content:
python SHOW_GRAVATAR_IMAGE = False # Add other config overrides here as needed # Refer to pgAdmin's config.py for available options
Modify your docker run or docker-compose.yml to mount this file:
- docker run: Add another -v flag (use an absolute path for the host file):
  bash docker run -d \ # ... other options ... -v /path/to/your/my_config_local.py:/pgadmin4/config_local.py \ -v pgadmin-data:/var/lib/pgadmin \ dpage/pgadmin4
- docker-compose.yml: Add the file mount under volumes:
  yaml services: pgadmin: # ... other definitions ... volumes: - pgadmin_data:/var/lib/pgadmin - ./my_config_local.py:/pgadmin4/config_local.py # Mount local file # ... rest of file ...
  (Ensure my_config_local.py is in the same directory as docker-compose.yml or adjust the host path accordingly).

Restart the container for the changes to take effect.

8. Troubleshooting Common Issues

Even with simple deployments, you might encounter issues. Here’s how to diagnose common problems:

Container Fails to Start:
- Check Logs: The first step is always to check the container logs.
  - docker logs <container_name_or_id> (e.g., docker logs pgadmin-service)
  - docker-compose logs pgadmin
- Look for error messages. Common startup errors include incorrect environment variable formats, volume permission issues (less common with named volumes), or problems internal to pgAdmin initialization.
- Port Conflicts: Check if the host port is already in use (see logs or try ss -tulnp | grep <host_port> on Linux, netstat -ano | findstr <host_port> on Windows). Change the host port mapping if needed.
Cannot Access pgAdmin Web Interface (e.g., “This site can’t be reached”):
- Container Running? Check docker ps or docker-compose ps to ensure the container is actually running. If not, check logs (see above).
- Correct URL? Double-check you are using the correct IP address (localhost, host.docker.internal, host IP) and the correct host port (the first part of the -p mapping, e.g., 8080).
- Firewall? Ensure no host firewall is blocking incoming connections on the host port you mapped.
- Reverse Proxy Issues? If using a reverse proxy (Nginx, Traefik), check its logs and configuration. Ensure the proxy can reach the pgAdmin container over the Docker network.
- Docker Networking: Use docker inspect <container_name_or_id> and look at the NetworkSettings to verify IP address and port mappings.
Login Failed:
- Correct Credentials? Verify you are using the exact email and password set via PGADMIN_DEFAULT_EMAIL and PGADMIN_DEFAULT_PASSWORD. Passwords are case-sensitive.
- Caps Lock? Check if Caps Lock is accidentally enabled.
- Did Persistence Work? If you previously logged in successfully but now can’t, ensure your volume mapping is correct and the volume wasn’t accidentally deleted (docker volume ls). If the volume was lost, the default credentials might have been reset when the container was recreated.
Configuration Not Persisted (Server definitions disappear after restart):
- Volume Mapped Correctly? Double-check your -v flag or volumes: section in Compose. Ensure the volume (named or bind mount) is mapped to the correct internal path: /var/lib/pgadmin.
- Volume Deleted? Verify the volume still exists (docker volume ls). If using docker-compose down -v, you explicitly deleted the volume. Use docker-compose down without -v to preserve volumes.
- Permissions (Bind Mounts)? If using a bind mount, ensure the pgadmin user inside the container (UID/GID typically 5050) has write permissions to the host directory you mounted. Use chown 5050:5050 /path/on/host or adjust permissions carefully. Named volumes generally avoid this.
Connection Errors to PostgreSQL Server:
- Network Path: Can the pgAdmin container reach the PostgreSQL server’s host and port?
  - From container to host: Use host.docker.internal or host IP on Docker bridge.
  - From container to container (same network): Use the other container’s service name.
  - From container to remote: Ensure container has outbound network access and the remote server/firewall allows connections from the Docker host’s IP.
- PostgreSQL Listening? Is PostgreSQL actually running and listening on the expected address/port? Check PostgreSQL logs.
- PostgreSQL pg_hba.conf: Does the PostgreSQL server’s pg_hba.conf file allow connections from the pgAdmin container’s source IP address (or the Docker host’s IP) for the specified user and database? You might need to add a rule like host all my_pg_user 172.17.0.0/16 md5 (adjust IP range and method). Remember to reload PostgreSQL config after changes.
- Credentials: Double-check the PostgreSQL username and password entered in the pgAdmin server connection dialog.
Checking Container Logs (docker logs)
- This is your primary diagnostic tool. Always check logs first.
- docker logs pgadmin-service
- docker logs -f pgadmin-service (follow logs)
- docker logs --tail 50 pgadmin-service (show last 50 lines)
- docker-compose logs pgadmin
- docker-compose logs -f pgadmin
Inspecting Container Details (docker inspect)
- Provides detailed JSON information about the container’s configuration, network settings, volumes, environment variables, etc.
- docker inspect pgadmin-service
- docker inspect pgadmin_container (if using container_name in Compose)

9. Alternative Scenarios

Running pgAdmin and PostgreSQL Together (Docker Compose)
- It’s very common to run both PostgreSQL and pgAdmin in the same Docker Compose project, especially for development.
“`yaml

docker-compose.yml (PostgreSQL + pgAdmin)

version: ‘3.8’

services:
postgres_db:
image: postgres:15 # Use an official Postgres image version
container_name: postgres_db_container
environment:
POSTGRES_DB: myappdb
POSTGRES_USER: myappuser
POSTGRES_PASSWORD: StrongDbPassword! # CHANGE THIS
volumes:
– postgres_data:/var/lib/postgresql/data # Persist Postgres data
ports:
– “5432:5432” # Optional: Expose Postgres port to host if needed
restart: unless-stopped

pgadmin:
image: dpage/pgadmin4:latest
container_name: pgadmin_container
environment:
PGADMIN_DEFAULT_EMAIL: [email protected] # CHANGE THIS
PGADMIN_DEFAULT_PASSWORD: StrongPgAdminPassword! # CHANGE THIS
ports:
– “8080:80”
volumes:
– pgadmin_data:/var/lib/pgadmin
depends_on: # Ensure Postgres starts before pgAdmin (optional, but good practice)
– postgres_db
restart: unless-stopped

volumes:
postgres_data:
name: myapp_postgres_data
pgadmin_data:
name: myapp_pgadmin_data
“`
- Key Points:
  - Two services defined: postgres_db and pgadmin.
  - Separate named volumes for PostgreSQL data (postgres_data) and pgAdmin config (pgadmin_data).
  - depends_on: - postgres_db tells Compose to start the postgres_db service before starting pgadmin.
  - Connecting pgAdmin: When adding the server connection in pgAdmin, use the service name postgres_db as the Host name/address. Use port 5432, database myappdb, user myappuser, and the StrongDbPassword!. Docker Compose’s internal networking allows the pgadmin container to resolve and connect to postgres_db by its service name.
Using Specific pgAdmin Versions (Image Tags)
- The dpage/pgadmin4 image on Docker Hub has various tags corresponding to specific pgAdmin releases (e.g., 8.0, 7.8, 6.21).
- Instead of image: dpage/pgadmin4:latest, specify a version:
  yaml # In docker-compose.yml services: pgadmin: image: dpage/pgadmin4:7.8 # ... rest ...
  bash # With docker run docker run -d ... dpage/pgadmin4:7.8
- Using specific version tags is highly recommended for production and even development to ensure predictable behavior and avoid unexpected breaking changes introduced by a latest tag update. You control exactly when you upgrade by changing the tag and redeploying.

10. Conclusion: Embracing Containerized Database Management

Deploying pgAdmin with Docker transforms a potentially tedious setup process into a streamlined, reproducible, and isolated operation. By leveraging containerization, you gain consistency across environments, simplified dependency management, and easy version control.

We’ve journeyed from the simplest ephemeral docker run command to a robust, persistent, and configurable setup using Docker Compose – the recommended approach for most use cases. We emphasized the critical importance of:

Persistence: Using named volumes (-v volume:/path or the volumes: section in Compose) to save your vital server connections and settings across container restarts.
Security: Setting strong initial credentials (PGADMIN_DEFAULT_EMAIL, PGADMIN_DEFAULT_PASSWORD), securing network access, and crucially, implementing HTTPS (typically via a reverse proxy) to protect sensitive data in transit.
Configuration: Using environment variables and Docker Compose for clear, manageable, and reproducible deployments.

Whether you’re a developer managing local databases, a DBA overseeing multiple PostgreSQL instances, or part of a team needing a shared database administration tool, Docker provides an elegant and efficient way to run pgAdmin. The techniques learned here – volumes, port mapping, environment variables, Compose files, reverse proxies – are fundamental Docker concepts applicable to containerizing countless other applications.

By adopting Docker for your pgAdmin deployment, you take a significant step towards modern, efficient, and manageable database administration workflows. Happy querying!

The Ultimate Guide to Simple pgAdmin Deployment with Docker

Table of Contents

1. Prerequisites: Getting Your Environment Ready

Installing Docker

For Docker Desktop, ensure the Docker engine is running (usually indicated by a whale icon in the system tray/menu bar).

For Linux, check the service status:

Log out and log back in for the group change to take effect.

Basic Docker Concepts Refresher

2. The Simplest Deployment: Quick & Ephemeral (docker run)

Understanding the Core Command

Accessing Your Ephemeral Instance

The Major Downside: Lack of Persistence

3. Adding Persistence: Saving Your Configuration (docker run with Volumes)

Why Persistence Matters for pgAdmin

Introducing Docker Volumes

Using Named Volumes (Recommended)

You can optionally create the volume beforehand, though docker run will create it if it doesn’t exist.

Now run the container, mounting the named volume:

You should see ‘pgadmin-data’ listed.

Using Bind Mounts (Alternative)

Create a directory on your host first

Run the container using the bind mount

4. Configuring Credentials and Ports (docker run)

Setting the Default Login Email and Password

Understanding Port Mapping

Putting It All Together: A Practical docker run Command

1. Define your desired credentials (use strong values!)

2. (Optional) Create the volume explicitly

3. Run the container

Note: Using environment variables like ${MY_PGADMIN_EMAIL} is a good practice

to avoid embedding secrets directly in scripts or command history.

Make sure these variables are set in your current shell session before running.

Alternatively, you can hardcode them directly in the command (less secure):

5. The Recommended Approach: Using Docker Compose

Why Docker Compose?

Creating the docker-compose.yml File

Example using environment variables in docker-compose.yml

Running pgAdmin with docker-compose up

Stopping and Removing with docker-compose down

Managing the Container Lifecycle

6. Accessing and Using Your Dockerized pgAdmin

Finding Your Host IP Address or Using localhost

Logging In

Adding Your First PostgreSQL Server Connection

Navigating the Interface (Brief Overview)

7. Advanced Configuration and Best Practices

Persistence Deep Dive

For the volume ‘pgadmin_app_data_compose’ created by docker-compose

Example: Backup ‘pgadmin_app_data_compose’ volume to the host’s current directory

Security Considerations

Networking Nuances

Resource Management

docker-compose.yml example with resource limits

Upgrading pgAdmin

Custom pgAdmin Configuration (config_local.py)

8. Troubleshooting Common Issues

9. Alternative Scenarios

docker-compose.yml (PostgreSQL + pgAdmin)

10. Conclusion: Embracing Containerized Database Management

Leave a Comment Cancel Reply

2. The Simplest Deployment: Quick & Ephemeral (`docker run`)

3. Adding Persistence: Saving Your Configuration (`docker run` with Volumes)

You can optionally create the volume beforehand, though `docker run` will create it if it doesn’t exist.

4. Configuring Credentials and Ports (`docker run`)

Putting It All Together: A Practical `docker run` Command

Creating the `docker-compose.yml` File

Running pgAdmin with `docker-compose up`

Stopping and Removing with `docker-compose down`

Finding Your Host IP Address or Using `localhost`

Custom pgAdmin Configuration (`config_local.py`)