Documentation

Expose a local PostgreSQL database with Pinggy

PostgreSQL listens on TCP port 5432 by default. On a development machine that port is reachable from psql on the same host or from other machines on the LAN, but it is firewalled from the public internet - and rightly so, because exposing a database directly to the world is risky.

Pinggy provides a controlled middle ground. A TCP tunnel gives a remote teammate or a hosted service a single public hostname and port that forwards into your local database, while still requiring your existing PostgreSQL credentials and TLS configuration to actually connect.

Step 1: Confirm PostgreSQL accepts the connection locally

Make sure the server is running and the postgres user (or whichever role you plan to use remotely) can authenticate:

psql -h 127.0.0.1 -U postgres -d mydb

If psql connects, you are ready for the tunnel. If not, check pg_hba.conf and postgresql.conf - listen_addresses must include localhost or *, and pg_hba.conf must contain a matching line for the role and source.

Step 2: Open a TCP tunnel

PostgreSQL is a TCP wire protocol, not HTTP, so use Pinggy’s TCP tunnel:

ssh -p 443 -R0:localhost:5432 tcp@free.pinggy.io

Pinggy returns a public hostname and port - for example tcp://rndnj.a.free.pinggy.online:31572. That endpoint is the address remote clients should connect to.

Step 3: Connect from a remote client

Use the same psql invocation, swapping in the Pinggy hostname and port:

psql -h rndnj.a.free.pinggy.online -p 31572 -U postgres -d mydb

GUI clients (DBeaver, TablePlus, pgAdmin) accept the same parameters under their connection settings.

Step 4: Lock the tunnel down

Anyone who guesses the Pinggy hostname and port hits your pg_hba.conf directly. Reduce the attack surface with at least one of:

  • A dedicated, low-privilege role for remote access - never expose postgres superuser credentials.
  • IP whitelisting on the tunnel so only known networks can reach the port.
  • TLS-only connections by setting ssl = on and forcing hostssl rules in pg_hba.conf. The TLS handshake terminates between the client and PostgreSQL, end to end through the tunnel.

Step 5: Stable address for production-like access

Free TCP tunnels reissue both hostname and port on every reconnect, which breaks saved connection strings. Sign in to the dashboard and use your access token (token+tcp@free.pinggy.io); on a Pinggy Pro plan you also get a stable hostname and port that survive reconnects.

For a deeper dive on TCP tunnel options, see the TCP tunnels reference.