The fly.toml and the local stack.

The fly.toml describes how the release becomes machines. It names the codemoji-phoenix app and a primary region, builds from the Dockerfile, and deploys with a rolling strategy so a release replaces machines one at a time. Fly’s internal network is IPv6, so the config points Erlang’s resolver at an inetrc file, makes the database driver use IPv6 sockets, and runs distribution over inet6 — harmless on one machine, ready if the app ever clusters.

Two settings keep the live surface live. A health check polls /health so a machine that stops answering is taken out of rotation, and auto-stop is turned off with at least one machine always running, so a node is not reaped mid-session and a player’s open /socket connection is not dropped under them. Connection limits are set per machine, so a machine sheds load by refusing new connections rather than collapsing.

The same image runs locally under docker compose, which brings up the whole stack: Postgres reachable on port 6432, Valkey on 6390 — the connector’s port — and the endpoint on 4000. Because the connector dials its Valkey on localhost, the web container shares the Valkey container’s network namespace, so the app finds the store on its own loopback with no change to the code. It is the production shape in miniature: the release, a database, and a queue, wired the way Fly wires them.