I am having some issues connecting to my database locally.
I have read the guide and I am able to connect that way with psql, or through a GUI tool like DBeaver.
The issue arises when I try to connect through Elixir, like so:
config :example, Example.Repo,
username: System.get_env("DB_USERNAME") || "postgres",
password: System.get_env("DB_PASSWORD") || "postgres",
database: System.get_env("DB_NAME") || "example_dev",
hostname: System.get_env("DB_HOST") || "localhost",
This gives me the following error
[error] Postgrex.Protocol (#PID<0.665.0>) failed to connect: ** (DBConnection.ConnectionError) tcp connect (*omitted*-stg-db.internal:5432): non-existing domain - :nxdomain
which to me indicates Elixir for some reason is unable to resolve the hostname. Pinging that same db with
ping *omitted*-stg-db.internal doesn’t work either, only connecting directly through psql. How can I connect to the fly database instance in my local elixir environment?
Hey @Emanuel_Enberg. Just to confirm, you’re able to connect externally using general tools to the
app.fly.dev endpoint, right? Seems clear that the app is running, then.
:nxdomain usually indicates a misconfiguration — the usual suspects are the app instances and the DB instances being in different organisations, or misconfigurations or spelling mistakes.
One thing you could do to confirm this is to get into the application server using
fly ssh console and
psql to the DB server using the
EDIT: misunderstood and though there was trouble reaching the DB from the application server on Fly.
Do you have wireguard set up? That error means it’s not resolving the
*omitted*-stg-db.internal hostname properly, which is a pretty common issue. The
.internal resolution with wireguard is pretty complicated.
You can try running
fly proxy 15432:5432 -a <stg-db>. That should let you connect to
localhost:15432 when it’s running.
Debugging the DNS issue is a little harder. Youre wireguard config will have a DNS field. You can grab that address (
fdaa: something) and run:
dig aaaa *omitted*-stg-db.internal @fdaa:<ip> +short
Thank you Kurt! Setting up a proxy solved the issue