DevOps
How to Enable Remote Connections in PostgreSQL: Security Guide
Learn how to configure PostgreSQL for remote connections with our step-by-step guide. Securely modify config files and set up access in minutes!
Shashikant Dwivedi
Hey there, database enthusiast! 🚀
Today, we’re diving into configuring PostgreSQL to accept remote connections. By default, PostgreSQL only listens to local connections for security reasons. However, there are times when you need to access your database from another machine. Let’s set this up securely!
⏱️ Estimated time: 5-10 minutes
Prerequisites 📋
Before we begin, ensure you have:
- PostgreSQL installed and running
- Root or sudo access to your server
- Your server’s IP address handy
- A PostgreSQL user with remote access permissions
⚠️ Security Note:
Allowing remote connections can expose your database to risks. Always:
- Use strong, complex passwords
- Restrict access to trusted IP addresses
- Implement robust firewall rules
- Use secure connection methods (e.g., VPN or SSH tunneling)
Step 1: Open the PostgreSQL Configuration File 🌐
We need to modify the configuration file to allow PostgreSQL to listen for remote connections. Open it with this command:
sudo nano /etc/postgresql/[version]/main/postgresql.conf
💡
Pro tip: Replace [version] with your installed PostgreSQL version (e.g., 15, 14, etc.). Always back up the configuration file before making changes!
Step 2: Modify the listen_addresses Setting ✏️
In the configuration file, locate the following line:
listen_addresses = 'localhost'
Change it to:
listen_addresses = '*'
This allows PostgreSQL to listen on all available IP addresses.
💡 Important Notes:
- Use
'*'for all IP addresses, or specify a particular IP for more control. - Avoid using
'*'in production unless combined with strict firewall rules.
Save and exit the file (in nano: press Ctrl + X, then Y, and Enter).
Step 3: Configure Client Authentication 🔑
Next, we must configure PostgreSQL’s client authentication file to allow specific IP addresses to connect. Open the file:
sudo nano /etc/postgresql/[version]/main/pg_hba.conf
Add one of the following lines at the end of the file, depending on your requirements:
Allow a specific IP address (recommended):
host all all your_client_ip/32 md5
Replace your_client_ip with the IP address of the machine you want to allow.
Allow all IP addresses (less secure, use with caution):
host all all 0.0.0.0/0 md5
💡 Pro tip:
- The
md5method enforces password authentication. - Always restrict access to trusted IPs for better security.
Save and exit the file (Ctrl + X, Y, and Enter).
Step 4: Restart PostgreSQL 💫
For the changes to take effect, restart the PostgreSQL service:
sudo service postgresql restart
Step 5: Verify the Configuration ✅
Check PostgreSQL Service Status:
sudo service postgresql status
Ensure the service is active and running.
Check Listening Ports:
sudo netstat -tuln | grep 5432
Look for 0.0.0.0:5432 or your server’s IP address to confirm PostgreSQL is listening for remote connections.
Firewall Configuration 🛡️
Don’t forget to allow PostgreSQL’s default port (5432) through your firewall. For example, using UFW:
sudo ufw allow 5432/tcp
💡 Critical Security Warning:
- Allowing
0.0.0.0/0inpg_hba.confis risky. Always combine it with strong authentication and strict firewall rules. - Consider using VPN or SSH tunneling for secure remote connections.
Troubleshooting 🔧
If you encounter issues:
- Check PostgreSQL Logs -
sudo tail -f /var/log/postgresql/postgresql-[version]-main.log - Verify Configuration File Syntax: Ensure there are no typos in
postgresql.conforpg_hba.conf. - Firewall Issues: Ensure port 5432 is open and accessible.
- User Permissions: Ensure the PostgreSQL user has the necessary privileges.
⏱️ Done! Your PostgreSQL server is now configured to accept remote connections.
Got questions or need help troubleshooting? Drop a comment below! Stay secure and happy database managing! 🔐
Security: exposing database ports
Opening database ports to the public internet is convenient for demos and risky in production. Prefer VPN, SSH tunnels, or IP allow-lists, enforce TLS where available, and use strong users and network rules.

Written by Shashikant Dwivedi
Engineer, occasional writer, full-time noticer. Based in Prayagraj, India. New essays land roughly twice a month.
Keep reading
Adjacent essays.
The newsletter
New articles in your inbox.
Occasional articles on engineering, tooling, and software development practices. No marketing, no fluff — just the article, when it's ready.
Unsubscribe with one click. Your email never leaves the list.


