Hoping this question makes sense! I’m hoping to limit an API to internal only use. I’ve deployed a simple Node.js app to Fly and currently, I can just visit the .dev hostname that Fly provides and access the app from anywhere, and I’d like to prevent that.
Based on this post from Kurt, it sounds like I’ll need to set up an nginx server through which API requests from the client will get routed, but are there configurations I’m missing to prevent access to the API from everywhere except other Fly apps deployed within the same organization? And/or is there official Fly documentation around this particular use case?
I’m guessing that’s because your fly.toml file (that’s the config file that will have been made for you) tells Fly to expose the app to the internet. It does that in the [[services]] section which maps internal/external ports. If you don’t want your app accessible to the outside world (outside your private Fly-provided network) it should simply be a case of removing that whole [[services]] block of YAML. I don’t think you’d need an nginx proxy just for that.
Then your other apps should still be able to connect to it, as long as they belong to the same organization. They will use e.g http://private-api-name.internal:8080/example/path (since you need to specify the port - likely to be 8080 or 3000). And if you try https://private-api-name.fly.dev, it shouldn’t work.
Not by default. It would depend on how your Node app is running. Most will have http.createServer (in some kind of app.js or equivalent) and so will use http, likely on 3000 or 8080.
If you want https internally you could try changing that to https.createServer … and so would need to provide that with a key and cert in its options. See e.g HTTPS | Node.js v21.2.0 Documentation.
Ok - makes sense. The specific issue I’m running into is that when I open the client application I’ve deployed within the same Fly organization in a browser, it defaults to https. So when I’m making an API request from https → http, it’s throwing a Mixed Content error:
Mixed Content: The page at 'https://{client-app}.fly.dev' was loaded over HTTPS,
but requested an insecure resource 'http://{api-app}.internal:8080/path'.
This request has been blocked; the content must be served over HTTPS.
I’ve tried removing the force https config from the client app’s toml file just to see if that would work, but it didn’t actually change anything (ie. loading the fly.dev url would still redirect to https)
Curious if this is the reason that an nginx proxy was suggested!
Well … the first thing is that Google own .dev and force https:
So yes, it will default to https in a browser and that would be correct in that it would also need to load its assets using https. Hence the error/block. However I may have misunderstood what you were trying to do. I figured your apps were doing some server-server communication over the internal network.
If you are opening a URL in a browser (unless its some headless/CI) using a fly.dev domain, you would need to open your app up to the internet. Unless you are running WireGuard on your own machine, and so are joining the private network that way (to resolve the .internal domain). So many variables.
If you are doing something like an SPA, loading that in a browser, then doing e.g API calls to sign a user in or something, yes you would need your API app to be running https in order to load its assets from a https page. So you would need to adapt your Node app to run a https server, and yes, provide a cert/key as mentioned above.
If you are doing something like an SPA, loading that in a browser, then doing e.g API calls to sign a user in or something, yes you would need your API app to be running https in order to load its assets from a https page. So you would need to adapt your Node app to run a https server, and yes, provide a cert/key as mentioned above.
Ok - great, that’s what I figured but super helpful to have it explicitly confirmed. Appreciate all your help!!
Ah, an SPA. Yes so that would be making API calls, from the browser (client-side). However you again run into the issue then of protecting that API from other people. If it is just for your use, you could run Wireguard. Then only you (and your Fly apps) can resolve your own internal domains. But if other people need to access it without Wireguard, you would need to protect your API using some other approach. Hence that nginx proxy mentioned earlier.
