postgre fails when connecting to an external service

Questions / Help Build debugging
1

Fly is a terrific product, My team members love it, but there are still some services stuck on other cloud platforms that haven’t been migrated yet, we want to connect to fly’s postgre from apps on external cloud platforms, but we are having trouble here, do I need to make changes to something like firewall, whitelist or any related configuration? Appreciate it if someone could point out the issue.

My steps
I followed connecting-external-services instructions and completed the following steps:

  1. Create PG and assign ipv4 to it.
  2. Add the toml file and specify in the file that the mapped public port is 10000.
  3. Redeploy the PG and successfully release a new version.

Now when I type flyctl info I can get the following message:

Services
PROTOCOL PORTS             
TCP      443 => 5432 [TLS] 
         10000 => 5432 []  

IP Adresses
TYPE ADDRESS     REGION CREATED AT 
v4   *.*.*.*        20m35s ago

Current connection error
Everything seems to be working fine (apps on the Fly platform can connect), but I still can’t use psql or a client to connect directly to pg from an external network:

connection to server at "<my_app_name>.fly.dev", port 10000 failed: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
1 Like
2

Are you trying to connect with TLS? That port 443 handler won’t work, Postgres does TLS weirdly. And port 10000 in that config will only work without TLS.

1 Like
3

Could the Fly docs on PostgreSQL be updated then? I just went through the same process as witt-dev, ran into the same issues, and eventually found this comment. The Fly guide still instructs us to expose 443 to allow external, secure connections.

After a little more searching I found the relevant ticket, where setting up pg-bouncer is the preferable solution, but even then there seemed to be uncertainty within the Fly team about doing this.

My customer use-case at this stage was really just seeing about exposing a fly-hosted db for Github Actions which are related to a project being hosted on fly.io, so external access is essential.

It seems there’s a bit more work to do this, and I appreciate the primary use case for the PostgreSQL offering is multi-region, internal read db services, so I’ll just use another service for any external db access needs for now.

1 Like