Phoenix Hosting
for Elixir Releases

Production Phoenix setups follow a standard container-based architecture:

• Multi-Stage Builds: You compile dependencies and assets in a builder stage, then copy the release to a minimal runner image (like Debian or Alpine).
• Runtime Configuration: Configuration is handled via config/runtime.exs, reading from environment variables at startup rather than build time.
• Database Separation: PostgreSQL is the standard database for Phoenix. It runs as a separate service, often alongside Redis for PubSub in clustered setups.
• Persistent Volumes: While the app is stateless, you might need volumes for user uploads or if you're running a local SQLite database.

A LiveView page holds a websocket open for as long as the tab is open. That is the part of Phoenix hosting most platforms get wrong, so it is worth being specific about what happens on Hostim.

• No websocket configuration. The ingress performs the HTTP upgrade itself. You do not set an annotation, a flag, or a separate endpoint — expose your HTTP port (4000 for a default Phoenix release) and /live/websocket works over the same hostname and certificate as the rest of the app.
• Keep the heartbeat on. Phoenix pings every 30 seconds by default (heartbeatIntervalMs in app.js), which is what keeps a proxy from treating an open LiveView socket as idle. If you raised that interval to save traffic, put it back.
• Check the origin. Set PHX_HOST to your real domain. Phoenix validates the websocket origin against it, and a mismatch shows up as a page that renders once and then never updates.
• Restarts drop sockets. A deploy replaces the container, so every LiveView reconnects. That is normal and the client handles it, but any state you kept only in the LiveView process is gone — keep it in PostgreSQL or Redis if it has to survive.

Distributed Erlang is the one thing that does not come for free. A single node needs no setup; multi-node clustering requires libcluster with a strategy that fits the platform, and Phoenix PubSub across nodes is simplest over a managed Redis instance.

"Free" hosting usually comes with significant caveats, which are particularly painful for Phoenix apps:

• Sleeping Apps: Free tiers often sleep inactive apps. This kills all active LiveView connections, leading to a poor user experience when they try to reconnect.
• Memory Limits: The BEAM VM is efficient but has a baseline memory footprint. Tiny free tiers often trigger OOM kills.
• No Persistence: Lack of persistent storage means you can't easily store uploads or use SQLite for simple projects.

Free tiers are excellent for learning, but for a responsive LiveView application, you need a stable environment that doesn't sleep. Hostim.dev offers a preview tier for testing, but our focus is on reliable, paid production hosting.