Which strategy should I use for Phoenix 1.7 to 1.8?
Elixir teams need a migration card for whether Phoenix 1.8 is worth the move now, because the framework baseline changed around LiveView 1.0-era assumptions and newer OTP requirements.
Blockers
- requires_version: framework/phoenix-1-7-21 → runtime/elixir-1-11
- requires_version: framework/phoenix-1-7-21 → runtime/erlang-otp-22-1
- requires_version: framework/phoenix-1-8-5 → runtime/elixir-1-15
- requires_version: framework/phoenix-1-8-5 → runtime/erlang-otp-25
- requires_version: framework/phoenix-1-7-17 → package/phoenix-liveview-1-0-0
- requires_version: framework/phoenix-1-8-0 → package/phoenix-liveview-1-1
Who this is for
- real-time
- small-team
- enterprise
Candidates
Stay on Phoenix 1.7.21 if your runtime floor is still below OTP 25
Phoenix 1.7.21 is the latest official v1.7 release visible in HexDocs, dated 2025-03-27. Phoenix 1.7 requires Elixir v1.11+ and Erlang v22.1+, and Phoenix 1.7.17 had already switched newly generated apps to LiveView 1.0.0 on 2024-12-03. As of 2026-04-02, there is no framework pricing change to consider: Phoenix remains MIT-licensed and free on Hex. This means many teams can stay on 1.7 without being blocked on old pre-LiveView-1.0 assumptions.
When to choose
Use this when your production baseline cannot yet move to Erlang/OTP 25 or you want to postpone framework cleanup work. The decisive reason to stay is runtime compatibility, not LiveView 1.0 adoption, because Phoenix 1.7 already incorporated LiveView 1.0-era defaults.
Tradeoffs
Lowest immediate migration risk and no new runtime floor, but you remain on the older Phoenix branch while current releases and fixes are happening on 1.8.x.
Cautions
Do not frame this as a LiveView 1.0 migration holdout by default. Official Phoenix 1.7 docs already show LiveView 1.0.0 in generated apps from 1.7.17 onward, so the remaining gap is mostly Phoenix 1.8 runtime and deprecation cleanup.
Upgrade to Phoenix 1.8.5 now if you can standardize on Elixir ~> 1.15 and OTP 25+
Phoenix 1.8.5 is the current Phoenix release on Hex as of 2026-04-02, published on 2026-03-05. Phoenix 1.8 requires Erlang/OTP 25+, and Phoenix 1.8.5 source declares an Elixir requirement of "~> 1.15". Phoenix 1.8.0 shipped on 2025-08-05 and its generators moved forward again by using LiveView 1.1 in generated code. As of 2026-04-02, there is still no framework pricing change: Phoenix remains MIT-licensed and free on Hex.
When to choose
Use this when your team is already comfortable moving the BEAM baseline to OTP 25+ and cleaning up framework deprecations in one pass. The upgrade is most worth it when you want to align with the active Phoenix branch and your blockers are operational, not conceptual.
Tradeoffs
You get the current release line and newer fixes, but you must absorb a runtime floor increase plus some source-level cleanup. The migration is not just a dependency bump if your app still relies on older controller or endpoint patterns.
Cautions
Key 1.8 migration caveats are official and concrete: `use Phoenix.Controller` must specify `:formats`; `:namespace` and `:put_default_views` are deprecated; layouts without modules are deprecated; the router `:trailing_slash` option is deprecated; and the compile-time `config` variable in `Phoenix.Endpoint` is no longer available, with `Application.compile_env/3` as the replacement. Also avoid targeting early 1.8.0 behavior as your baseline: Phoenix 1.8.2 fixed LongPoll being active by default since 1.8.0.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Which strategy should I use for Phoenix 1.7 to 1.8?"