Phoenix LiveDashboard: a debugging tool with one release tag, four years behind its own install instructions

Nine modules, each answering one question about a running node

The feature list is nine bullets and each is a scope statement rather than a feature description. Home gives general system information. OS Data covers CPU, memory and disk. Metrics visualizes `:telemetry` events as real-time charts, which is the module that makes the dashboard useful in a project that has already instrumented itself properly.

The next four are all variations on the same idea, inspecting the runtime. Applications lets you filter and search the applications on the current node and view their processes in a supervision tree. Processes, Ports and Sockets each do the same for their own resource type, with the README annotating Ports as responsible for I/O and Sockets as responsible for TCP and UDP. ETS covers in-memory tables. Ecto Stats shows index, table and general usage information about the underlying Repo.

The item that changes how you use the dashboard is the last paragraph before the screenshot: it also works across nodes. If your nodes are connected via Distributed Erlang, you can inspect information on node B while sitting on node A. For a clustered Phoenix deployment that turns a per-node tool into a fleet tool, and it is the single feature most worth checking against your own topology, since it depends on distribution being configured with cookies and names rather than merely being reachable.

The install asks for 0.7 and the newest tag is 0.2.6

Step one of the installation is adding a dependency:

def deps do
  [
    {:phoenix_live_dashboard, "~> 0.7"}
  ]
end

Now look at the release history on this repository. There is exactly one release tag: v0.2.6, published on 2020-06-03, with an empty release body. There is no 0.3, no 0.4, none of the intermediate versions, and no 0.7. The repository itself is not archived, and it was pushed on 2026-09-16, so the code is clearly being worked on.

Both facts are true and they are not in conflict, because a Hex package does not have to be tagged on GitHub to be published. The `~> 0.7` constraint resolves from hex.pm, and the maintainers appear to have stopped mirroring releases back into GitHub tags some time after 0.2.6. The practical consequence is that anything reading this repository's release list will conclude the project is a decade-old 0.2 release, which is the wrong picture. Conversely, if you pin by tag you will pin to code from 2020.

Two things follow for an evaluator. Check hex.pm for the current version rather than the GitHub releases page, and read the CHANGELOG.md file in the tree, which is where a project that stopped tagging will record what changed.

The README is a stub that hands off to hexdocs

The README is bracketed by `<!-- MDOC !-->` comments near the top and again before the contributing section. Those markers mean the file is generated from or synchronized with the documentation, and the practical effect is that the module list you just read is the entire feature documentation. There is no section on configuring the Metrics module's telemetry list, no explanation of what the Ecto Stats module queries or how expensive that is, and no note on how the node filter works when you have many.

Everything else lives at hexdocs.pm/phoenix_live_dashboard, which the README links as Online Documentation at the top. That is a reasonable split for a library inside a well-documented ecosystem, and Phoenix's own guides assume you are comfortable reading module docs. But it does mean the GitHub page is not where you evaluate the tool.

One link in the installation section is worth flagging. The guidance for running behind a proxy points at an article on configuring Nginx with Phoenix and WebSockets, and the URL is a web.archive.org snapshot dated 2017. The archived page is from a decade before LiveDashboard existed, so it may or may not reflect current WebSocket proxy requirements. If you deploy behind Nginx, verify the upgrade headers yourself rather than trusting a 2017 mirror.

Three install steps, two of which you probably already have

The README is upfront that this is built on LiveView and that both LiveView and LiveDashboard ship by default as part of Phoenix. So for a project generated by phx.new, steps two and three are mostly already done and what remains is choosing a mount path. The three steps are: add the dependency, configure LiveView, add dashboard access.

Step two means two edits. The endpoint configuration needs a signing salt for live views, and the endpoint needs a socket declaration for the LiveView socket. Both are one-liners, and the README notes you are good to go after them.

Step three is the router, and it is gated on the environment:

if Mix.env() == :dev do
  scope "/" do
    pipe_through :browser
    live_dashboard "/dashboard"
  end
end

Run `mix phx.server` and visit the dashboard path, where the modules are configured from the UI. The default that most people want is the one in that snippet: available in development only.

The extra section covers the other case, using it in production, and it is the part worth reading carefully because the dashboard exposes your entire runtime. It offers two patterns: a proper pipeline with `fetch_current_admin` and `require_authenticated_admin` plugs generated by `mix phx.gen.auth`, and a quick HTTP Basic Auth plug that pulls a username and password from the environment with `System.fetch_env!`. The second is explicitly labelled quick and dirty. The README also reminds you to allow WebSocket upgrades at the proxy, which is the step people forget and then spend an afternoon debugging.

Contributing runs a dev dashboard with Ecto backends you choose

The contributing section describes running a development version of the dashboard from the repository itself, which takes two commands: `mix setup` followed by `mix dev`. Running it as `iex -S mix dev` gives you a shell alongside it.

What makes it interesting is the flag set. The Ecto-related demos are opt-in, one per database engine: `--postgres` for the PostgreSQL repo, `--mysql` for MySQL and `--sqlite` for SQLite. In other words the Ecto Stats module is demonstrated against three different backends from one codebase, which tells you something about how much of that module is portable and how much is query generation per adapter.

There is a housekeeping instruction that suggests contributors hit a specific problem: before submitting a pull request, discard any changes made to the dist directory, with `git restore dist` given as the example. A tracked `dist/` in the tree is a sign that the LiveView assets are compiled and committed so the dashboard can run without a separate asset build. That is convenient for the project and a recurring source of noise in pull requests.

The tree also contains `dev.exs`, `config/`, `test/`, `guides/` and a `traffic.yml` at the root, the last of which is typically a load-testing definition rather than a package manifest. The repository is 2171 stars with 208 forks and 17 open issues.

License and copyright holders named in the README

The final section of the README states MIT License with copyright attributed to three named people, Michael Crumm, Chris McCord and José Valim, with the year 2019. The repository metadata independently reports MIT as the license and the tree contains a LICENSE.md file, so this is one of the few projects where the README, the metadata and the tree all agree.

The three names also explain the shape of the project. José Valim is the creator of Phoenix and Elixir's core team lead, Chris McCord was one of the original Phoenix authors, and Michael Crumm worked on LiveView at Cisco. That is a team that built LiveDashboard because they needed it, which is also the best explanation for why the README is so terse and the hexdocs pages are so thorough.

For anyone weighing alternatives: the thing LiveDashboard does that general APM tools do not is expose BEAM internals in a structured, filterable form. A generic profiler will show you that a request was slow. LiveDashboard will show you which ETS table grew, which process holds a port, or which node in the cluster owns it.

Editorial conclusion

LiveDashboard is the closest thing the BEAM has to a control panel, and its value comes from breadth rather than depth: nine modules that each answer one question about a running node, available across a cluster through Distributed Erlang, installed in three steps that already ship inside a generated Phoenix app. The documentation gap is the real caveat. The README is a stub bracketed by MDOC markers that hands off to hexdocs, the modules are listed with no configuration notes at all, and the one release tag on GitHub has not moved since 2020 even though the install instructions ask for a constraint seven minor versions ahead of it. If you use it in development, read the hexdocs pages for the module configuration options. If you expose it in production, the README's own advice to put authentication in front of it is not optional advice.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. phoenixframework/phoenix_live_dashboard on GitHub
4. README
5. Releases