I have a public api and a public dashboard, where I want the dashboard to hit the api internally over flycast, in order to get the benefits of autostarting it when suspended. However, since the api uses force_https, flycast doesn’t work.
Is there a solution to this along the lines of having the api run two services, one public and one private. If so, I’m not sure how to make one internal-only, since public ips are assigned to the app itself.
Looks like fly-replay would work for this for cases where I would otherwise simply be proxying the request, but still curious for a case where I want to contact an app that is public and can potentially scale to zero, without going back to the internet.
Hi… This is indeed the crux of the problem: there’s still no way to split those two. Any service available over Flycast would also find itself accessible from the entire public Internet.
(And, conversely, the .internal addresses don’t auto-start—as it looks like you’ve already noticed. There are possible workarounds, such as using a dummy HTTP request to app-name.fly.dev to wake the machine, but then app-name.internal for the real traffic, for security. Those have inconvenient corner cases, though, .)
There’s some hope of this becoming possible in the future, however, once they’ve finished with “heavy lift” projects like decentralization of the Fly Proxy…
Hi @joprice, I set a reminder to respond when back from holiday break and sorry the topic auto-closed first.
We’ve been working on solving this for a while now and have been using the solution internally to power our FKS product. There’s still some updates needed to have all the necessary docs and flyctl tooling in place but you can use the feature with direct API calls right now. Here’s how it works (substitute APP_NAME everywhere below for your use):
define a service for the App with the same name (i.e. dashboard) and I’m assuming the API listens on port 8080 and exposing it over flycast via port 80 and the JSON is saved to a file locally as service.json