Best Phoenix (Elixir) Boilerplates in 2026

TL;DR

Phoenix LiveView is one of the most compelling web technologies in 2026 — real-time, server-rendered UI without JavaScript frameworks. Petal Pro ($299) is the most complete Phoenix SaaS boilerplate with auth, billing, teams, and LiveView components. The free Petal Boilerplate is the best starting point for Elixir developers building their own SaaS features. Choose Phoenix if you value functional programming, extreme concurrency, and the BEAM runtime's fault tolerance.

Phoenix: Real-Time Without the Complexity

Phoenix LiveView lets you build real-time, interactive UIs entirely in server-side Elixir — no JavaScript framework required. The browser renders a WebSocket connection; the server sends minimal DOM diffs when state changes. Discord's web client scaled to millions of concurrent connections on Phoenix.

In 2026, Phoenix's developer community is small but extremely enthusiastic. The language (Elixir), runtime (BEAM/OTP), and framework (Phoenix) combine to produce some of the most reliable, concurrent, low-latency web applications in production.

Quick Comparison

Starter	Price	Auth	Billing	LiveView	Teams	Best For
Petal Pro	$299	Full	Stripe	✅	✅	Complete Phoenix SaaS
Petal Boilerplate	Free	phx.gen.auth	❌	✅	❌	Phoenix foundation
mix phx.new	Free	❌	❌	Optional	❌	Official scaffold
Phoenix LiveDashboard	Free	❌	❌	✅	❌	Dev monitoring
kaffy	Free	❌	❌	❌	❌	Admin panel only

The Starters

Petal Pro — Best Complete Phoenix SaaS

Price: $299 one-time | Creator: Petal team

The most complete Phoenix SaaS boilerplate. Tailwind CSS, Petal components (50+ LiveView components), authentication (magic links, OAuth), Stripe billing (subscriptions, one-time, metered), multi-tenancy with org management, admin panel, transactional emails, and dark mode.

Key features:

• Phoenix 1.7 + LiveView throughout — no React/Vue
• Petal UI component library (50+ accessible components)
• Magic link auth + Google/GitHub OAuth
• Stripe Billing with subscription + webhook handling
• Teams/organizations with member invitation flow
• Admin dashboard with user impersonation
• Transactional email with Bamboo

Project setup:

# After purchase, download the Petal Pro archive
mix deps.get
mix ecto.create && mix ecto.migrate
iex -S mix phx.server  # localhost:4000

Choose if: You're committed to the Elixir/Phoenix ecosystem and want the most complete SaaS starting point.

Petal Boilerplate — Best Free Phoenix

Price: Free | Creator: Petal team | GitHub Stars: 1k+

The free tier of Petal Pro. Phoenix 1.7, Tailwind CSS, Petal UI components, user authentication via phx.gen.auth, and LiveView foundations. No billing or team management — a clean modern Phoenix foundation.

git clone https://github.com/petalframework/petal_boilerplate
cd petal_boilerplate
mix deps.get && mix ecto.setup
mix phx.server

Choose if: You want a free, modern Phoenix starting point and will build SaaS features yourself.

mix phx.new — Official Scaffold

Price: Free | Creator: Phoenix team

The official Phoenix project generator. Generates a Phoenix app with your choice of LiveView or traditional controller/template views, Ecto + PostgreSQL, Tailwind CSS, and JavaScript bundling.

# Full SaaS starter with LiveView
mix phx.new myapp --live --database postgres

# With built-in authentication
mix phx.gen.auth Accounts User users

# Generates:
# - User schema with hashed passwords
# - Registration/login/logout controllers
# - LiveView session management
# - Email confirmation flow
# - Password reset via email

Ecto schema and migrations:

# Generated User schema
defmodule MyApp.Accounts.User do
  use Ecto.Schema
  import Ecto.Changeset

  schema "users" do
    field :email, :string
    field :password, :string, virtual: true, redact: true
    field :hashed_password, :string, redact: true
    field :confirmed_at, :naive_datetime

    timestamps(type: :utc_datetime)
  end

  def registration_changeset(user, attrs, opts \\ []) do
    user
    |> cast(attrs, [:email, :password])
    |> validate_email(opts)
    |> validate_password(opts)
  end
end

