Machines app without public ports

[losfair]

I’m routing all ingress traffic through an API gateway and would like to avoid exposing services directly to the outside world. After following the instructions here to deploy a Machines app, an undocumented [http_service] section is generated in fly.toml (and the flyctl source suggests that there is no switch to turn off exposing the port with http_service?). Traditional [[services]] section seems to work, but with Machines it requires at least one external mapping.

How can I use a Machines app without exposing any port to the outside but still have automated liveness/health check?

[losfair]

Another problem I ran into is that wake-on-request does not work when requesting the Machines app with the internal address (app-name.internal).

[JP_Phillips]

Hi @losfair, sorry for any issues you’ve hit using fly machines launch! Unfortunately that subcommand puts a lot of expectations on apps and I think you’d be better off managing the machines directly with fly machine run and fly machine update. Those give you more direct access to the machine config.

For your use case, you will still need the [http_service] because it tells our proxy how to route requests which you’ll still want even with the API gateway setup. In order to support wake on request for internal requests, you’ll want to use private load balancing. With the above to configurations, you should be able to run an internal only service that is accessible only through the API gateway and can scale to zero.

[ignoramous]

@JP_Phillips

In order to support wake on request for internal requests, you’ll want to use private load balancing .

Neat. Can we please add it to the documentation?

I asked this once before, it went unanswered: New Feature: Application Private IPs - #6 by ignoramous

A related Q: Is connecting straight to the public IPv6 endpoint of the Machine guarantee to wake it up?

---

@JP_Phillips

fly machine run and fly machine update. Those give you more direct access to the machine config.

nb these still work differently to fly deploy -a <machine-app>…which I’ve attempted to fix in a PR request I sent: Improvements to deploy and run commands for machines by ignoramous · Pull Request #1327 · superfly/flyctl · GitHub

[ignoramous]

@losfair

Traditional [[services]] section seems to work, but with Machines it requires at least one external mapping.

I once deployed a machine without [[service]] (as I was testing schedules). I found that fly m start woke it up and ran its entrypoint.

fly ssh console (sshing into machine’s 6pn address) also woke up the machine, which is interesting because you say sending request to private 6pn address doesn’t wake it up…

[losfair]

@JP_Phillips

For your use case, you will still need the [http_service] because it tells our proxy how to route requests which you’ll still want even with the API gateway setup. In order to support wake on request for internal requests, you’ll want to use private load balancing . With the above to configurations, you should be able to run an internal only service that is accessible only through the API gateway and can scale to zero.

Thanks for the advice. I tried allocating private Flycast IPs and pointing the API gateway at it. It works!