Fix 'no pg_hba.conf entry for host'
The short version: Postgres refused your connection before the password - the host-based auth rules (pg_hba.conf) had no match for how you connected. Two causes cover almost every case: the server requires SSL and you connected without it (add ?sslmode=require), or your client’s IP is not allowed (add it to the managed database’s allowlist, or to pg_hba.conf on a self-hosted server). It is not a wrong-password problem.
It fails before the password
Postgres checks host-based auth (pg_hba.conf) first: is a connection from this address, for this user and database, with this method, even allowed? Only if a rule matches does it move on to the password. This error means no rule matched - so the fix is about how and from where you connect, not your credentials.
# the most common fix - the server wants SSL and you did not offer it:
DATABASE_URL=postgres://user:pass@host:5432/db?sslmode=require
# node-postgres equivalent:
new Pool({ connectionString, ssl: { rejectUnauthorized: false } })The two causes
SSL required, none offered
RDS, Supabase, Neon and most managed Postgres reject plaintext connections. Add sslmode=require to the connection string.
Your IP is not allowed
The connecting address is not in the allowlist (managed) or pg_hba.conf (self-hosted). Add the production egress IP.
Where to make the change
On a managed database you do not edit pg_hba.conf directly - you add sslmode=require on the client side and allowlist the IP in the provider console. On a self-hosted Postgres you edit pg_hba.conf to add a scoped rule (host, db, user, address, method) and reload. Either way, the principle is the same: the database is enforcing a front-door policy, and the fix is to satisfy it deliberately - not to widen it to everything.
Get the connection string right with the DATABASE_URL builder (it sets sslmode for you). If the password really is wrong, that is a different error.
Database access, scoped and recorded
A host-auth rejection is the database doing its job - the question is whether you can see and manage those rules cleanly. On your own servers, Infraveil keeps database access policy consistent across your hosts, applies SSL and allowlist rules deliberately rather than by hand-edited drift, and records changes - so “who can connect to the database, from where” is an answer you can inspect, not a pg_hba.conf nobody remembers editing.
Frequently asked questions
How is this different from “password authentication failed”?
Different layers. The pg_hba error fails first - no rule even permits a connection from your address/method, so it never checks the password. 28P01 means a rule matched and let you try, but the password was wrong. With the pg_hba error, fix how/where you connect, not the password.
What sslmode should I use for a managed database?
At least sslmode=require for RDS/Supabase/Neon - they reject non-SSL connections. require encrypts but does not verify the cert; verify-full also checks it against a CA and hostname. Start with require to connect, then move to verify-full where you can supply the CA.
It connects locally but not from production - why?
Your local machine is likely allowlisted and the production host is not. Managed providers restrict which IPs may connect; a new server or region is blocked until added. Allowlist the production egress IP (or use the provider's VPC/peering).
How do I fix it on self-hosted Postgres?
Add a scoped pg_hba.conf line (host, db, user, address, method like scram-sha-256), match SSL settings, then reload (SELECT pg_reload_conf();). Scope each rule to the smallest address range and strongest method that works - never 0.0.0.0/0 trust.
Client-side, no signup — they run in your browser.