If you plan to run the BEAM using Erlang distribution, I don’t think Azure Container Apps is the ideal environment for that. If all BEAM instances are standalone (behind the load balancer / ingress), then all is good. But Erlang distribution is east-west-traffic, cluster-internal gossip. For that to work, you need 2 things:

1. You want to be able to discover the IP addresses of other BEAM instances/nodes/pods.
2. You must be able to actually get the TCP traffic going across these nodes.

Discovery: I’m not aware of an API that a freshly booted node could query, to enumerate the environment. It seems not to be exposed in ARM, also not in an environment variable. As a workaround, a fresh node could write it’s own IP to an external configuration store (Azure Storage, relational DB, etcd/consul/zookeeper), and use that store to discover other nodes. But that complicates things, because now you also depend on that external component.

East/West traffic: Assuming you found all the VNET-internal IP addresses of the other nodes, you need to establish the TCP connection when your instance connects to another node. Azure Container Apps has effectively an AKS cluster under the hood, and it has a certain CNI implementation going. Assuming you can successfully get your app to fly, but in 6 months down the road the Container apps team changes the CNI implementation and suddenly you can no longer directly talk across nodes, that would be an outage outside of your sphere of influence.

I guess that’s a long-winded explanation to say: If you want Erlang distribution, certainly running on Azure Kubernetes Service (AKS) or on IaaS virtual machines might be the most predictable option.

It might be that there’s some other way, but I’m not aware of.

We’ve been running an Elixir system (phoenix liveview app) in production on Azure for a few years, but not using Azure Container services. We started with terraform but moved to bicep later for our infrastructure as code. Happy to sync up and share experience if it is helpful. PM me.

Thank you for looking into it further @chgeuer and for providing a definitive answer.