Choose if: You want the official minimal Phoenix starting point with maximum control.

Phoenix LiveView: The Killer Feature

LiveView is what makes Phoenix unique. Real-time, server-rendered components with no JavaScript framework:

# lib/my_app_web/live/counter_live.ex
defmodule MyAppWeb.CounterLive do
  use MyAppWeb, :live_view

  def mount(_params, _session, socket) do
    {:ok, assign(socket, count: 0, users_online: 0)}
  end

  def render(assigns) do
    ~H"""
    <div class="p-8 text-center">
      <h1 class="text-4xl font-bold"><%= @count %></h1>
      <p class="text-gray-500"><%= @users_online %> users watching</p>
      <button phx-click="increment" class="mt-4 px-6 py-2 bg-blue-500 text-white rounded">
        Increment
      </button>
    </div>
    """
  end

  def handle_event("increment", _params, socket) do
    {:noreply, update(socket, :count, &(&1 + 1))}
  end

  # Subscribe to presence for real-time user count
  def handle_info({:user_joined, count}, socket) do
    {:noreply, assign(socket, users_online: count)}
  end
end

This renders server-side HTML, connects via WebSocket, sends DOM diffs on state changes, and updates the browser in real-time — with zero JavaScript code written by the developer.

Complex LiveView patterns:

# Real-time collaborative list
defmodule MyAppWeb.TodoListLive do
  use MyAppWeb, :live_view
  alias MyApp.Todos
  alias MyAppWeb.Presence

  def mount(%{"list_id" => list_id}, %{"user_id" => user_id}, socket) do
    if connected?(socket) do
      Todos.subscribe(list_id)
      Presence.track(self(), "todos:#{list_id}", user_id, %{name: socket.assigns.current_user.name})
    end

    {:ok, assign(socket,
      todos: Todos.list_todos(list_id),
      users: Presence.list("todos:#{list_id}")
    )}
  end

  def handle_info({:todo_added, todo}, socket) do
    {:noreply, update(socket, :todos, fn todos -> [todo | todos] end)}
  end

  def handle_info(%{event: "presence_diff"}, socket) do
    {:noreply, assign(socket, users: Presence.list("todos:#{socket.assigns.list_id}"))}
  end
end

BEAM/OTP: The Concurrency Advantage

