Overview

Phoenix is a free, open-source web framework for the Elixir programming language, built for the server-side MVC pattern and released under the MIT licence. Chris McCord started it in 2014 as a way to bring the productivity of frameworks like Ruby on Rails to the Erlang virtual machine, and that combination is still the pitch: familiar controllers, views and routing on one side, and the BEAM’s lightweight processes, supervision trees and fault tolerance underneath. A Phoenix application is a normal Mix project, so it is generated, compiled, tested and released with the standard Elixir tooling rather than a bespoke CLI. The current release is 1.8.16, published on 20 October 2026, and the framework is among the most downloaded packages on Hex with roughly 160 million downloads across 183 versions.

Key Features

• Phoenix LiveView — interactive, stateful user interfaces rendered on the server and streamed over a WebSocket, so a rich page can be written in Elixir with no separate JavaScript application to build and deploy.
• Channels and PubSub — a built-in publish/subscribe layer and socket abstraction for real-time features such as chat, notifications and collaborative editing, working the same way across one node or a cluster.
• Presence — tracks who is connected to what right now, across every node in a cluster, without an external service such as Redis or a separate presence server.
• HEEx templates — HTML with embedded Elixir, compiled ahead of time into fast functions, with function components, slots and change tracking that lets LiveView send only the parts of a page that actually changed.
• Generators — mix phx.gen.html, phx.gen.json, phx.gen.live and phx.gen.auth scaffold CRUD screens, JSON APIs, LiveView pages and a complete authentication system from a schema description.
• Ecto integration — the generated project is wired to Ecto with PostgreSQL by default, and the same migrations, schemas and changesets work against MySQL, SQLite or SQL Server with a different adapter.
• LiveDashboard and telemetry — every application ships with a development dashboard for performance metrics, request logs and running processes, plus the :telemetry events needed to plug into Prometheus, StatsD or OpenTelemetry.
• Releases and containers — mix phx.gen.release produces a self-contained OTP release, optionally with a Dockerfile, so a Phoenix application is deployed as one binary tree with no runtime interpreter to manage.
• Development reloading — code changes recompile and the browser refreshes without restarting the server, and LiveView state survives the recompile.

Why Use Phoenix?

The framework’s argument is that a single language and a single runtime should cover the whole application: request handling, background work, WebSocket traffic and the interactive front end. Because LiveView keeps UI state on the server and pushes DOM diffs to the browser, a team can build dashboards, forms and live-updating lists without maintaining a second JavaScript application, an API contract between the two, and the state synchronisation that goes with it. Underneath, everything inherits the Erlang VM’s model — processes are cheap, supervised and isolated, a crashed request handler does not take the node down, and horizontal scaling means adding nodes to a cluster rather than re-architecting the state layer. The trade is Elixir itself: the language is small and pleasant, but functional programming, pattern matching and the actor-style concurrency model are a real learning curve for developers coming from object-oriented frameworks, and hiring is a narrower pool than for Python, PHP or Ruby. The documentation, the official guides and the Phoenix LiveView book are thorough, and the community is unusually helpful, which shortens that ramp considerably.

Use Cases

• Real-time dashboards and monitoring consoles that push updates to many connected browsers.
• Chat, notifications, presence and collaborative editing features built on Channels and PubSub.
• JSON and GraphQL APIs, generated with mix phx.gen.json or built with Absinthe, for mobile and single-page clients.
• Server-rendered web applications that need interactivity without a JavaScript build pipeline.
• High-connection-count services — WebSocket fan-out, IoT ingestion, live sports or trading feeds — where the BEAM’s process model does the heavy lifting.
• Teams already writing Elixir for background jobs or data pipelines that want the web layer in the same language.

Getting Started

Phoenix needs Elixir, which brings Erlang/OTP with it; the phx_new project generator itself requires Elixir 1.18 or newer, while generated applications target Elixir 1.15 and later. Install the generator once with mix archive.install hex phx_new, then create a project with mix phx.new demo, fetch dependencies with mix deps.get, set up the asset tooling with mix assets.setup, and start the development server with mix phx.server. The scaffolded application answers on http://localhost:4000 with a welcome page, and from there mix ecto.create provisions the PostgreSQL database the default project expects.

The bundled guides cover routing, controllers, Ecto changesets, authentication, testing with Phoenix.ConnTest and deployment as an OTP release. On Debian and Ubuntu, Elixir and Erlang are packaged, so no version manager is strictly required, though most teams use asdf or mise to pin a specific OTP and Elixir pair per project.

Related reading in this directory

Phoenix is written in Elixir, so that listing is the natural starting point for the language itself. For the same server-side MVC role in other ecosystems, compare Django in Python, Laravel in PHP, or the lighter Flask and FastAPI when a full-stack framework is more than the job needs.