LiveDebugger: a browser debugger for Phoenix LiveView, installed as a dev-only Mix dependency
Tool for debugging LiveView applications
At a glance
- What is it?
- LiveDebugger is an Elixir package from Software Mansion that runs a separate web UI on port 4007 to show your LiveComponents tree, assigns and callback traces. It is usable only in dev, and the README is explicit about that.
- Who is it for?
- Adopt LiveDebugger if you are developing a Phoenix LiveView app in Elixir and want to see assigns, component nesting and callback traces without adding IO.inspect calls. Do not install it outside :dev, and do not expect the browser extension to work on its own.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Elixir, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap LiveDebugger fills in a LiveView development loop
A LiveView process keeps state in assigns and re-renders over a socket connection. When a component shows the wrong value, the usual options are IO.inspect in a callback, a breakpoint in IEx, or reading the rendered HTML. None of those show the component tree as a tree. LiveDebugger is aimed at that moment: the README lists four browser features, a LiveComponents tree, assigns viewing, tracing and filtering of callback executions, and element inspection. It is built for developers working on Phoenix LiveView applications in Elixir, and it lives in the dev environment rather than in a test or production setup. The project is maintained by Software Mansion, the agency behind it, and is published on Hex as live_debugger under Apache-2.0.
What actually runs when you start your app
The mechanism is a second endpoint. The README states that after you start your application, LiveDebugger runs at http://localhost:4007 by default. That is separate from the port your own Phoenix app binds to, so the debugger UI is a parallel surface rather than a panel inside your application's pages. Two things feed it. First, the dependency itself, added to mix.exs, which is what instruments the running LiveView processes. Second, a snippet placed in the root layout head, Application.get_env(:live_debugger, :live_debugger_tags), which the README says attaches a meta tag and LiveDebugger scripts in the dev environment and enables the browser features. The README notes that the browser plugin alone is not enough, so the extension is a client for a server that the Mix dependency provides. The four capabilities listed (tree, assigns, callback tracing and filtering, element inspection) are the surface of that server. The README does not describe how the instrumentation attaches to LiveView callbacks internally, so treat the tracing implementation as undocumented in the material available.
Installing it: two paths and the exact lines involved
The manual path is a dependency entry plus a layout edit. In mix.exs, the README gives {:live_debugger, "~> 1.0.0", only: :dev}. The only: :dev option is not decoration. The README carries an IMPORTANT note saying LiveDebugger should not be used on production and that the dependency must be dev-only. The layout change goes in lib/my_app_web/components/layouts/root.html.heex, inside the head element, and the README calls this the way to get the full experience because it enables the browser features. The second path is Igniter, the code-generation tool from the Ash project. Running mix igniter.install live_debugger adds the dependency and modifies root.html.heex automatically, per the README. If your project already uses Igniter, that single command replaces both manual steps. If it does not, adding Igniter to get one dependency installed is a larger change than the two edits it saves. Configuration beyond that is deferred to a separate Configuration Guide page on hexdocs, which the README links but does not reproduce, so the available config keys are not visible in the repository README itself.
The extension is optional, and the docs say so twice
Since v0.2.0 there is an official DevTools extension for Chrome and Firefox, listed in the README with store links. The stated purpose is to interact with LiveDebugger features alongside your application's runtime, which suggests the extension is a convenience layer over the same data the port 4007 UI already exposes. The README adds a NOTE telling you to ensure the main dependency is in your mix project, because the browser plugin alone is not enough. That is a deliberate repetition of the same constraint stated for the Mix install, and it matters for how you evaluate the tool: there is no browser-only mode. A team that cannot add the dependency for policy reasons gets nothing from the extension. For contributors, the README gives a separate loop: mix setup followed by iex -S mix runs the application declared in the dev/ directory with the library installed. LiveReload works for .ex files and static files, and the README offers mix assets.build:dev as the fix when styles do not appear.
Where LiveDebugger is the wrong tool
The dev-only constraint is the first limit, and the README states it rather than implying it. Anything you want to observe in a staging or production environment is out of scope by design. The second limit is the port. Port 4007 is a default, and a second web server means a second thing bound to localhost; the README points to a Configuration Guide for changing behaviour but does not list the key names inline, so you cannot confirm from the README alone how to move that port. The third limit is scope. LiveDebugger targets Phoenix LiveView. If your problem is in an Ecto query, a GenServer, an Oban job or a plain controller action, the four listed features do not cover it, and you are back to IEx and Logger. The fourth is the layout requirement: the extra features depend on a snippet in the root layout head, so an application that renders its own head structure differently, or serves multiple layouts, needs to work out where that line belongs. The README shows one location and one form of the line.
How this differs from Erlang observer and IEx.pry
The obvious comparison is the tooling already in the Elixir and Erlang distributions. observer and observer_cli show processes, memory and message queues for the whole node. They are process-level and know nothing about LiveView semantics: a LiveView socket process looks like any other process, and assigns are just terms inside its state. IEx.pry stops execution at a breakpoint so you can inspect bindings in a shell. LiveDebugger takes a third position. It stays inside the LiveView abstraction, presenting a LiveComponents tree and assigns for a running app, and it does that in a browser tab rather than a terminal, which is why the README pairs it with a DevTools extension. The trade-off is depth against framing. observer and IEx.pry will show you anything on the node; LiveDebugger shows you the LiveView concepts it was built around, and only while the dependency is present in dev. If your bug is in a LiveView callback, the framing is the point. If it is in a process that has nothing to do with LiveView, the framing is a wall.
Version, licence and what maintenance looks like
The repository is active, not archived, and the most recent release in the material is v1.0.2, dated 2026-07-15, with v1.0.1 and v0.8.1 both dated 2026-06-03. The jump from 0.8.1 to 1.0.x on the same day suggests a stabilisation point rather than a long 1.x history, so pinning at ~> 1.0.0 (as the README's own example does) is consistent with how the project presents itself. The licence is Apache-2.0, which permits commercial and closed-source use with the usual obligations around notices and the licence text; that is a summary of the licence family, not legal advice, and if your organisation has a dependency policy you should read LICENSE in the repository. The cost of adoption is small and mostly one-time: a dependency line, a layout line, and a port. The recurring cost is the dev-loop overhead of a second running endpoint and the need to keep the dependency dev-only in every environment, which is enforced by the only: :dev option rather than by the tool itself. The README points to a discussion page for upcoming plans, and to a separate LiveDebugger Tour repository for learning the interface, so the learning material lives outside the main repo.
Editorial conclusion
Adopt LiveDebugger if you are developing a Phoenix LiveView app in Elixir and want to see assigns, component nesting and callback traces without adding IO.inspect calls. Do not install it outside :dev, and do not expect the browser extension to work on its own. Before committing, verify three things: that the dependency resolves at ~> 1.0.0 against your Phoenix LiveView version, that the Application.get_env(:live_debugger, :live_debugger_tags) line renders inside the head of lib/my_app_web/components/layouts/root.html.heex, and that port 4007 is free in your local setup.
Community notes