Phoenix hosting
on Shipped.
Bring your Phoenix pages, channels, and application logic together in a deployed service. Shipped gives your Elixir product a public home.
Ship the endpoint and its assets together
Build the Phoenix release with the frontend assets your application uses, then deploy it as a web service. Configure the endpoint for its public host and production environment. Shipped provides the address and HTTPS around the service, while Phoenix handles routing, rendering, and communication with connected clients.
Connect your contexts to persistent records
Use PostgreSQL with the data-access setup your application chooses, and keep connection settings and endpoint secrets in private configuration. Run migrations deliberately as part of the release. Store uploaded files separately from the application image so changing the code does not replace the content your users have created.
Design for reconnects and state changes
Connected interfaces need to recover when a connection ends or an app release replaces a process. Test reconnect behavior and persistent state in staging. If the product grows to multiple instances, configure its PubSub and distribution strategy explicitly rather than assuming process-local state is shared across the service.
A little more detail
Questions about Phoenix?
Can a Phoenix LiveView app be served as static files?
A LiveView application needs a running Phoenix server for its server-side interaction. Deploy the release as a web service and include its built assets.
Does rolling back Phoenix also reverse Ecto migrations?
No. Restoring an application release does not reverse database migrations. Keep release compatibility in mind when planning schema changes and data recovery.
From your workspace to the web