F6 · the architecture · module 8
Auth, deployment & going live
Everything built so far — the F5 engine, the contexts, the controllers, LiveView, PubSub and
Presence — now has to run as one supervised system in production, and three concerns stand between a
working app and a live one. First, the app must know who the user is: sessions and
authentication, which in Phoenix is a generated context plus a signed-cookie session and a plug, not a
special subsystem. Second, the app must be packaged to run on a server with no Elixir toolchain
present: a mix release bundles your code, its dependencies, and the BEAM itself into one
self-contained artifact, with secrets supplied at boot through runtime.exs rather than
baked in at compile time. Third, it must actually go live: build the release, run pending
migrations through a release command (there is no mix on the server), and boot the
supervision tree so the endpoint serves — with the nodes clustered so the F6.07 broadcasts and presence
span every machine. None of this replaces what you built; it wraps the same tree from F5 in the operational
concerns that make it a real, running platform.
Three dives: sessions and authentication, releases and runtime config, and the deploy itself — the same supervised system from F5, now in production.
Going live · build, migrate, boot
build — compile the release into a runnable image.
mix release packages the app, its deps, and the BEAM into one artifact.
Three concerns of going live
Production splits into three questions, and this module takes each in turn. Authentication answers who the user is. A release packages the app to run anywhere. Deployment boots it and keeps it serving. Select a concern.
Going live · select a concern
concern: authentication
does: know who the user is
All three lean on the foundations rather than replacing them: auth is a context, a release packages the same supervision tree, and the deploy boots that tree. Production is the F5 system wearing operational clothes.
What runs in production
A release boots on a server with no Elixir installed, because the BEAM is bundled inside it. At boot,
runtime.exs reads the environment — the database URL, the secret key base, the
host — and the application’s supervision tree starts: the Repo, the Endpoint, PubSub, Presence, and
the F5 engine, each a supervised child. Migrations run on deploy through a release command. From there the
endpoint serves, and if the app is clustered, PubSub and Presence reach across every node.
release artifact → boot → supervised, serving
The deploy does not start your processes by hand — it boots the supervision tree, and the tree starts everything in order and keeps it alive. The reliability you designed in F5 is exactly what carries into production.
Three deep dives
In order: sessions and authentication as a generated context; releases and the compile-time-versus-runtime config split; and the build-migrate-boot deploy with clustering.
mix phx.gen.auth, the signed-cookie session, a fetch_current_user plug, and on_mount for LiveView.mix release, compile-time versus runtime.exs, and running migrations without mix.F5 supervised it
a tree of processes designed to start in order and restart on failure.
F6.08 ships it
the same tree, packaged in a release and booted in production.
Start with sessions and authentication, then releases and config, then deploying to production. This module follows F6.07 — PubSub — and the chapter closes with F6.09, which assembles the live dashboard on everything built here.
References
Generated authentication, releases, runtime config, and going to production.
Sources
- Phoenix — mix phx.gen.auth — the generated authentication system.
- Phoenix — Deploying with releases — release-based deployment.
- Mix — mix release — assembling a release and runtime config.
- Phoenix — Deployment — going to production.
Related in this course
- F6.08.1 · Sessions & authentication
- F6.08.2 · Releases & config
- F6.08.3 · Deploying to production
- F6.07 · PubSub — clustered across nodes in production.
- F6 · Phoenix Framework