Skip to content

FLYIO 2025-06-20 Tier 3

Read original ↗

Fly.io — Phoenix.new: The Remote AI Runtime for Phoenix

Summary

Chris McCord (creator of Elixir's Phoenix framework) introduces Phoenix.new — a "batteries-included fully-online coding agent tailored to Elixir and Phoenix" — as his months-long Fly.io skunkworks project. Every session runs in its own ephemeral Fly Machine (Firecracker micro-VM) with a root shell shared between the developer and the agent, an integrated full headless Chrome the agent drives to verify its own front-end changes, and preview URLs under phx.run produced automatically from any bound port via integrated port-forwarding. Apps "live in the cloud from the minute they launch" and inherit Fly.io's hardware virtualization + WireGuard + isolated networks. GitHub CLI (gh) is pre-installed so the agent can clone any repo, browse issues, and open PRs — McCord himself uses Phoenix.new to triage phoenix-core GitHub issues: "I close my laptop, grab a cup of coffee, and wait for a PR to arrive." Framed as an instance of an async agent future where development iterations shift from laptop-and-IDE to CI-shaped environments with agents working around the clock. The post notes that the system prompt is tuned for Phoenix/LiveView today but "all languages you care about are already installed" — the substrate is language-agnostic; Phoenix.new just ships a Phoenix-tuned agent on top.

Key takeaways

  1. Ephemeral per-session VM with a shared root shell — "even though it runs entirely in your browser, Phoenix.new gives both you and your agent a root shell, in an ephemeral virtual machine (a Fly Machine) that gives our agent loop free rein to install things and run programs — without any risk of messing up your local machine." Canonical wiki instance of patterns/ephemeral-vm-as-cloud-ide — concepts/cloud-ide shape specialised for agentic development where isolation matters because the agent is a co-tenant of the shell, not just because VMs are cheap. Sibling of the 2025-02-07 VSCode-SSH-bananas patterns/disposable-vm-for-agentic-loop shape but shipped as a product: the disposable VM is the user's entire development session. (Source: Phoenix.new on fly.io/blog)
  2. Full headless browser as first-class agent tool — "Phoenix.new includes, in both its UI and its agent tools, a full browser. The Phoenix.new agent uses that browser 'headlessly' to check its own front-end changes and interact with the app. Because it's a full browser, instead of trying to iterate on screenshots, the agent sees real page content and JavaScript state – with or without a human present." Canonical wiki instance of concepts/agent-driven-browser + patterns/agent-driven-headless-browser. Distinguishes itself from screenshot-iteration agents (which get a rasterised snapshot) by giving the agent the DOM tree + live JavaScript state + server-side logs simultaneously. Structural pair with the 2026-01-29 Cloudflare MoltWorker patterns/cdp-proxy-for-headless-browser pattern — same primitive (a CDP-driven browser the agent owns), different deployment shape (tenant- scoped endpoint vs per-session VM-local).
  3. Root access is the load-bearing affordance — "A fully isolated virtual machine means Phoenix.new's fingernails can get arbitrarily dirty. If it wants to add a package to mix.exs, it can do that and then run mix phx.server or mix test and check the output. Sure. Every agent can do that. But if it wants to add an APT package to the base operating system, it can do that too, and make sure it worked. It owns the whole environment." Canonical wiki statement of concepts/agent-with-root-shell — the agent's capability surface is the whole Linux environment rather than a narrow tool-allowlist. The bounded blast radius is supplied by Firecracker + Fly Machine isolation, not by agent-side permission design. Structural counter-framing to concepts/capability-based-sandbox (Cloudflare Project Think / EmDash) which reach containment through capability scoping inside the runtime; Phoenix.new reaches it through a disposable whole-OS perimeter.
  4. Preview URL as a first-class platform primitive — "They have private, shareable URLs (we detect anything the agent generates with a bound port and give it a preview URL underneath phx.run, with integrated port-forwarding)." Canonical wiki instance of concepts/ephemeral-preview-url + patterns/ephemeral-preview-url-via-port-forward. Addresses Karpathy's "code was the easy part; getting it online took me a whole week" pain point directly: the app is always live because port-binding is itself the deployment signal.
  5. GitHub CLI baked into the substrate — "Github's gh CLI is installed by default. So the agent knows how to clone any repo, or browse issues, and you can even authorize it for internal repositories to get it working with your team's existing projects and dependencies." The agent's reach-into-your-org surface is a standard CLI shape (pairs with the wrap-CLI-as-MCP / agent-ergonomic CLI framings from the 2025-04-10 flymcp post and 2026-04-13 Cloudflare all-of-Cloudflare CLI post) rather than a new authorisation protocol.
  6. Closed log-plus-browser-plus-test loop — "When Phoenix.new boots an app, it watches the logs, and tests the application. When an action triggers an error, Phoenix.new notices and gets to work." Concrete instantiation of concepts/agentic-development-loop: log tail + browser drive + test runner all streaming into the agent's context, all running inside the same VM the agent has root on. The three-signal closed loop makes this a three-way signal fusion (server logs + browser DOM/JS state + test exit codes) rather than the two-way signal fusion (compiler + test output) typical of earlier coding agents.
  7. Vibe-coding with real real-time semantics — "Phoenix.new can already build real, full-stack applications with WebSockets, Phoenix's Presence features, and real databases. I'm seeing it succeed at business and collaborative applications right now." A canonical concrete wiki instance of concepts/vibe-coding at LiveView complexity: the agent is not just autogenerating CRUD; it's wiring Presence + Channels + DB schemas + LiveView templates. The ElixirConfEU Tetris demo ("nailed it, first try, first prompt") is offered as an existence proof that frontier-model world knowledge + the right substrate can cover surface-pattern gaps in training data.
  8. PR-shaped async agent workflow — "I'm already using Phoenix.new to triage phoenix-core Github issues and pick problems to solve. I close my laptop, grab a cup of coffee, and wait for a PR to arrive — Phoenix.new knows how PRs work, too." Canonical wiki instance of patterns/agentic-pr-triage: hand an agent a gh-authenticated environment, point it at an issue tracker, let it pick work and surface results as PRs. The async framing ("the future of development … probably looks less like cracking open a shell and finding a file to edit, and more like popping into a CI environment with agents working away around the clock") is the 2025-04-08 RX thesis's robot-experience sibling reworked for coding agents specifically.

Systems / concepts / patterns extracted

Systems

  • systems/phoenix-new — new; Fly.io's in-browser Phoenix-tailored coding agent; ephemeral Fly Machine per session with root shell + headless Chrome + phx.run preview + gh CLI.
  • systems/phoenix-framework — new; the Elixir web framework Phoenix.new is tuned for (Channels, Presence, LiveView, live reload as the interactive substrate).
  • systems/fly-machines — extend; named as the ephemeral VM substrate ("a Fly Machine"). Adds "Fly Machine as per- session cloud-IDE sandbox" to the set of first-class Fly Machine workload shapes (alongside stateful apps, FKS Pods, GPU inference, MCP-server hosting, and disposable agent VMs).
  • systems/firecracker — extend; the underlying micro-VM that makes per-session cloud-IDE economics viable (instant boot, bounded blast radius, whole-OS isolation).
  • systems/gh-cli — new; GitHub's gh command-line tool; pre-installed in the Phoenix.new VM to give the agent PR / issue / repo reach into authorised orgs.

Concepts

  • concepts/cloud-ide — new; browser-delivered development environment backed by a remote VM, orthogonal to whether the primary user is a human or an agent.
  • concepts/ephemeral-dev-environment — new; dev environment that exists for the duration of a session rather than as a long-lived personal machine; production instances include Phoenix.new, GitHub Codespaces, Gitpod, Replit, StackBlitz.
  • concepts/agent-with-root-shell — new; the LLM agent's capability surface is a Linux shell with root, not a narrow tool-allowlist; containment is the VM boundary rather than the capability grant.
  • concepts/agent-driven-browser — new; agent controls a full browser (DOM + JS state + navigation + event injection) rather than iterating on screenshots; distinguishes from screenshot-agents on signal-fidelity.
  • concepts/ephemeral-preview-url — new; any port bound by the running application is automatically exposed as a publicly-shareable preview URL, usually on a platform-owned subdomain, without manual deploy steps.
  • concepts/async-agent-workflow — new; the development iteration loop shifts from a human-in-every-loop IDE pattern to a CI-shaped pattern where agents pick work from a queue (issues, tasks, tickets) and surface results as PRs or similar async artifacts.
  • concepts/agentic-development-loop — extend; the three-way signal fusion (logs + browser + tests) on Phoenix.new sharpens the existing concept page's framing of what "closing the loop" requires.
  • concepts/vibe-coding — extend; LiveView/Phoenix complexity as a concrete vibe-coding instance (not just single-file toy apps).
  • concepts/robot-experience-rx — extend; coding-agent specialisation of the 2025-04-08 RX thesis.

Patterns

  • patterns/ephemeral-vm-as-cloud-ide — new; per-session VM (Firecracker-class for fast boot) delivered as a browser IDE where the shell is shared with a coding agent; canonical Phoenix.new instance.
  • patterns/agent-driven-headless-browser — new; the coding agent owns a headless browser colocated with the application under development and drives it directly (not via screenshot feedback).
  • patterns/ephemeral-preview-url-via-port-forward — new; bound ports inside an ephemeral dev VM are auto-mapped to a platform-owned subdomain via port-forwarding, producing shareable URLs without a deploy step.
  • patterns/agentic-pr-triage — new; give an agent a gh-authenticated ephemeral env pointed at an issue tracker, let it pick work and produce PRs autonomously.
  • patterns/disposable-vm-for-agentic-loop — extend; add Phoenix.new as a canonical productised instance of this pattern (vs the 2025-02-07 VSCode-SSH-bananas post where the pattern was only sketched).

Operational numbers

  • 1 Fly Machine per Phoenix.new session (ephemeral; terminated when the session ends).
  • 1 shared root shell per VM (user + agent).
  • 1 full (not headless-only) Chrome browser per VM, driven by the agent + visible in the Phoenix.new UI as a live preview.
  • Preview URLs published under *.phx.run — one per bound port in the running app.
  • gh CLI pre-installed (version unspecified).
  • Phoenix.new's Phoenix-tuned system prompt covers Phoenix / LiveView / Channels / Presence / Ecto; Rails / Expo-React-Native / Svelte / Go all "already installed" as non-default targets.
  • No production numbers disclosed: no VM boot time, no per- session cost, no concurrency / fleet ceiling, no PR-merge rate from McCord's own PR-triage usage.

Caveats

  • Product-launch post by the Phoenix framework's creator — framing is optimistic, system-prompt / agent-loop internals not disclosed; the agent architecture is described at the capability level, not the prompt-chain / tool-schema / retry-policy level.
  • "Entire browser as agent tool" is a real architectural departure from screenshot-iteration agents but the mechanics (which CDP client? which headless runtime? context-window impact of DOM dumps vs screenshots?) are not disclosed.
  • Preview-URL mechanism ("we detect anything the agent generates with a bound port") is described at marketing depth; routing path from *.phx.run → fly-proxy → inner port is not sketched.
  • No security-model discussion for the agent-with-root-shell posture beyond the implicit "the VM is ephemeral" — no discussion of what an attacker who compromises the agent can reach over the WireGuard private network during the session window, or how gh auth tokens are scoped.
  • Language-agnostic claim ("all languages you care about are already installed") is unqualified and likely means "the VM image ships the toolchains" rather than "the agent has equal competence across all stacks" — the system prompt is Phoenix- tuned, and the post concedes adding new languages and frameworks is future work.
  • PR-triage workflow (McCord on phoenix-core) is self-reported and n=1; no aggregate throughput, PR-merge rate, regression- introduction rate.
  • Positioning against competitors (Replit Agent, v0, Bolt, Lovable, Cursor's remote agents, Devin) not discussed.

Source

Last updated · 200 distilled / 1,178 read