Postgres Port 5432: What to Check Before Deploying

Q: What is the default Postgres port?

The default Postgres port is 5432. Most clients assume 5432 when no port is provided, but production connection strings should include it explicitly.

Q: How do I find my PostgreSQL port?

Run SHOW port inside psql, check postgresql.conf, or use the connection details from your managed database provider.

Q: Can I change the PostgreSQL port?

Yes, self-managed PostgreSQL can listen on a different port, but you should only change it for a clear operational reason and update every client and firewall rule.

The default Postgres port is 5432. In most deployments, your application connects to PostgreSQL with a hostname, database name, username, password, and port 5432 unless the database server or managed provider has been configured to listen somewhere else. The practical question is not just “which port?” It is “can my app reach that port safely from the runtime where it is deployed?”

That second question is where real production debugging starts. A local psql command can work while the deployed app fails. A database can listen on 5432 while a firewall blocks it. A connection string can include the right port and still fail because SSL, private networking, credentials, or pool limits are wrong.

Postgres port quick answer
What port 5432 actually means
How to check the Postgres port
Connection strings and port syntax
When to change the Postgres port
Why deployed apps still fail on the right port
A production checklist for Postgres connectivity
FAQ

Postgres port quick answer

PostgreSQL uses port 5432 by default for TCP connections. A typical application connection string looks like this:

postgresql://user:[email protected]:5432/appdb

If the port is omitted, many clients assume 5432. Still, production teams should include it explicitly in environment variables so the deploy configuration is readable:

DATABASE_URL="postgresql://app_user:[email protected]:5432/app_db"

On RunxBuild, database-backed apps should keep connection details in environment variables, not source code. Pair that with the RunxBuild database docs, database user management, and network security controls so the app has a clear permission boundary instead of a secret pasted into a random config file.

What port 5432 actually means

A port is a numbered endpoint on a host. Postgres listens on a port so clients know where to open a TCP connection. By convention, PostgreSQL listens on 5432, and the official documentation describes the port server setting as the TCP port the server listens on.

That does not mean every Postgres database is public on the internet. In a healthy production setup, the database may listen on 5432 only inside a private network. Your app can reach it; the rest of the internet cannot. That is usually what you want.

Think of port 5432 as the door number, not the whole address. You still need:

the right hostname
a database name
a username and password
SSL settings when required
firewall or private-network access
a client library that reads the connection string correctly
enough connection capacity for your app and workers

The port matters. It just rarely acts alone.

How to check the Postgres port

Start with the database server if you control it.

Inside psql, run:

SHOW port;

To see related connection settings:

SHOW listen_addresses;
SHOW ssl;

On a Linux server, you can also inspect the PostgreSQL config file. The setting often lives in postgresql.conf:

port = 5432
listen_addresses = 'localhost'

If Postgres is managed by a platform, use the provider’s connection details instead of editing server files. Managed databases often expose one internal hostname and one external hostname, with different security expectations.

From the application runtime, test reachability. A raw TCP test only proves the port opens; it does not prove credentials or SSL are correct.

nc -vz db.example.com 5432

Then test with psql:

psql "postgresql://user:[email protected]:5432/appdb?sslmode=require"

If nc succeeds but psql fails, the network path is open and the issue is likely credentials, database name, SSL mode, or server rules. If nc fails, start with hostname, firewall, private network, or service binding.

For official reference, see the PostgreSQL connection settings and psql client documentation.

Connection strings and port syntax

Most production apps pass Postgres settings through DATABASE_URL. The port sits after the hostname and before the database name:

postgresql://USER:PASSWORD@HOST:PORT/DATABASE

Example:

postgresql://api_user:[email protected]:5432/product_api

Some frameworks split this into separate environment variables:

PGHOST=postgres.internal
PGPORT=5432
PGDATABASE=product_api
PGUSER=api_user
PGPASSWORD=long_secret

Both styles work. The single URL is convenient for deployment. Separate variables are sometimes easier when legacy libraries expect PGPORT directly.

The mistake to avoid is hardcoding connection details in app code. Your API should not know its database password because somebody typed it into settings.py, server.js, or a YAML file that later became public. Put secrets in environment variables and let the platform inject them at runtime.

If you are planning the full database-backed deployment, use the RunxBuild hosting calculator to estimate the app, database, and storage together. A database is not an accessory. It is usually the first stateful part of the product.

When to change the Postgres port

Most teams should not change the Postgres port unless they have a specific reason. Security through obscurity is not a serious database strategy. A non-default port may reduce drive-by noise in logs, but it does not replace authentication, TLS, private networking, least-privilege users, backups, or network rules.

Valid reasons to change the port include:

