BEAM hosting integration (Elixir/Phoenix, Erlang, Gleam)

[naratteu]

Overview

The toolkit hosts a good spread of non-.NET runtimes — Golang, Rust, Java, Deno, Perl, plus the Python and JavaScript extensions — but nothing on the BEAM. Elixir, Erlang and Gleam are missing, and there is no existing issue or discussion for any of them.

Elixir is the one I would most like to see, specifically for running a Phoenix web server as an Aspire resource. Phoenix is a common choice for the real-time tier of an otherwise .NET system, and today wiring one into an app host means dropping to AddExecutable and hand-rolling the build step, the port wiring and the secret.

The pairing is better than "another runtime we could support":

• Phoenix reads its port from the environment, so it slots into Aspire's endpoint allocation without any shim.
• Elixir has first-class OpenTelemetry (opentelemetry_exporter), so a Phoenix resource can export straight into the Aspire dashboard's OTLP endpoint rather than being a black box next to the .NET services.
• mix deps.get is the same shape as the go.mod installer resource the Golang integration already models, so there is precedent in this repo for the dependency step.

Usage example

var builder = DistributedApplication.CreateBuilder(args);

var db = builder.AddPostgres("pg").AddDatabase("appdb");

var secretKeyBase = builder.AddParameter("phx-secret-key-base", secret: true);

var web = builder.AddElixirApp("web", "../my_phoenix_app")
                 .WithMixDepsGet()
                 .WithHttpEndpoint(env: "PORT")
                 .WithEnvironment("SECRET_KEY_BASE", secretKeyBase)
                 .WithReference(db)
                 .WaitFor(db);

builder.AddProject<Projects.Api>("api")
       .WithReference(web);

builder.Build().Run();

AddElixirApp would default to mix run --no-halt; a Phoenix app wants mix phx.server, which could either be the argument or a thin wrapper:

builder.AddElixirApp("web", "../my_phoenix_app", args: ["phx.server"]);

// or, if a Phoenix-aware helper is worth it:
builder.AddPhoenixApp("web", "../my_phoenix_app");

Erlang and Gleam fit the same shape, if the integration is scoped to the BEAM rather than to Elixir alone:

builder.AddErlangApp("worker", "../my_rebar_app");   // rebar3 shell / release
builder.AddGleamApp("edge", "../my_gleam_app");      // gleam run

Additional context

Design points I would expect to come up:

• Dev vs release. mix phx.server is the dev loop; mix release produces _build/<env>/rel/<app>/bin/<app> start. The former is what an app host wants, but the latter is what publish would need, so the resource probably has to know about both rather than hardcoding one.
• MIX_ENV. Defaults to dev, and a lot of Phoenix behaviour keys off it. Worth being explicit rather than inherited.
• Phoenix-specific environment. PORT, PHX_HOST, SECRET_KEY_BASE are the three that always need wiring; SECRET_KEY_BASE belongs in a secret parameter.
• Scope. One Hosting.Elixir integration with Erlang and Gleam as siblings, or a single Hosting.Beam covering all three? Elixir alone would cover the common case, and I do not know which the maintainers would prefer.

I do not know Elixir well enough to claim the design above is idiomatic — it is written to match the existing Golang and Deno integrations rather than from Elixir experience, so pushback from someone who ships Phoenix would improve it.

Help us help you

No, just wanted to propose this.