Can't connect to database via proxy (TablePlus)

I’m trying to connect to my production database on TablePlus. I did it via URL as follows:


but I get the error that the database does not exist if I have the hostname blank. If I enter the appropriate host name given to me when I created the databse I get the following error:
could not translate host name "all-spice-production.internal" to address: nodename nor servname provided, or not known

I have my proxy running too:

flyctl proxy 5432 -a all-spice-production

Hey there!

Since you’re proxying via fly proxy, you don’t need to connect to your .internal hostname. You should be able to access your instance via localhost:5432. The proxy subcommand creates proxy between an internal port on any of your instances and a local port. Meaning you can then access the port as if it was local.

If you just need to connect to your instance for debugging locally, you can use fly postgres connect -a all-spice-production (I believe). You might have to check out the other flags for your specific situation: fly postgres connect --help.

If this isn’t how you want to do it, you can still access .internal hostnames. You’ll need to be connected to your private wireguard network for that. Here is some documentation on how to do it: Private Networking · Fly Docs

Thanks for the reply!

As you say in the first paragraph of your answer, I thought I’d be able to do so, with the following connection but I continually get the error “all-spice-production” does not exist. I’d like to be able to connect via TablePlus in order to visualise my production data.

I’ll give the Private Networking a try in a couple hours when I’m home from work. Will using wireguard allow me to connect via TablePlus? And perhaps a stupid question, once I’ve created a wireguard tunnel, will it act as a proxy (just a more secure version of running flyctl proxy …)?

Do you already have a local postgres database running on port 5432? This might be an issue with fly proxy not telling you that. You can try fly proxy 15432:5432 all-spice-production.internal to bind to port 15432 locally instead to use a different port that’s likely unused.

There are no stupid questions :slight_smile:

Connecting to your private wireguard network means you have access to all the apps on that private network (likely all apps in your organization). You don’t need to use any proxying if you connect to your private network. You’d access your database like you do in your other Fly apps: by connecting to all-spice-production.internal:5432 locally.

When you connect to your private wireguard network, it changes the DNS servers your computer uses for resolving hostnames. That’s how it makes it possible to resolve .internal hostnames. Since these aren’t “real” hostnames (they don’t exist from the perspective of the internet), you can only resolve them when using our own DNS servers (same ones your app use).

I just checked and the proxy the only thing I have running on port 5432, I also tried proxying my local port 15432 and I get the same error… I don’t have any other app running locally that might be using a dev databases on port 5432.

Thanks so much for you explanation! I’ll go through the documentation later and let you know how it goes.

@jerome I just tried connecting to the database via my connectio with Wireguard. I used the DNS servers address (defined in the Wireguard app) as the host/socket in TablePlus, the port is 60367 (which is defined in the Wireguard app as the ‘Listen port’). The database remained all-spice-production which does come up with I run dig +noall +answer _apps.internal txt. Yet there is no connection made. I may be completely misunderstanding how to use Wireguard.

When I use all-spice-production.internal as the host instead of the DNS provided in the Wireguard app, I get the error that the connection was refused (as seen below). The fdaa address in the connection below doesn’t seem to be correct or in line with the one I see in my Wireguard app or my wireguard.conf file.

Oh you should use port 5432, the expected port is the one being listened on from your postgres server.