There is a certain category of engineering decision that looks straightforward on paper but gets complicated quickly in practice. Combining Elixir with Kubernetes is one of them. Both technologies are production-proven. Both handle scale well. But they approach distributed computing from entirely different angles, and understanding where those angles align is what separates a well-architected system from an expensive mistake.
Why Elixir and Kubernetes Are Not an Obvious Pairing
Elixir and Kubernetes were built with different goals, and using them together takes more care than most teams expect. Elixir runs on the BEAM virtual machine, the same runtime that powers Erlang. The BEAM was built in the 1980s for telecom infrastructure that could not afford downtime. Fault tolerance, process isolation, and node-to-node messaging are baked into the runtime itself, not bolted on through external tooling.
Kubernetes, on the other hand, solves a different problem. It manages containerised workloads across a cluster of machines, handling scheduling, scaling, and restarts at the infrastructure level. It assumes your application is largely stateless, or that state lives in an external store.
The tension is real. When you run distributed Elixir, nodes communicate directly over TCP using the Erlang distribution protocol. They form a mesh. Kubernetes prefers ephemeral pods behind load balancers, which disrupts that mesh unless you configure things carefully. Neither technology is wrong. They are solving different layers of the same problem, which is precisely why the combination requires deliberate setup rather than default configuration.
The Real-World Scenarios Where This Stack Pays Off
This combination works best for high-traffic APIs and large-scale data processing pipelines, not for every Elixir project.
Stateless Phoenix APIs Behind a Kubernetes Ingress
Phoenix applications serving REST or GraphQL APIs are an excellent fit. When each request is handled independently and session state lives in a database or cache, pods can be scaled horizontally without any coordination between nodes. Kubernetes handles traffic distribution through its ingress controller. Phoenix handles throughput efficiently thanks to the BEAM scheduler. The result is a setup that scales linearly with load and deploys safely through rolling updates. Teams that need to ship frequently and scale unpredictably get the most out of this pattern.
Event-Driven Pipelines with Broadway and Kafka on Kubernetes
Broadway, the Elixir library for concurrent data processing, pairs naturally with Kafka when both run on Kubernetes. Each Broadway pipeline runs as a pod. Kafka partitions map cleanly to consumer groups. Kubernetes manages pod restarts when something fails, and Broadway handles backpressure within the process. The operational model is clean: one concern per pod, infrastructure-level restarts, application-level flow control. Teams processing high volumes of events with strict ordering requirements find this combination particularly reliable.
How to Configure Kubernetes for Elixir’s Unique Clustering Needs
Getting Elixir nodes to find and talk to each other inside Kubernetes requires specific configuration that does not come out of the box. If your application uses Elixir’s native clustering, whether for distributed caching, global process registries, or cross-node GenServer calls, you need to make Kubernetes aware of it.
The standard approach uses libcluster with the Cluster.Strategy.Kubernetes.DNS strategy. This relies on a Kubernetes headless Service, which returns the IP addresses of individual pods rather than routing through a single virtual IP. Pods use DNS lookups to discover each other and form a cluster.
A few configuration requirements are worth knowing upfront:
- Set subdomain and hostname on your pod spec so each pod gets a stable DNS identity.
- Use StatefulSet instead of Deployment when stable pod names matter for cluster membership.
- Open port 4369 (EPMD) and your distribution port range in your container’s security group or network policy.
- Set RELEASE_DISTRIBUTION=name and RELEASE_NODE to a fully qualified DNS name in your environment variables.
Without these settings, nodes will start but never connect. The cluster silently stays as a set of isolated singletons, which causes subtle bugs that are difficult to trace under load. This is one of the areas where it pays to hire Kubernetes developers who have handled Elixir-specific topologies before, rather than relying on general Kubernetes experience alone. Getting this layer right at the start saves significant rework later, particularly when the system moves from a single-region setup to a multi-zone deployment.
Containerising Elixir Applications: Docker, OTP Releases, and Image Size
Packaging an Elixir application for Kubernetes requires a specific build process that keeps the deployable file small and self-contained. mix release is the correct tool for building production Elixir containers. It compiles your application and its dependencies into a self-contained OTP release that does not require Elixir or Mix to be installed in the final image.
A multi-stage Dockerfile keeps image sizes manageable. The builder stage installs Elixir, compiles the release, and discards the build tooling afterwards. The runtime stage starts from a minimal Debian or Alpine base and copies only the compiled release. Final images typically land between 50MB and 120MB depending on your dependencies.
One thing to get right early: set COOKIE to a consistent value across all pods using a Kubernetes Secret. Nodes with mismatched cookies refuse to connect. It is a simple configuration step that causes a disproportionate amount of debugging time when skipped.
Health Checks, Graceful Shutdowns, and Rolling Deploys in Kubernetes
Kubernetes needs to know when your application is ready to serve traffic and when it is safe to shut it down, and Elixir requires more care here than most other languages. It relies on liveness and readiness probes to manage the pod lifecycle. For Elixir applications, the readiness probe should confirm that your application is fully started and that any clustering or warm-up work is complete before Kubernetes routes traffic to the pod.
A simple HTTP endpoint at /health that returns 200 OK works well for stateless services. For clustered applications, consider returning a non-200 status until the node has joined the cluster, preventing Kubernetes from sending requests to an isolated node.
Graceful shutdown matters more with Elixir than with many other runtimes because BEAM processes can hold state in memory. Set terminationGracePeriodSeconds to a value that gives your application time to drain in-flight requests and flush any in-memory state before the pod is killed. Thirty to sixty seconds is a reasonable starting point for most workloads.
When to Stick with Elixir’s Native Distribution Instead of Kubernetes
Kubernetes is infrastructure overhead, and sometimes the simpler choice is to let Elixir manage its own infrastructure without Kubernetes involved at all. For teams running a small number of Elixir nodes that need to communicate heavily with each other, native BEAM distribution without Kubernetes is often the simpler choice.
| Native BEAM Distribution | Kubernetes | |
| Best for | Fixed node count, real-time state sharing | Variable scale, multi-region, mixed workloads |
| Latency | Lower, direct node-to-node | Higher, routed through load balancer |
| Complexity | Lower operational overhead | Higher, requires specialist configuration |
| Debugging | Simpler, fewer moving parts | More tooling required |
| Tooling | libcluster + DNS or gossip | libcluster + headless Service + StatefulSet |
If you are building a real-time system where nodes share state through distributed process registries like Horde or Syn, and your deployment target is a fixed set of machines or a single cloud provider with predictable capacity, a bare VM deployment with libcluster and a DNS or gossip strategy may serve you better. You get lower latency between nodes, simpler debugging, and fewer moving parts.
Kubernetes adds value when you need multi-region deployments, automated bin packing, or integration with a broader platform ecosystem. It adds friction when your primary concern is tight inter-node communication at low latency. Teams evaluating this decision often find it worth bringing in Elixir developers for hire who can assess the architecture objectively before the infrastructure choices are locked in. Choosing based on your actual operational requirements, not on what appears on most architecture diagrams, leads to better outcomes.
Practical Checklist: Is Your Team Ready to Run Elixir on Kubernetes?
Before committing budget and time to this stack in production, use the following to gauge whether your team has the right skills and setup in place:
- Your team understands OTP release configuration and can build reproducible Docker images with mix release.
- You have decided whether your application needs native Elixir clustering or can run as stateless pods.
- If clustering is required, headless Services and libcluster DNS strategy are configured and tested locally with multiple pod replicas.
- Liveness and readiness probes are in place and tested against real failure scenarios, not just happy paths.
- Graceful shutdown periods are set and validated under load.
- Cookie values are stored in Kubernetes Secrets and injected consistently across all pods.
- Your CI/CD pipeline builds OTP releases, not raw Elixir source, and pushes versioned images.
If you are building a team around this stack, look for engineers who have worked with non-standard clustering topologies, not just those experienced with stateless web services.
Conclusion: Choosing the Right Abstraction Layer for Your Elixir Stack
The question is never whether Elixir or Kubernetes is a good technology. Both are. The question is whether the problems each one solves match the problems you actually have.
Elixir on Kubernetes works well when workloads are containerisable, deployments are frequent, and teams already operate Kubernetes infrastructure for other services. It works less well when native BEAM distribution is at the core of your architecture, and Kubernetes adds complexity without a corresponding operational benefit.
Teams looking to expand their engineering capacity should look for engineers who understand both sides of this trade-off and can reason about where the infrastructure boundary belongs. That knowledge, more than any specific tooling preference, determines how well a system holds up under real production conditions.