A PostgreSQL connection pooler sits directly between your applications and the database. That makes the pooler's network boundary part of your database security model: clients authenticate to it, credentials pass through it, and every database connection depends on it.

pgAgroal 1.4.5 strengthens that boundary in two important ways: TLS for client connections and strict validation of HBA source configuration.

The release is now available on Docker Hub and GHCR.

TLS between PostgreSQL clients and pgAgroal

pgAgroal 1.4.5 adds frontend TLS to the Elevarq container.

PostgreSQL clients can now establish an encrypted connection to pgAgroal instead of sending traffic over an unencrypted client-to-pooler connection.

You can configure TLS through environment variables or the Helm chart, making the same configuration available for Docker and Kubernetes deployments.

For Kubernetes, TLS configuration is exposed through the chart:

tls:
  enabled: true
  existingSecret: pgagroal-tls

The referenced Secret contains the certificate and private key used by pgAgroal.

The implementation is deliberately fail-closed. If TLS is enabled but the required certificate material is missing or invalid, the container does not silently fall back to an unencrypted configuration.

Optional mutual TLS

Encryption protects traffic in transit, but some environments also need the client itself to present a trusted certificate.

pgAgroal 1.4.5 therefore supports optional mutual TLS.

tls:
  enabled: true
  existingSecret: pgagroal-tls
  mutualTLS: true

With mutual TLS enabled, pgAgroal validates client certificates against the configured CA.

This gives operators another authentication boundary in front of PostgreSQL, particularly useful in Kubernetes and other environments where applications, services, and databases communicate across shared networks.

Closing an HBA configuration injection path

1.4.5 also fixes a security issue in the way PGAGROAL_HBA_SOURCE was used to generate pgAgroal's HBA configuration.

The source value is configuration input, but it ultimately becomes part of an authentication rule. That means treating it as arbitrary text is dangerous.

A specially crafted value could previously alter the structure of the generated rule and potentially change the intended authentication method from scram-sha-256 to trust.

That is no longer possible.

pgAgroal 1.4.5 strictly validates PGAGROAL_HBA_SOURCE before generating the HBA configuration. Invalid values are rejected rather than written into an authentication rule.

The important invariant is simple:

configuration may select where a connection is allowed from; it must never be able to rewrite how that connection is authenticated.

This is also a useful reminder that configuration boundaries deserve the same scrutiny as application input. An environment variable may look harmless, but once its value is used to construct security-sensitive configuration, it becomes part of the attack surface.

What about TLS from pgAgroal to PostgreSQL?

Frontend TLS protects the connection from the PostgreSQL client to pgAgroal.

The other half of the path is:

PostgreSQL client → pgAgroal → PostgreSQL

Backend TLS support in upstream pgAgroal 2.1.0 remains experimental and currently disables connection pooling. Enabling it in the Elevarq image would therefore undermine the primary reason for running pgAgroal in the first place.

For that reason, 1.4.5 does not pretend to provide a production-ready solution where upstream pgAgroal does not yet provide one.

We will continue tracking upstream backend TLS support as it matures.

Built for containerized deployments

The 1.4.5 release continues the production and supply-chain properties of the Elevarq pgAgroal distribution:

Multi-architecture images for linux/amd64 and linux/arm64
Non-root execution
Read-only root filesystem support
Linux capabilities dropped
Keyless Cosign signing through GitHub OIDC
SBOM attestations
SLSA provenance attestations
Helm deployment for Kubernetes

These aren't separate from database security. A pooler is infrastructure that holds database credentials and accepts application connections, so how you build, configure, deploy, and verify the container matters.

Available now

Elevarq pgAgroal 1.4.5 is now available on Docker Hub and GHCR.

For production deployments, pin the version—or preferably the published image digest—rather than relying on latest.

The complete release notes include configuration examples, image digests, and verification instructions.

pgAgroal remains open source. The Elevarq distribution makes it straightforward to deploy pgAgroal with hardened defaults, reproducible artifacts, Kubernetes support, and a verifiable software supply chain.

Preview

pgAgroal 1.4.5: Frontend TLS and Stricter HBA Security

A connection pooler is part of your database security boundary.

pgAgroal 1.4.5 adds TLS for PostgreSQL client connections, optional mutual TLS, and strict HBA source validation, closing a configuration-injection path that could weaken authentication.

The release also continues our hardened container approach with multi-arch images, non-root execution, Cosign signatures, SBOMs, SLSA provenance, and Helm support.

Available now on Docker Hub and GHCR.

https://hub.docker.com/r/elevarq/pgagroal https://github.com/Elevarq/pgAgroal