The two private names & the discriminator

An app on Fly reaches another app over the private IPv6 network (6PN) by a private name, and there are two name schemes. .internal is direct 6PN. A name like portal-postgres.internal is org-scoped, carries only AAAA (IPv6) records, and resolves only for an app that has a live machine in the requester’s 6PN. It requires the two apps to sit in the same organisation. This is the convention the deploy uses: the prod.exs fly_dns topology polls echo-portal.internal to form the cluster, and the first bring-up reached the database at portal-postgres.internal. When that database is auto-stopped, its .internal name returns no record, and the boot crashes with :nxdomain — this is gotcha 2.

.flycast is the Fly-proxy private name. It reaches an app through Fly’s internal proxy rather than directly, and it additionally needs a flycast IP — for a Fly Managed Postgres, that IP is allocated by fly mpg attach. The first bring-up’s portal-postgres is a same-org postgres-flex HA cluster reached over .internal, not a Managed Postgres over .flycast; F7.3 names that discriminator so the right host scheme is chosen for the right kind of database. Pick the database kind to read which scheme its host carries.

The trap is that two different faults raise the same error. Gotcha 2 — the name has no record because the instance is stopped or out of org — crashes Postgrex with :nxdomain. Gotcha 3 — the name has an AAAA record but the app A-queries it on the default :inet family (dive 2’s fault) — crashes with the identical :nxdomain. The error string does not say which. The test that isolates them is a single command run from another running machine in the org: getent hosts <db>.internal. That command uses glibc getaddrinfo, the same resolution path Erlang’s native lookup takes. If the other machine resolves the name to an AAAA, the name and DNS are sound — so the fault is the app’s address family (gotcha 3, fixed in runtime.exs), not the network (gotcha 2).

The first bring-up ran exactly this test: getent hosts portal-postgres.internal SUCCEEDED from inside the running, same-org portal-postgres machine, returning an AAAA. The name was sound, so the app’s IPv4 default was the fault — which is how gotcha 3 was identified as the decisive one. A complementary check guards the other direction: if even echo-portal.internal — the app’s OWN name — fails to resolve from inside a machine, the machine’s 6PN DNS itself is broken, not the target. Set the database host’s machine state and the app’s Postgrex address family below and read the diagnosis the discriminator returns for that cell.

One more unblock is worth naming for completeness, and then setting aside. A bracketed IPv6 literal in DATABASE_URL — a fixed address rather than a name — sidesteps resolution entirely: with no DNS lookup, neither gotcha 2 nor gotcha 3 can fire. It confirms the network path works. But it pins the URL to a machine IP that Fly can recreate, so it is brittle as a deploy value. The durable fix is the one dive 2 wired: socket_options: [:inet6] on Portal.Repo, so the .internal AAAA resolves over IPv6 through a name that survives a machine being recreated. The literal is a diagnostic, not the deploy path.