Changelog

One Phoenix app across several servers, plus a fresh look for the whole app.

Clusters

You can now run one Phoenix app across several app servers at once, behind a load balancer, with the database on its own server. If a node goes away, the rest keep serving.

Attach, promote, and detach nodes from your app's new Cluster page. Deploys roll node by node, with each one health-checked before traffic switches, and migrations run exactly once on the primary. Apps that rely on Phoenix.PubSub or Presence across nodes can turn on BEAM clustering with one click.

Get started with the Clusters and BEAM Clustering docs.

Custom health check path

You can now choose which path Potions requests to decide your app is up. Every app is checked before traffic switches to a new release, and every minute if uptime monitoring is on. Until now that check always hit /. Set a dedicated route instead, such as /health.

See the Health Checks docs for more.

Deploy commit SHA

Every deploy now injects POTIONS_COMMIT_SHA into your app's environment, carrying the full commit SHA of the release that's running. Point AppSignal's revision, Sentry's release, or your error tracker's equivalent at it, and errors group by deploy instead of by wall clock. After a rollback, it reports the SHA that was actually restored.

See Deploy Metadata for setup with AppSignal, Sentry, Honeybadger, and Bugsnag.

A redesigned dashboard and app

The dashboard is now a fleet view, which scales as more servers and apps are added. We've also updated the design of all app pages.

Your database can now live on its own server.

Dedicated database servers

Potions can now provision a server that runs PostgreSQL and nothing else. It's reachable only over your private network, and you can point one or more apps at it.

Apps with a database under 5 GB can be moved to a database server with a single click and zero downtime. For migrating larger databases, see the Dedicated Database Servers docs. Read the blog post for the full story.

Building a product where your customers get their own hostnames? One Phoenix app can now serve unlimited tenant hostnames, with automatic HTTPS.

Wildcard subdomains

Give every tenant their own subdomain, like moonstone.potionshop.xyz and nightshade.potionshop.xyz. A single wildcard certificate covers all of them, so new tenants work instantly. Any DNS provider works.

Tenant custom domains

Your tenants can also bring their own domain, like example.com, with SSL handled automatically. Your app stays in control of which domains get approved.

View the Multi-Tenant Apps & Dynamic Domains docs to get started.

Database backups can now live somewhere other than your server, providing resiliency for your data.

Offsite database backups

Every backup can now be copied automatically to an S3-compatible bucket that you own. The following providers are supported at launch: Amazon S3, Cloudflare R2, Backblaze B2, DigitalOcean Spaces, Wasabi, and Hetzner Object Storage. That redundancy means your data survives even if the server is lost. Credentials never touch your server, large databases upload in parts, and every offsite restore is checksum-verified.

A clearer backup view

Each database backup will now show you where it lives: Server, Offsite, or both. Expand one to restore from the server or straight from your bucket.

A big batch of updates:

Open signups

The waitlist is gone! You can sign up and start deploying right away.

Hetzner Cloud support

Potions can now provision and manage servers on Hetzner Cloud, alongside DigitalOcean. See Connecting Hetzner to get started.

Monorepo support

Phoenix apps that live in a subfolder of a larger repo can now be deployed. Set the Root Directory when adding an app, or configure it later in the app settings.

Improved environment variable management

You can now paste in your entire .env file. This makes it easier to add or update environment variables, and it renders a live preview of which variables are new versus what's changing. You can also export your variables back out in .env format.

Persistent storage for every app

Every app now gets a storage directory on its server that survives deploys. This is helpful for user uploads, generated files, or anything you need to keep around. The path is exposed to your app as the auto-generated STORAGE_DIR environment variable. Read more in Persistent Storage.