# Machines app without public ports

**URL:** <https://community.fly.io/t/machines-app-without-public-ports/7625>\
**Category:** General\
**Created:** [October 3, 2022, 7:23pm UTC](https://community.fly.io/t/machines-app-without-public-ports/7625 "2022-10-03T19:23:45Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![losfair](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/losfair/32/14415_2.png) [@losfair](https://community.fly.io/u/losfair)\
**Post date:** [October 3, 2022, 7:23pm UTC](https://community.fly.io/t/machines-app-without-public-ports/7625/1 "2022-10-03T19:23:46Z")

</div>

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](https://community.fly.io/t/preview-deploying-applications-on-machines-with-flyctl/6171) 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?

---

<div class="post-metadata">

**Author:** ![losfair](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/losfair/32/14415_2.png) [@losfair](https://community.fly.io/u/losfair)\
**Post date:** [October 3, 2022, 7:28pm UTC](https://community.fly.io/t/machines-app-without-public-ports/7625/2 "2022-10-03T19:28:04Z")

</div>

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`).

---

<div class="post-metadata">

**Author:** ![JP\_Phillips](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/jp_phillips/32/18337_2.png) [@JP\_Phillips](https://community.fly.io/u/JP_Phillips)\
**Post date:** [October 3, 2022, 8:16pm UTC](https://community.fly.io/t/machines-app-without-public-ports/7625/3 "2022-10-03T20:16:56Z")

</div>

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](https://fly.io/docs/reference/private-networking/#private-load-balancing-aka-flycast). 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.

---

<div class="post-metadata">

**Author:** ![ignoramous](https://avatars.discourse-cdn.com/v4/letter/i/a9adbd/32.png) [@ignoramous](https://community.fly.io/u/ignoramous)\
**Post date:** [October 4, 2022, 4:04am UTC](https://community.fly.io/t/machines-app-without-public-ports/7625/4 "2022-10-04T04:04:46Z")

</div>

> [@JP\_Phillips](#):
>
> In order to support wake on request for internal requests, you’ll want to use [private load balancing](https://fly.io/docs/reference/private-networking/#private-load-balancing-aka-flycast).

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](https://community.fly.io/t/new-feature-application-private-ips/6078/6)

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](https://community.fly.io/t/preview-deploying-applications-on-machines-with-flyctl/6171/5) 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](https://github.com/superfly/flyctl/pull/1327)

---

<div class="post-metadata">

**Author:** ![ignoramous](https://avatars.discourse-cdn.com/v4/letter/i/a9adbd/32.png) [@ignoramous](https://community.fly.io/u/ignoramous)\
**Post date:** [October 4, 2022, 4:28am UTC](https://community.fly.io/t/machines-app-without-public-ports/7625/5 "2022-10-04T04:28:14Z")

</div>

> [@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 `schedule`s). I found that `fly m start` woke it up and ran its `entrypoint`.

`fly ssh console` (`ssh`ing 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…

---

<div class="post-metadata">

**Author:** ![losfair](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/losfair/32/14415_2.png) [@losfair](https://community.fly.io/u/losfair)\
**Post date:** [October 4, 2022, 10:17am UTC](https://community.fly.io/t/machines-app-without-public-ports/7625/6 "2022-10-04T10:17:50Z")

</div>

> [@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](https://fly.io/docs/reference/private-networking/#private-load-balancing-aka-flycast). 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!
