Connect to your Voroa PostgreSQL database from anywhere

Every managed PostgreSQL database on Voroa is given its own public endpoint when it is created, so you can connect from outside — your laptop, a database tool like pgAdmin or DBeaver, or an application hosted elsewhere — without turning anything on first. Connections are always encrypted with TLS and protected by your database password.

That endpoint is reachable from the internet, so it is worth knowing exactly what guards it. Plain connections are refused by the server, passwords are checked with scram-sha-256, and a client that does not finish signing in is dropped after ten seconds. You can narrow it further to a list of addresses you choose — see Restrict which addresses can connect — but read that section before you do, because a Voroa service that uses this database reaches it over the same public endpoint.

The endpoint serves a certificate for *.db.getvoroa.com issued by Let’s Encrypt, a public certificate authority, so your client can verify both the certificate and the hostname with sslmode=verify-full. sslmode=require also works if your tool cannot verify certificates. See Verify the server certificate.

Find your public endpoint

1. Open your database in the dashboard and go to the Connect tab.
2. The External access card shows your external host, port, and a connection URL template.
3. If the card shows external access switched off, choose Enable external access. Your database restarts briefly (a few seconds) and the card then shows the same three details.

The external URL looks like this:

postgres://postgres:***@YOUR-EXTERNAL-HOST:20481/your_db?sslmode=require

Always copy the host and port from the card rather than typing them from an example. The host shown there is the one your database answers on, and it is the only one we support. It can change: if we ever move your database to a different machine we will tell you, and the card will show the new address the moment we do.

Replace *** with your database password. If you do not have it, open the database and select Get connection details on the Connect tab - that creates a new password and shows the full connection URL once, so copy it straight away. Any service still using an older password will need updating after that. The port is unique to your database.

Verify the server certificate

Your public endpoint’s hostname looks like db-xxxxxxxxxxxx.db.getvoroa.com. Its certificate covers *.db.getvoroa.com and is issued by Let’s Encrypt, so it chains to the ISRG root that operating systems and browsers already trust. That means you can use the strictest setting, sslmode=verify-full, which checks both that the certificate is genuine and that it was issued for the host you asked for. The same certificate is served on the direct port and on the pooled port.

With libpq 16 or newer (psql, and Psycopg built against it), tell the client to use the system’s trusted certificates:

postgres://postgres:YOUR_PASSWORD@db-xxxxxxxxxxxx.db.getvoroa.com:PORT/your_db?sslmode=verify-full&sslrootcert=system

With an older libpq, point sslrootcert at your system’s certificate bundle instead, for example sslrootcert=/etc/ssl/certs/ca-certificates.crt on Debian and Ubuntu.

Three things to get right:

• Connect by hostname, never by IP address. Hostname verification compares the name you dialled with the certificate, so an IP address always fails verify-full.
• Do not pin the certificate itself. Let’s Encrypt certificates last 90 days and Voroa renews them automatically about 30 days before they expire. Trust the public root, not one certificate file.
• Use the public hostname for verify-full. A Voroa service connecting over its internal address does not see the public hostname, so verify-full applies to the public endpoint; use sslmode=require on the internal address.

Connect from a database tool

In pgAdmin, DBeaver, TablePlus, or any PostgreSQL client, create a new connection with:

• Host: the external host shown in the card
• Port: the external port shown in the card
• Database, User: as shown in Connection details
• Password: your database password (see Get connection details on the Connect tab)
• SSL mode: require

From the command line:

psql "postgres://postgres:YOUR_PASSWORD@YOUR-EXTERNAL-HOST:20481/your_db?sslmode=require"

Restrict which addresses can connect

External access opens your database to the whole internet, guarded by a password and TLS. You can narrow that to a list of addresses you trust, so a connection from anywhere else is refused before the password is even considered.

You can set one at any time from the same card. Until you do, the endpoint accepts a connection attempt from any address on the internet. Read the warnings below first - a list that is right for a laptop can be wrong for a database your Voroa service uses. A database keeps its trusted-sources list while external access is off, and the enable screen shows you that list - choosing “Any source” there replaces it, so leave it selected only when you mean every source.

A trusted-sources list is set per database, as IPv4 addresses in CIDR form - a single office address looks like 203.0.113.42/32, and a whole range looks like 203.0.113.0/24. The change takes effect on live connections without restarting your database.

Three things to know before you set one:

• Include the address you are connecting from. A list that leaves your own address out will refuse you as readily as anyone else. If that happens, clear the list - an empty list means every source is allowed again, which is where you started - and set it again with the right address.
• Your address must be stable. Most home and mobile connections get a new address regularly, so a list built around one will start refusing you without warning. This suits a fixed office address, a server you own, or a cloud provider’s documented ranges.
• A service you run on Voroa is not exempt. It reaches this database over the same public endpoint, from a platform address, not from your laptop’s. A list that names only your own addresses will refuse your service exactly as it refuses a stranger. If a Voroa service uses this database, contact support before you set a list — the addresses to include depend on where your database runs, and getting it wrong takes your service down.

A database with a trusted-sources list does not use connection pooling, even on a plan that includes it. The pooler cannot check where a connection came from, so allowing it would quietly hand you a weaker rule than the one you asked for. If you need pooling more than you need the address list, leave the list empty.

This narrows who can reach the database. It does not replace the password or TLS - all three apply together, and the list is the outermost of them.

Security notes

• TLS is required. Plain (unencrypted) external connections are rejected by the server, not just discouraged.
• Your password is the key, and it is only ever shown once. We cannot look it up for you. If it may have leaked, select Get connection details on the Connect tab to issue a new one, then update every service that used the old one.
• Whether your own services use the internal URL depends on where your database runs. If it sits on a different machine from the service that uses it, the internal address does not resolve there and the service connects over the public endpoint instead. Ask support which applies to your database - the dashboard does not show it today.
• A connection that does not finish signing in is dropped after ten seconds. This protects the connection slots your own application needs: without it, anything on the internet could open connections, never log in, and hold them long enough to keep your services out. It is not a limit on how long your queries may run, and a correctly configured client never notices it. Restricting trusted sources remains the stronger protection, because an address that is not on your list is refused immediately.
• A trusted-sources list never locks out your own Voroa services. Your services connect from Voroa’s private network, which stays allowed (over TLS, with your password) beside the addresses you list - so you only need to add the machines outside Voroa that should reach the database, such as your laptop or an office.

Disable external access

Choose Disable external access in the same card. After a brief restart the public endpoint is gone. This is not the state the database was created in - a new database is published from the moment it exists - so it is a change you make, and it stays until you turn external access back on.

For most databases this also cuts off your own services. If your database sits on a different machine from the service that uses it, the public endpoint is the only address that service can reach it on, and disabling leaves the database reachable by nothing at all. Ask support which applies to your database before you disable it.

Related

• Create extra PostgreSQL users for each app or tool - give a tool or teammate its own login on this endpoint instead of your main one.
• Managed PostgreSQL on Voroa - sizes, prices and what every database includes.