Backpex generates admin CRUD views for Phoenix LiveView apps

Admin panels as a Phoenix library, not a generator

Backpex is described as a highly customizable administration panel for Phoenix LiveView applications. The goal is to create CRUD views for existing data quickly, using configurable LiveResources, and to integrate with an existing Phoenix application rather than replace it.

The word configurable is doing the work here. A LiveResource is a module you define for a table, and from that definition Backpex derives the listing, the forms, the filters and the actions. You can bring your own layout or use the components the library ships, and you can extend it with your own layouts, views, field types and filters.

The audience is a Phoenix developer who has an application with Ecto schemas and needs an internal tool over them. That is a common need that is awkward to satisfy with general purpose admin frameworks, because those tend to impose their own authentication, their own routing and their own template layer. Backpex deliberately stays inside the LiveView conventions of the host application.

The project is published on Hex as backpex, the documentation is on hexdocs.pm/backpex, there is a live demo at backpex.live, and the licence is MIT.

Seven pieces of machinery, each of them a module

The feature list in the README is short enough to be a design sketch, and each item maps onto a specific mechanism.

LiveResources are the core. You create a LiveResource module for a database table and get a CRUD view with customization. Search and filters come next: you define which fields are searchable and add custom filters, and the results update in the LiveView without a full page load. Resource actions are global custom actions such as user invitations or exports, and they can carry additional form fields of their own.

Authorization is handled through simple pattern matching for CRUD and for custom actions, with optional integration for external authorization libraries. The pattern matching approach is worth understanding before you commit: it means the library calls into your code to decide, so you can implement any policy, but you have to implement it.

Field types come out of the box for Text, Number, Date, Upload and more, and you can add your own field type modules. Associations cover HasOne, BelongsTo and HasMany(Through) with minimal configuration, and you can control which options are available and which columns are rendered. Metrics add value calculations such as sums or averages for quick data insight, with more metric types described as on the horizon.

The README points to the docs instead of showing code

One thing to be clear about before you clone anything: the README does not contain an installation snippet. It links to a comprehensive installation guide at hexdocs.pm/backpex/installation.html and to the general documentation, plus three explanatory pages, what is Backpex, why we built Backpex, and contribute to Backpex.

So the dependency and the wiring steps live in the hosted documentation rather than in the repository front page. If you are evaluating the library from the repository alone, you are evaluating the feature list and the documentation index, not the API.

The repository itself is a Mix project, with mix.exs and mix.lock at the root, config, lib, priv, test and scripts directories, a demo application under demo/, and guides. There is also a Dockerfile, a compose.yml, a .docker directory, a package.json and a bun.lock, which is the sign that the asset pipeline is part of the build rather than something you wire up afterwards.

The default branch is develop, and the documentation link in the README for the licence file points at the main branch, so the two branches are both in use.

The JavaScript side is a separate package with its own tests

The package.json in the repository root is interesting because it is not the Elixir package. It describes a JavaScript bundle named backpex at version 0.18.0, published with both an ES module and a CommonJS entry point, and the files it ships are the README, the licence, the built JavaScript in priv/static/js and the sources under assets/js.

The scripts show a Bun based workflow with the standard JavaScript linter:

  "scripts": {
    "format:standard": "standard assets/js test/js --fix",
    "lint:standard": "standard assets/js test/js",
    "test:js": "bun test test/js"
  },

The runtime dependency list is short, with imask at 7.6.1 as the only production dependency, which is the masked input library used for form fields.

The globals the linter is told about are a good clue to what the client code does: localStorage, sessionStorage, IntersectionObserver, requestAnimationFrame and getComputedStyle. That is a component library that keeps some state in the browser, observes viewport changes, schedules animation frames and reads computed styles, which is what you would expect from a LiveView component set that has to behave like a normal web app.

Note the version number here is 0.18.0 while the published Hex releases have reached 0.22.0. The two are separate artifacts, and the gap tells you the JavaScript package is versioned on its own schedule.

Running the demo stack with compose

