PostgreSQL is an open-source relational database management system valued for its power, standards-compliance, and extensibility.  Whether you’re building a microservice, spinning up test environments, or maintaining a dev copy of production, it’s often easier and cleaner to run Postgres in a container than to install it locally.

Running Postgres in Docker is great for a quick test but what if you want it to behave like a proper, production-style setup with SSL encryption, certificate-based authentication, persistent volumes, and custom configurations? In this article, we’ll find out how, tackling the various tasks involved such as:

We’ll do all of this with security-conscious file ownership and permission control. By the end, you’ll have a containerized PostgreSQL instance that behaves more like a hardened server than a throwaway development toy.

Why Secure Your Dockerized PostgreSQL?

If you’re just experimenting, the default Docker Postgres image is fine. But when you’re developing an application that will later use a properly secured production database, it’s worth aligning your local environment now, because:

It also makes your setup portable — anyone else on your team can run the same containerized environment and be sure it behaves the same way.

Prerequisites for a Secure Setup

To get started, you’ll need:

Step 1: Set Up SSL/TLS for Encrypted Connections

PostgreSQL supports SSL, but it doesn’t come enabled in the default Docker image. You’ll need to create the necessary certificate and key files first – it’s not difficult, just a few OpenSSL commands – and then configure the container to use them.

We’ll start by generating self-signed certificates using OpenSSL. Later, you could replace them with ones from a trusted certificate authority like Let’s Encrypt if you plan to expose your database to the outside world.

Create Your Certificate Authority (CA)

This creates an RSA private key via the OpenSSL command-line tool. It sets the key length to 4096 and saves the resulting private key in ca-key.pem.

Create Server Certificate

This is what the PostgreSQL container will present to clients when they connect:

This creates a self-signed CA using its private key (ca-key.pem). Its validity is set to 365 days and saved in ca-cert.pem. It also:

If you omit the -subj flag, OpenSSL will ask you to provide the metadata for your CA. It’s usually very convenient to provide them upfront with the -subj flag.

Create Client Certificate

This certificate will be used by a trusted client (such as a web app or a CI process) to authenticate.

Set File Permissions

Make sure these certificates are usable by Postgres, but not world-readable.

Step 2: Configuring PostgreSQL for SSL and Authentication

We now have all the certificates we need, but PostgreSQL won’t use them unless we tell it to — via configuration files. We’ll create two key files:

These will be mounted into the container at runtime, so Postgres picks them up on launch.

Create the Config Directory

Create pg_hba.conf

This file tells PostgreSQL which users can connect, from where, using which authentication method.

What’s going on here?

It’s a common and practical split: strong certificate-based auth for automated systems (they won’t forget a cert), and simpler password auth for developers.

Create postgresql.conf

This is PostgreSQL’s main configuration file. We’ll use it to enable SSL and point to the right files.

Why set listen_addresses = ‘*’?

This allows connections from any IP, which is useful in development or if other containers will connect via a custom location – /pgdata instead of the container’s default locationDocker network. In production, you’d narrow this.

Fix Permissions

PostgreSQL runs inside the container as UID 999, so it must own the config files. Otherwise, you’ll likely run into permissions errors that stop the container from starting or accepting connection:

Step 3: Prepare the Data Directory

Postgres needs a place to store databases, tables, logs, and so on – without it, Postgres will simply not operate. By default, it uses /var/lib/postgresql/data, but we’re going to use a custom path and mount it as a Docker container, which will look for or initialize all its data under the /pgdata directory inside the container. For your PostgreSQL container to use the custom /pgdata directory, you need to create the directory (on your host machine) and ensure that only the postgres user inside the PostgreSQL container has access to the /pgata directoryvolume.

Step 4: Launch the Postgres UserContainer

With certificates, configs, and data directory in place, it’s time to spin up the container.

Add Yourself to the Docker Group (Optional)

So you can run Docker without sudo:

Create a Docker Network

This allows Postgres to be easily connected to other containers (like an app or pgAdmin):

Start the PostgreSQL Container

This starts the container (with the name postgres) in detached mode. It also:

Verify It’s Running

You should see something like this:

Step 5: Creating Database Users

Now that our PostgreSQL container is up, we need to create the database users that will match our authentication setup. We will Create `pguser` for cert-based service access and `john` for human password-based access.

First, open a shell inside the container:

Open the PostgreSQL client:

Create two users — one for automated service-to-service connections (pguser, matching the CN in the client certificate), and one for general development (john):

Exit psql and the container shell:

Step 6: Testing SSL Connections

Let’s confirm that pguser can connect using its certificate and that john can connect using a password over SSL.

From the host machine, run:

You should see something like:

Notice that no password was requested — the client certificate handled authentication.

Test a Password-Based User

If you connect as john, the container will fall back to password authentication, but still require SSL:

You’ll be prompted for john123 (or whatever password you set).

Step 7: Switching to Let’s Encrypt (For Real-World Deployments)

Our self-signed certificates are fine for development, but production should use trusted certificates from a CA like Let’s Encrypt. We’ll end by showing how you’d swap to Let’s Encrypt in production.

The workflow is very similar:

If you’re running Postgres behind a reverse proxy or load balancer, you can often terminate SSL at that layer and connect to Postgres over a secure network, simplifying the setup.

Conclusion

If you’ve followed this workflow, you should now have a containerized PostgreSQL instance with:

You’ve just built something much closer to a real-world PostgreSQL setup — SSL, cert-based auth, persistent data — but still with all the convenience of Docker. Not bad for a few shell commands. It’s portable, reproducible, and secure enough to mirror a real-world environment, making your database development and testing much more relevant and meaningful.