It looks like @bojand beat me to this. I’ve left mine below as it adds some additional details. Sorry for the sparse documentation. I’ve made an internal ticket to prioritize official documentation of this functionality.

Each App Platform App has a private network, though at present these are separate from customer managed VPCs. Workers, jobs, and services may connect locally (not over the public internet) by component name to services within the same app. The app spec document for service components may include a list of internal_ports, and/or an http_port. http_port is required unless at least one port is specified in the components internal_ports list. If an http_port is specified, the service will be expressed both internally within the same app AND publicly at the apps ingress domains. Services with at least one internal_ports port and no http_port are only accessible locally within the same app. The component name of each service resolves (via the app’s default DNS server) to a load-balancer which balances new connections (layer 4) across each healthy service instance. If you’re using the internal_ports, the load-balancer will be available at each listed port. For example, a service web with a spec {"services": [{"name": "web", "internal_ports": [8080, 3000]}]} would be available at http://web:8080 and http://web:3000. If a the service specifies an http_port, it’s available at that port and port 80, unless it’s otherwise overridden in the service’s internal_port. For example, {"services": [{"name": "web", "http_port": 8080}]}) would be available at http://web:8080, http://web:80). A port specified as http_port MUST implement the HTTP protocol, but internal_ports can facilitate any TCP protocol.