Elixir runs on the BEAM virtual machine (Erlang's runtime), designed for telecom systems that must never go down:

• Lightweight processes — millions of concurrent processes per node, ~2KB each
• Fault tolerance — Supervisor trees restart crashed processes automatically
• Distribution — Cluster nodes communicate natively across the network
• Hot code upgrades — Deploy without downtime at the VM level
• Let it crash — Design for recovery rather than prevention

# OTP Supervisor — automatically restarts workers on crash
defmodule MyApp.Application do
  use Application

  def start(_type, _args) do
    children = [
      MyApp.Repo,                  # Database connection pool
      MyAppWeb.Endpoint,           # HTTP server
      {MyApp.Workers.Email, []},   # Email worker — auto-restarts on crash
      {Phoenix.PubSub, name: MyApp.PubSub},
    ]

    # :one_for_one — restart failed child, leave others running
    Supervisor.start_link(children, strategy: :one_for_one)
  end
end

WhatsApp served 900 million users with 50 engineers. Discord handles millions of concurrent WebSocket connections. Both run on the BEAM.

Ecto: Database Access in Elixir

Ecto is Phoenix's database layer — explicit queries, no magic:

# Composable queries
def active_users(query \\ User) do
  from u in query, where: u.status == "active"
end

def premium_users(query \\ User) do
  from u in query, where: u.tier == "premium"
end

# Compose at call site
active_premium = User |> active_users() |> premium_users() |> Repo.all()

# Preload associations
users = Repo.all(from u in User, preload: [:team, :subscription])

# Transactions
Repo.transaction(fn ->
  {:ok, team} = Teams.create_team(team_attrs)
  {:ok, _membership} = Teams.add_member(team, user, role: :owner)
  team
end)

Stripe Integration in Phoenix

# Handle Stripe webhooks with pattern matching
defmodule MyAppWeb.WebhooksController do
  use MyAppWeb, :controller

  def handle(%{"type" => "customer.subscription.created"} = event, conn) do
    subscription = event["data"]["object"]
    customer_id = subscription["customer"]

    # Update user subscription in database
    {:ok, user} = Accounts.get_user_by_stripe_customer(customer_id)
    Accounts.update_subscription(user, %{
      status: subscription["status"],
      plan: subscription["items"]["data"] |> List.first() |> get_in(["plan", "nickname"]),
    })

    send_resp(conn, 200, "ok")
  end

  def handle(%{"type" => "customer.subscription.deleted"} = event, conn) do
    # Handle cancellation
    send_resp(conn, 200, "ok")
  end

  def handle(_event, conn), do: send_resp(conn, 200, "ok")
end

When to Choose Phoenix

Phoenix is the right choice for:

• Real-time applications — chat, live collaboration, dashboards, presence
• High-concurrency scenarios — millions of simultaneous WebSocket connections
• Functional programming teams — developers who value Elixir's immutability and pattern matching
• Long-running services — BEAM's fault tolerance and hot reload shine in always-on services
• Financial applications — Elixir's explicit data handling reduces runtime errors

Phoenix is harder to justify when:

• Team has no Elixir experience — steep learning curve (3-6 months to productive)
• Hiring is a priority — Elixir/Phoenix talent pool is small vs JavaScript/Python
• npm ecosystem dependencies — many JavaScript libraries have no Elixir equivalent
• Speed to launch matters most — Node.js SaaS starters ship faster for most teams

Getting Started with Phoenix SaaS

With Petal Boilerplate (recommended):

git clone https://github.com/petalframework/petal_boilerplate
cd petal_boilerplate

# Install Elixir dependencies
mix deps.get

# Create and migrate database
mix ecto.setup

# Generate authentication
mix phx.gen.auth Accounts User users

# Start development server
mix phx.server  # localhost:4000

With mix phx.new (from scratch):

# Install Phoenix
mix archive.install hex phx_new

# Create Phoenix project
mix phx.new myapp --live

# Setup
cd myapp
mix ecto.create
mix phx.server

Deployment: Phoenix in Production

Phoenix applications deploy to Linux servers or containers. The recommended stack:

• Fly.io — Best Phoenix hosting experience. Deploy with fly deploy, built-in clustering, PostgreSQL (via Supabase or Fly Postgres)
• Gigalixir — Elixir-specific managed hosting with hot code upgrades
• Railway — Simple deployment, good Postgres integration
• Self-hosted with Docker — Standard containerized deployment

# Build a Fly.io deployment
fly launch
fly deploy  # Subsequent deployments

# Example fly.toml for a Phoenix app
# [build]
# dockerfile = "Dockerfile"
# [env]
#   PHX_HOST = "myapp.fly.dev"
#   PORT = "8080"

Fly.io's distributed deployment is particularly compelling for Phoenix applications — Phoenix's clustering capabilities (via Distributed Erlang) work natively across Fly's multi-region infrastructure. You can have Phoenix nodes in multiple regions with automatic message passing between them.

Phoenix vs Node.js: The Decision

The fundamental question is whether Phoenix's concurrency advantages matter for your specific use case. For a standard B2B SaaS with CRUD operations and a small team, the Node.js ecosystem's hiring velocity usually wins. For real-time-heavy products (collaboration tools, trading systems, live dashboards), Phoenix's LiveView and concurrency advantages are material.

Scenario	Recommendation
Real-time collaboration product	Phoenix LiveView
Standard CRUD SaaS	Node.js
Team knows Elixir	Phoenix
Team knows JavaScript	Node.js
Need massive npm ecosystem	Node.js
Prioritize system reliability	Phoenix/BEAM

Testing in Elixir: ExUnit and LiveView Test

Elixir's testing story is one of its strongest points. ExUnit is the built-in test framework, and mix phx.gen.auth generates tests for the authentication system automatically.

# test/my_app_web/live/counter_live_test.exs
defmodule MyAppWeb.CounterLiveTest do
  use MyAppWeb.ConnCase
  import Phoenix.LiveViewTest

  test "increments counter on click", %{conn: conn} do
    {:ok, view, html} = live(conn, ~p"/counter")
    assert html =~ "0"

    view |> element("button", "Increment") |> render_click()
    assert render(view) =~ "1"
  end

  test "shows current user count", %{conn: conn} do
    {:ok, view, _html} = live(conn, ~p"/counter")
    send(view.pid, {:user_joined, 2})
    assert render(view) =~ "2 users watching"
  end
end

LiveView's test helpers allow simulating clicks, form submissions, and server-sent events — making it possible to test real-time behavior without a running browser. This is a meaningful advantage over JavaScript frontend frameworks where testing interactive components requires jsdom or a headless browser.

The standard Phoenix project includes database sandboxing: each test runs in a transaction that's rolled back after the test, ensuring test isolation without slow setup/teardown.

---

Elixir Pattern Matching: Core to Phoenix Development

Elixir's syntax is unfamiliar to developers from object-oriented backgrounds, but the learning curve is worth understanding before committing to Phoenix. The core concept is pattern matching — destructuring data directly in function clauses rather than writing conditional logic:

# Pattern matching in function clauses
def process_result({:ok, user}), do: send_welcome_email(user)
def process_result({:error, :not_found}), do: {:error, "User not found"}
def process_result({:error, reason}), do: Logger.error("Unexpected error: #{reason}")

# The caller doesn't write if/else — the runtime dispatches to the right clause
process_result(Accounts.create_user(attrs))

This pattern, combined with Elixir's immutable data structures, produces code where state changes are explicit and side effects are isolated. In a web application context, this means fewer hidden bugs from mutable state and more predictable behavior under concurrent load.

Phoenix is built on these primitives. Every request is handled by an independent process. Every LiveView component is an independent process with its own state. The BEAM scheduler manages hundreds of thousands of these processes concurrently without blocking.

---

Is Elixir Worth Learning for SaaS in 2026?

The honest answer for most SaaS developers: only if you already know Elixir, or you're building something that specifically benefits from the BEAM's concurrency model.

Phoenix LiveView's real-time capabilities can be replicated with WebSockets in Node.js (Socket.io, PartyKit) at additional complexity cost. BEAM's fault tolerance and process isolation are unique — but most SaaS applications don't fail in the ways BEAM solves for. The tail latency improvements from running millions of lightweight processes matter at Discord's scale; for a SaaS with 1,000 active users, the difference is academic.

Where Elixir's ROI is clearest: developer teams that are already productive in functional languages and find Elixir's syntax approachable, products where real-time is the core feature (collaborative tools, live trading, social feeds), and long-running services where reliability is valued over raw throughput.

For teams coming from JavaScript, TypeScript, or Python, the ramp-up time (3-6 months to productive) means Node.js or Go are almost always the faster path to a shipping product. The exception is when a team member is already expert in Elixir — expert Elixir developers are highly productive in Phoenix, and the ecosystem gap with Node.js is small enough for most SaaS use cases.

---

Ecto Changesets: Safe Data Mutation

One of Elixir's most practical advantages for SaaS development is Ecto's changeset pattern. In most frameworks, data validation is scattered across models, controllers, and service objects. Ecto centralizes validation in changesets — pure functions that transform and validate data before it touches the database:

defmodule MyApp.Accounts.User do
  use Ecto.Schema
  import Ecto.Changeset

  schema "users" do
    field :email, :string
    field :name, :string
    field :plan, :string, default: "free"
    field :password, :string, virtual: true
    field :hashed_password, :string
    timestamps()
  end

  def registration_changeset(user, attrs) do
    user
    |> cast(attrs, [:email, :name, :password])
    |> validate_required([:email, :name, :password])
    |> validate_format(:email, ~r/^[^\s]+@[^\s]+$/, message: "must be a valid email")
    |> validate_length(:password, min: 8)
    |> unique_constraint(:email)
    |> put_password_hash()
  end

  defp put_password_hash(%{valid?: true, changes: %{password: password}} = changeset) do
    change(changeset, hashed_password: Bcrypt.hash_pwd_salt(password))
  end
  defp put_password_hash(changeset), do: changeset
end

Changesets compose. An update changeset can be separate from a registration changeset, and each function handles exactly the fields it's responsible for. The valid? field on the changeset propagates through the pipeline — if validation fails, the database is never touched.

This pattern maps directly to the use cases SaaS products deal with constantly: registration flows, profile updates, subscription changes, and admin overrides each need different validation rules. Ecto changesets express this cleanly without controller logic bloat.

---

Key Takeaways

• Petal Pro ($299) is the most complete Phoenix SaaS boilerplate with LiveView, billing, and teams
• Phoenix LiveView enables real-time UIs without JavaScript frameworks — the BEAM handles WebSocket connections
• The BEAM runtime's fault tolerance (OTP supervisors) makes Phoenix applications extremely reliable
• Elixir's functional programming model reduces state-related bugs at the cost of a steeper learning curve
• Fly.io is the best hosting platform for Phoenix applications in 2026

---

The Phoenix Ecosystem in 2026: What's Mature and What's Not

Before committing to Phoenix, understand the maturity landscape across different areas:

Mature and production-ready: Phoenix itself, LiveView, Ecto, ExUnit testing, PostgreSQL integration via ecto_sql, authentication via phx.gen.auth or Pow, and real-time presence via Phoenix.Presence. These have been in production at scale for years. Deployment tooling (Mix releases, Fly.io, Gigalixir) is solid.

Good but narrower than Node.js: Background jobs (Oban is excellent), email sending (Swoosh + Bamboo), task queues, caching (Cachex, Nebulex). Viable production options exist, but fewer alternatives than npm.

Thinner than you might expect: Admin UI generation (Kaffy exists but isn't as capable as ActiveAdmin or Django Admin), multi-tenant SaaS abstractions, third-party API SDKs (many popular SaaS APIs have official Node.js SDKs but only community Elixir clients). You'll write more glue code.

Honest gaps: If your SaaS needs deep integrations with the npm ecosystem (specific AI libraries, specialized data processing packages, complex PDF generation), you'll hit friction. The Elixir community tends toward building from primitives rather than consuming pre-built packages. This is a feature for teams that prefer control, and a burden for teams that want to move fast with existing tooling.

The verdict for new projects: if your SaaS's core value proposition doesn't require the BEAM's unique capabilities (massive concurrency, fault tolerance, real-time), Node.js or Go will get you to production faster. If those capabilities are central to your product — a live collaboration tool, a financial platform requiring extreme reliability, a system handling millions of concurrent connections — Phoenix's maturity in those areas makes it the right foundation and clearly justifies the learning investment.

---

Phoenix vs Next.js for SaaS: The Realistic Comparison

Developers often ask whether Phoenix can match Next.js productivity for SaaS applications. The honest answer depends on your team's background and what your product does.

Phoenix is faster to production for real-time features, concurrent workloads, and systems where reliability is the primary concern. A Phoenix LiveView dashboard that shows live data to thousands of simultaneous users requires less architectural complexity than the equivalent Next.js app — WebSocket connections are cheap on the BEAM, and LiveView handles the state synchronization that you'd otherwise implement with WebSockets, server-sent events, and client-side state management separately.

Next.js is faster to production for most standard SaaS patterns — CRUD interfaces, form-heavy workflows, content management — because the ecosystem of components, tutorials, and developer tooling is dramatically larger. Finding a Stripe webhook handler example for Next.js takes minutes. Finding the equivalent for Phoenix takes longer, though the Petal Pro documentation covers this well.

The team skill factor dominates both considerations. A team fluent in Elixir ships Phoenix faster than Next.js regardless of ecosystem size. A team learning Elixir from scratch will ship Next.js faster for the first six to twelve months of a project.

For solo founders choosing their first production stack: if the product genuinely benefits from BEAM concurrency or reliability, Phoenix is worth the investment. If not, why most boilerplates choose Next.js covers the ecosystem factors that make Next.js the default. For free alternatives before committing to a framework, the best free open source SaaS boilerplates includes both Phoenix and Next.js options worth evaluating side by side. For the broader market of available starters across all frameworks, best SaaS boilerplates 2026 provides the complete landscape. If you are already building on Next.js and need a database decision, the Prisma vs Drizzle comparison for boilerplates covers the ORM tradeoffs that Phoenix avoids by using Ecto.

---

Compare Phoenix boilerplates alongside Node.js and Go starters in the StarterPick directory.

See how Phoenix real-time features compare to Next.js real-time boilerplates for collaboration apps.

Review Petal Pro — the most complete Phoenix SaaS starter with LiveView and billing.