Clarify understanding of the Fly Proxy, auto start/stop and internal vs "public" DNS names

Questions / Help
1

So, I have 3 fly apps in an organisation: nginx, api and ui

All of them have have essentially the same [http_service] block, just with differing internal_port

[http_service]
  internal_port = 80
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
  processes = ['app']

nginx is the reverse proxy

Initially, I set the upstreams to http://ui.fly.dev and http://api.fly.dev, which works perfectly.

If any of the apps go to sleep/shut down, they are automatically restarted, which is excellent.

However, I don’t really want the ui and the api to be “on the internet”.
My first thought was to change the upstreams to http://ui.internal:3000 and http://api.internal:8080.
Initially, this did work.

However, this seemed to be a coincidence. Once ui and api scaled to 0, nginx could not connect to the upstreams, and they never restarted.

What I assume this means, is that Fly Proxy is doing the start/stop, and this only works on the public DNS

Is this assumption correct:
If I want apps to auto-start and auto-stop, then I MUST have a service/http-service, and I MUST access them via the *.fly.dev DNS

So essentially, I CANNOT have the following “stack”:
API with 2 instances, that is able to go from 0 to 2 to 0, which does NOT have a public DNS
UI with 2 instances, that is able to go from 0 to 2 to 0, which does NOT have a public DNS
nginx with 2 instances, that is able to go from 0 to 2 to 0, which DOES have a public DNS, and serves the “private” api and ui

2

So, after posting this, I read the docs some more, and found this - Private Networking · Fly Docs

I think this does exactly what I need :+1:

3

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