SYSTEM Cited by 2 sources
Phoenix (Elixir web framework)¶
Phoenix is the dominant web framework for Elixir. Created by Chris McCord, it runs on BEAM and centres on real-time / collaborative applications built around Channels (WebSocket abstraction), Presence (distributed presence tracking), and LiveView (server-rendered real-time UI with seamless live reload).
Role on this wiki¶
Phoenix appears on this wiki primarily as:
- The framework Phoenix.new is tuned for — the 2025-06-20 Fly.io post frames the agent as "batteries-included fully-online coding agent tailored to Elixir and Phoenix" and demonstrates it building LiveView apps end-to-end (Presence + Channels + Ecto + real databases) as a concrete concepts/vibe-coding target.
- The "real-time collaborative applications" design target McCord names as the reason an agent benefits from a full browser: LiveView's live-reload semantics make the agent's edit → build → verify loop natural across a WebSocket-driven page.
- A load-bearing ecosystem piece on the BEAM stack adjacent to Livebook and FLAME on Fly.io.
Key architectural properties (as cited by Phoenix.new context)¶
- Channels / WebSockets — Phoenix's native transport for real-time bidirectional messaging between browser and server, built on BEAM processes per connection.
- Presence — distributed-state CRDT-adjacent primitive for tracking which users / processes are currently connected, integrating with Channels.
- LiveView — server-rendered UIs that push partial DOM updates over Channels, giving "seamless live reload" the agent can observe through its own driven browser when verifying changes.
- Ecto — the database wrapper Phoenix.new can model against live schemas in a pre-existing Postgres/MySQL database.
- Mix — the build tool (
mix phx.server,mix test,mix deps.get) the agent uses inside the Phoenix.new VM.
Seen in¶
- sources/2025-06-20-flyio-phoenixnew-remote-ai-runtime-for-phoenix — "Phoenix is about real-time collaborative applications, and Phoenix.new knows what that means." Phoenix.new demonstrates full-stack LiveView app generation with Presence / Channels / real databases.
- [[sources/2026-01-14-flyio-the-design-implementation-of- sprites]] — Phoenix as control-plane substrate for Sprites, not user-facing product veneer. Ptacek: "The global orchestrator for Sprites is an Elixir/Phoenix app that uses object storage as the primary source of metadata for accounts. We then give each account an independent SQLite database, again made durable on object storage with Litestream." First wiki instance of Phoenix as an internal orchestration substrate for a Fly.io product — pairs with the pattern visible across tkdb (Go) and flyd (Go); Phoenix enters the Fly.io internal-services language mix for a user-facing orchestrator. Multi-tenant metadata shape (SQLite-per-account + Litestream) leans on the wildcard- replication story unlocked by Litestream revamped.
Related¶
- systems/phoenix-new — coding agent tailored to Phoenix.
- systems/erlang-vm — BEAM substrate.
- systems/fly-machines — hosting substrate for Phoenix.new sessions and for deployed Phoenix apps.
- systems/fly-sprites — second Fly.io product with Phoenix in a load-bearing role (as global orchestrator substrate).
- systems/litestream — durability substrate for Sprites' per-account SQLite DBs under the Phoenix orchestrator.
- systems/sqlite — per-account metadata store shape.
- concepts/vibe-coding — Phoenix / LiveView is a concrete complex-target for the vibe-coding workflow.