# LiveDebugger: a browser debugger for Phoenix LiveView > LiveDebugger is an Elixir library from Software Mansion that opens a debugger UI for Phoenix LiveView at localhost:4007. It is a dev-only tool with a narrow feature set and a clear boundary: it must never run in production. **software-mansion/live-debugger** — Tool for debugging LiveView applications - Repository: https://github.com/software-mansion/live-debugger - Website: https://docs.swmansion.com/live-debugger/ - Stars: 765 · Forks: 30 - Language: Elixir - License: Apache-2.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/software-mansion-live-debugger ## What LiveDebugger solves for LiveView developers A Phoenix LiveView process keeps its state in assigns and rebuilds HTML on the server after every event. When a page behaves incorrectly, the evidence is spread across process state, the component tree, and the order in which callbacks fired. Standard Elixir tooling shows you a process and its mailbox; it does not show you which LiveComponent owns which assign or which callback ran in what order. LiveDebugger targets exactly that gap. The README lists four capabilities: seeing the LiveComponents tree, viewing assigns, tracing and filtering callback executions, and inspecting elements. It is aimed at developers already working inside a Phoenix LiveView application, and the README is explicit that it should not be used on production, instructing you to keep the dependency dev-only. That constraint is the tool's identity, not a footnote. ## How the debugger attaches to a running app The mechanism is a dependency plus a script tag. You add live_debugger to your deps, and you add a line to the application root layout that renders Application.get_env(:live_debugger, :live_debugger_tags). According to the README, that tag attaches a meta tag and the LiveDebugger scripts in the dev environment, which is what enables the browser features. Without it, the browser side has nothing to talk to. The debugger then runs as a separate endpoint on a default port of 4007, so your application keeps serving on its own port while the debugger UI lives beside it. The repository layout backs this up: there is a lib/ directory for the library, a dev/ directory holding a sample application, an assets/ directory for the front-end, a devtools/ directory for the browser extension, and an e2e/ directory. The DevTools extension, available since v0.2.0 for Chrome and Firefox, is an alternative front end to the same runtime, and the README warns that the browser plugin alone is not enough: the mix dependency still has to be present. ## Installing LiveDebugger with Mix or Igniter The README gives two installation routes. The standard one is a Mix dependency, pinned to the 1.0 series and marked dev-only: ```elixir defp deps do [ {:live_debugger, "~> 1.0.0", only: :dev} ] end ``` The only: :dev option is what keeps the dependency out of a production release, and the README repeats the warning that LiveDebugger should not be used on production. After adding the dependency, the README recommends one more edit in the application root layout so the browser features work: ```elixir # lib/my_app_web/components/layouts/root.html.heex <%= Application.get_env(:live_debugger, :live_debugger_tags) %> ``` Start your application as usual, and the README states LiveDebugger will be running at the default port http://localhost:4007. The second route is Igniter, which performs both edits for you: ```bash mix igniter.install live_debugger ``` The README says this command adds the LiveDebugger dependency and modifies root.html.heex automatically. If you are contributing to the library itself rather than using it, the README documents a separate flow: mix setup followed by iex -S mix, which runs the application declared in the dev/ directory with the library installed. LiveReload works for .ex files and static files, and the README suggests mix assets.build:dev if some styles do not show up. ## The production boundary and other limits The most important limitation is stated by the project itself: LiveDebugger should not be used on production, and the dependency should be dev-only. A tool that renders assigns and traces callbacks exposes internal state, and the README's instruction to keep it out of production releases is the practical expression of that. Treat any setup where the dependency is not scoped to :dev as a mistake. The second limit is scope. This is a debugger for Phoenix LiveView specifically, not a general Elixir debugger and not a tool for other stacks. If your problem lives in a plain GenServer, a background job, or a non-LiveView controller, the four listed capabilities (component tree, assigns, callback tracing, element inspection) do not address it. The README also does not document rollback or uninstall steps; removing the dependency entry and the layout line is implied by the installation instructions but not written out. Configuration beyond the defaults is not covered in the README either: it points to a separate Configuration Guide for customizing the tool. ## How it differs from generic debugging and from Dynatrace The obvious alternative is the tooling you already have: IEx, Logger output, and the Phoenix LiveView debug annotations that ship with the framework. Those are always available and require no extra dependency, but they are not interactive: you read logs and inspect processes rather than browsing a component tree or filtering callback executions in a UI. LiveDebugger trades that zero-setup property for a browser view of the same runtime. A second comparison matters because search traffic about "live debugger" often means something else entirely. Dynatrace Live Debugger and Datadog's live debugger are production observability products: they attach to running production systems to capture snapshots of code execution without redeploying. LiveDebugger is the opposite by design. It is a local development tool, installed as a dev-only dependency, and the README forbids production use. If your requirement is inspecting a production incident, this project is not the answer, and the naming overlap is a trap worth knowing about. ## Maintenance, releases and licence The repository is not archived, and the last push was on 2026-09-10, which is recent. Releases are versioned and dated: v1.0.2 on 2026-07-15, v1.0.1 on 2026-06-03, and v0.8.1 on the same day as v1.0.1. The README pins the recommended dependency constraint at "~> 1.0.0", so upgrades inside the 1.x line are the expected path, and the CHANGELOG.md at the repository root is where changes are recorded. The README also links a discussion page for upcoming plans rather than promising a roadmap in the repository itself. The licence is Apache-2.0, which permits commercial use and modification subject to its notice and attribution conditions. That is a permissive licence, but licence compatibility with your own distribution model is a question for your legal team, not for this article. The upgrade cost is low by construction: a dev-only dependency that is absent from production builds cannot break a release, and the main recurring work is keeping the mix.exs constraint current. ## Conclusion Adopt LiveDebugger if you work on a Phoenix LiveView app and want to see the LiveComponents tree, assigns and callback executions in a browser instead of guessing from logs; the Apache-2.0 licence and the dev-only dependency declaration make that low risk. Do not adopt it for production inspection, for non-LiveView Elixir code, or for React Native and other stacks, since the README scopes it to Phoenix LiveView and states it should not be used on production. Before relying on it, verify that your mix.exs pins it with only: :dev, that the live_debugger_tags line is present in root.html.heex, and that port 4007 is free on your machine. ## FAQ ### How do I activate LiveDebugger? Add {:live_debugger, "~> 1.0.0", only: :dev} to your deps in mix.exs and add the live_debugger_tags line to your application root layout. After starting your application, the README states the debugger runs at http://localhost:4007 by default. ### What is LiveDebugger? It is a browser-based tool for debugging applications written in Phoenix LiveView, created by Software Mansion. It shows the LiveComponents tree, assigns, callback execution traces and element inspection, and it should not be used on production. ### Can I install LiveDebugger on Windows, macOS or Linux? The README does not discuss operating systems. Installation is described through Mix and Igniter, and there is a Chrome and Firefox DevTools extension, so the practical requirement is a working Elixir and Phoenix LiveView project plus a supported browser. ### Do I need the browser extension to use LiveDebugger? No. The extension, available since v0.2.0 for Chrome and Firefox, is an option, and the README notes that the plugin alone is not enough because the main dependency must still be added to your Mix project. ### Where can I find the LiveDebugger documentation? The README points to the project documentation site and to HexDocs, including a features overview and a separate configuration guide. A LiveDebugger Tour repository is also linked for a quick introduction. ## Sources - [License: Apache-2.0](https://github.com/software-mansion/live-debugger/blob/main/LICENSE) - [Project website](https://docs.swmansion.com/live-debugger/) - [README](https://github.com/software-mansion/live-debugger/blob/main/README.md) - [Releases](https://github.com/software-mansion/live-debugger/releases) - [software-mansion/live-debugger on GitHub](https://github.com/software-mansion/live-debugger) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/software-mansion-live-debugger