multiple Postgres clusters on the same host
a local development conflict
a migration where old and new instances run side by side
strict platform networking requirements
a temporary blue/green cutover setup

If you do change it, update every client, migration script, connection pooler, monitoring check, backup job, and secret reference. The port number has a way of hiding in places nobody remembers until the deploy fails.

For self-managed servers, changing the port usually means editing postgresql.conf, restarting or reloading PostgreSQL, and confirming firewall rules. On managed platforms, change only what the platform supports. Do not fight the provider’s network model just to make a port number look custom.

Why deployed apps still fail on the right port

A deployed app can fail even when DATABASE_URL contains :5432. Here are the usual suspects.

The hostname is only valid locally

localhost from your laptop means your laptop. localhost from a deployed app means the app container or VM. If Postgres is not running in that same runtime, localhost:5432 is wrong.

Use the managed database hostname, internal service name, or private-network address provided by your platform.

The database only allows private access

This is a feature, not a bug. If the database is private, your app must run in a network that can reach it. A random local terminal should not necessarily connect.

RunxBuild database networking docs help keep that boundary intentional. The goal is not “open the port to everything.” The goal is “allow the right app to reach the right database.”

SSL mode is missing or wrong

Many managed databases require SSL for external connections. Add the correct SSL parameter for your driver. For libpq-style clients, that often looks like:

?sslmode=require

Some ORMs have their own SSL config. Read the driver docs instead of assuming every library parses DATABASE_URL the same way.

The database user lacks permission

A successful TCP connection can still fail at authentication or authorization. Use a dedicated app user with the minimum privileges required. Avoid deploying with a superuser account because it was faster during setup.

The app opens too many connections

Port 5432 can be reachable while the database rejects new clients because connection limits are exhausted. This often happens with serverless-style bursts, background workers, or every request creating a new pool.

Use connection pooling, tune worker counts, and watch max connections. RunxBuild’s database max connections guide is a useful checkpoint before scaling the app tier.

A production checklist for Postgres connectivity

Before you blame the port, walk through the whole path.

Confirm the expected port, usually 5432.
Verify the hostname from the deployed runtime, not just your laptop.
Store DATABASE_URL or PG* variables in environment variables.
Confirm the database name exists.
Use a dedicated app user, not a shared admin login.
Check SSL requirements.
Confirm private-network or firewall rules.
Run migrations from the same environment model used in production.
Configure connection pooling for web workers and background jobs.
Watch deploy logs and database logs during the first release.

This is also where platform shape matters. A backend service, managed database, private networking, environment variables, logs, backups, and deploy history should feel like one system. If every piece lives in a different dashboard, debugging becomes a tab-management exercise with consequences.

RunxBuild is built around that growth path: deploy the service, connect the database, keep secrets out of code, and inspect logs when something goes sideways. The port is only one line. The operating model is the real win.

Practical examples

Node.js with pg

import pg from "pg";

const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
  ssl: process.env.NODE_ENV === "production" ? { rejectUnauthorized: false } : false,
});

The deployed app should receive DATABASE_URL from the environment. Locally, use a .env file that is ignored by Git.

Django

import dj_database_url

DATABASES = {
    "default": dj_database_url.config(conn_max_age=600, ssl_require=True)
}

Django does not care that Postgres defaults to 5432 if the URL is wrong, the app cannot reach the host, or the SSL settings do not match the database.

Go

connStr := os.Getenv("DATABASE_URL")
db, err := sql.Open("postgres", connStr)

Keep the port in the URL and keep the URL out of source code. Simple is good. Secret-simple is better.

FAQ

What is the default Postgres port?

The default Postgres port is 5432. Most PostgreSQL clients assume 5432 when no port is provided, but production connection strings should include the port explicitly for clarity.

How do I find my PostgreSQL port?

Run SHOW port; inside psql, check postgresql.conf, or use the connection details from your managed database provider. From an app runtime, test reachability with nc -vz hostname 5432 and then confirm authentication with psql.

Can I change the PostgreSQL port?

Yes, self-managed PostgreSQL can listen on a different port by changing the port setting and restarting or reloading the server. Only do this for a clear operational reason, then update clients, firewalls, scripts, pools, and monitoring.

Is opening port 5432 to the internet safe?

Usually no. PostgreSQL should be protected with strong credentials, TLS, network restrictions, and preferably private networking. Public access may be necessary in some cases, but it should be intentionally limited.

Why does localhost:5432 fail in production?

localhost means the current machine or container. In production, your app usually runs separately from the database, so it needs the database hostname or private service address instead of localhost.

Does DATABASE_URL need to include the port?

It should. Some clients assume 5432 by default, but including :5432 makes the deployment easier to inspect and prevents confusion when a database uses a custom port.