The compose file shows what a working development environment needs, and the startup sequence is a useful checklist for anyone self hosting.

The app service builds from the repository with a builder target and MIX_ENV set to dev. Its startup commands run in order: fetch the dependencies and create and migrate the database, install the JavaScript packages with a frozen lockfile, install Chromium for Playwright with its dependencies, run the asset setup task, and then a command that reinstalls dependencies in the demo directory.

      STARTUP_COMMAND_1: mix do deps.get + ecto.create + ecto.migrate
      STARTUP_COMMAND_2: bun install --frozen-lockfile
      STARTUP_COMMAND_3: bun x playwright install chromium --with-deps
      STARTUP_COMMAND_4: mix assets.setup

The app depends on a postgres service that is checked with pg_isready before the app starts, and the ports are published through environment variables with a default of 0, so nothing is exposed to the host unless you set a value. A named volume caches the Playwright browsers between runs.

One thing to note if you copy this file: the compose configuration carries a literal SECRET_KEY_BASE and LIVE_VIEW_SIGNING_SALT value. Those are fine for a local demo, and they should be replaced with your own secrets for anything shared, because the salts are what sign LiveView sessions.

The container pins Elixir, Erlang, Ubuntu and Bun

The Dockerfile is more careful about versions than most, and every toolchain version is an argument with a comment explaining which tool updates it.

ARG ELIXIR_VERSION=1.20.4
ARG OTP_VERSION=29.1.1
ARG UBUNTU_VERSION=resolute-20260927
ARG BUN_VERSION=1.4.2

The base image is the official Elixir image for that Elixir and Erlang version on that Ubuntu release, and the runtime image is plain Ubuntu of the same release. The build stage installs build-essential, curl, git, inotify-tools and watchman, then adds Node.js from the NodeSource setup script and Bun from its own installer, pinning Bun to the version given by the argument.

The environment sets MIX_HOME, HEX_HOME and APP_HOME, and enables the Erlang shell history flag. The watchman and inotify-tools packages are the file watching dependencies that a Phoenix development server needs, so the image is set up for live reload rather than only for a production build.

The result is an environment where the Elixir version, the Erlang version, the Ubuntu release and the JavaScript runtime are all pinned and all updated by an automated dependency bot, which is the pattern you want if you intend to run this in CI.

A fast moving project with a large surface area

The release history shows a project shipping often. Version 0.22.0 was tagged on 2026-10-07, 0.21.0 on 2026-09-29 and 0.20.0 on 2026-08-14, and the repository is not archived with the last push on 2026-10-19.

Two details in the repository root point at how the project is developed. There is a .claude directory, a .claude-plugin directory, a .mcp.json file, an AGENTS.md, a CLAUDE.md and a usage_rules.md file, which together suggest the project is worked on with coding agents and publishes a plugin and a model context protocol configuration. There is also a .credo.exs for Credo, the Elixir static analysis tool, and a .sobelow-conf for Sobelow, the security scanner. The presence of both is a reasonable signal about what the maintainers check before a release.

The version numbers are still below 1.0, which in Elixir usually means the public API is not frozen. For a library you will declare resources against, that is the thing to plan for: expect to adjust your declarations when you upgrade, and read the changelog rather than assuming a minor bump is cosmetic.

The MIT licence keeps the legal side uncomplicated, and any specific question about it belongs with your own counsel.

Editorial conclusion

Backpex suits a Phoenix team that needs an internal administration panel for its own tables and would rather declare resources than hand write LiveViews, since a LiveResource module plus configurable fields replaces a pile of templates. It is the wrong choice if you need a general purpose admin framework with authentication, roles and audit logging built in, because authorisation is delegated to your own code and the shipped defaults are for Tailwind and daisyUI. Before adopting it, read the installation guide on hexdocs.pm/backpex, declare one LiveResource for a table you already understand, and check that the components it renders match the styling your application already uses.

Frequently asked questions

Official sources

1. License: MIT
2. naymspace/backpex on GitHub
3. Project website
4. README
5. Releases