Fly launch tells me to use .flycast, but only works on .internal

I am trying to start a Postgres image as a fly app on the private network, but going through fly’s proxy. I was hoping to get the benefit of ‘auto stop’ this way, but despite fly launch telling me:

`Your your newly deployed app is available in the organizations’ private network under http://myapp-postgres.flycast`

It is only available at the .internal address. fly dig shows me the same, empty for .flycast, address shown for .internal. It looks like it’s got only a private ip address:

❯ fly services list -a myapp-postgres
Services
PROTOCOL	PORTS       	HANDLERS     	FORCE HTTPS	PROCESS GROUP	REGIONS	MACHINES
TCP     	5432 => 5432	[PROXY_PROTO]	False      	app          	iad    	1       	

This is the fly.toml that’s being used:

app = "myapp-postgres"
primary_region = "iad"

[build]
image = "postgres:16-alpine"

[env]
PGDATA = "/var/lib/postgresql/data/pgdata"
POSTGRES_DB = "postgres"
POSTGRES_PORT = "5432"
POSTGRES_USER = "postgres"

[[mounts]]
destination = "/var/lib/postgresql/data"
source = "pg_data"

[[services]]
auto_start_machines = true
auto_stop_machines = "suspend"
internal_port = 5432
min_machines_running = 0
protocol = "tcp"

[[services.ports]]
handlers = ["proxy_proto"]
port = 5432

[[vm]]
memory = "2gb"
size = "performance-1x"

In two other posts concerning .flycast troubles it seems like the advice that worked was ‘turn it off and back on again’, basically, by releasing the ip and creating it again. But these are fresh apps i’m creating, i’m working towards ‘preview apps’, i don’t really want to add a step of ‘cycle the ip’ after freshly creating it just as a workaround. I’m really hoping I’ve just got something silly set in the fly.toml.

Yeah, like I said earlier, that shouldn’t really be necessary, :sweat_smile:, and it’s not typical of the platform these days.

(The old system had a lot of problems with metadata, though.)

I would strongly recommend against using fly launch in any automated setting, however. It’s very heuristic, and the heuristics do change without warning.

I create a lot of small test apps that use Flycast, and the most reliable procedure in my opinion is…

fly app create tst-app
fly config validate --strict   # opt-in silly mistake detector.
fly ips allocate-v6 --private
fly deploy --no-public-ips

These days, you might be able to use fly deploy --flycast, thus shaving off the third step.

I may be misunderstanding you here, but you actually want fly ips list, to verify the existence of the Flycast address. (It should have TYPE = private, REGION = global, and an address beginning with fdaa:.)

Hope this helps!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.