---
title: "Build and scale Phoenix apps on a developer-focused public cloud"
description: "Phoenix hosting on Fly.io. fly launch detects Phoenix and writes your config, migrations run before every deploy, and Managed Postgres is one command away."
---

# Phoenix’s Productivity, Elixir’s Reliability: *Unlocked* & *Deployed*

Build and scale Phoenix apps on a developer-focused public cloud.

[Launch Now](https://fly.io/speedrun)

Ready, Set, Go!

## Speedrun Your Phoenix App Onto Fly.io

Deploy a Phoenix app to Fly.io in a few minutes with Fly.io's command line tool, `flyctl`.

[Get Started](https://docs.fly.io/elixir/getting-started)

```
> Install flyctl on GNU/Linux
$ curl -L https://fly.io/install.sh | sh

> Run from Phoenix project root
$ fly launch

> Scale CPU, memory, instances & regions
$ fly scale
```

Not on GNU/Linux? [Install flyctl for your platform.](https://docs.fly.io/flyctl/install)

Up, Up, and Away!

## Ship Every Release Without Taking the App Down

fly deploy builds your Phoenix release and replaces Machines one at a time by default. Set the bluegreen strategy in fly.toml and the new Machines boot beside the old ones, with traffic moving over only after their health checks pass. LiveView clients reconnect to the new release on their own.

Effortless Clustering Made for Elixir

## Elixir Was Born to Be Clustered & Fly.io Makes It Natural

Elixir’s true strength lies in its ability to run clustered applications. Thanks to Fly.io's built-in private WireGuard network, you can easily unite your Elixir applications into a cohesive, powerful system with minimal setup. Experience the simplicity of scaling and get your apps working together, just like they were designed to.

NEW!

## Managed Postgres For Your Elixir Project

Build more, manage less with Fly.io's fully-managed database service. We'll handle all aspects of running production PostgreSQL with Elixir, including:

- Automatic backups and recovery
- High availability with automatic failover
- Performance monitoring and metrics
- Resource scaling (CPU, RAM, storage)
- Automatic encryption of data at rest and in transit

[Learn More](https://fly.io/mpg/)

Quick and Easy Set-up

## From Concept to Launch, Faster Than Ever

Starting fresh with Fly.io feels like a breeze. We’ve streamlined the process so you can deploy your Phoenix applications without hassle. Swiftly move from development to deployment, ensuring your app is up and running in no time, all the while enjoying the performance perks that come with our platform.

Pay for What Runs

## Idle Machines Stop. The Next Request Starts Them.

Fly Proxy stops Machines that have no traffic and starts them again when the next request arrives, so a staging app or a quiet side project isn't billed for CPU or RAM while it sits idle. Started Machines bill per second. When load grows, fly scale count adds Machines running the same release, and with dns_cluster configured they join the cluster on their own.

## Trusted by teams at

- **Encrypted Secrets**
  fly secrets set stores values encrypted and exposes them to your Machines as environment variables, which is where config/runtime.exs already reads DATABASE_URL and SECRET_KEY_BASE.
- **Secure, Private Networking**
  Build with confidence knowing your applications are protected with built-in secure, private networking, keeping your data safe and your connections secure.
- **Built-in Observability**
  Get insight into your Phoenix app's performance with Fly.io's built-in observability tools. Monitor, troubleshoot, and optimize your Elixir applications with real-time metrics and logging.

## Ready to See Your Phoenix App Take Flight?

Deploy on Fly.io today. It’s fast, it’s simple, and it’s where your Elixir app is meant to thrive. Join the leaders and embrace the future of distributed Elixir applications.

[Get Started](https://fly.io/app/sign-up)

## Attach Managed Postgres to your Phoenix app

Managed Postgres is the supported path. Fly.io runs the cluster for you, handling automatic backups and recovery, high availability with automatic failover, performance monitoring, resource scaling, and encryption of data at rest and in transit. Provision it as part of the launch:

```
fly launch --db mpg
```

Or add one to an app that already exists, in two commands:

```
fly mpg create
fly mpg attach <clusterID> -a your-app-name
```

`fly mpg attach` writes the connection string onto the app as a secret named `DATABASE_URL` and triggers a deploy so the app comes up holding it. The string is the pooled connection URL, which goes through PgBouncer. You never see the password. Your `repo.ex` does not change, and neither does `config/runtime.exs` beyond reading the variable it already expects.

To use it, Ecto picks it up in `config/runtime.exs`, which is where a Phoenix release reads its runtime configuration.

Migrations run on every deploy through `release_command`, which the migrate script `mix phx.gen.release` generates:

```
[deploy]
  release_command = "/app/bin/migrate"
```

It runs in a temporary Machine built from the new image, with your secrets loaded, before any Machine takes traffic. A non-zero exit fails the deploy and the previous version keeps serving.

## What you didn't have to set up

Look back at what actually happened. You ran `fly launch`, and either took the database with it or added it with `fly mpg create` and `fly mpg attach`. A standard Phoenix app with a Postgres database in one region is the ordinary case Fly.io is built for, not a stretch. Here is the work that never appeared:

**A hosting service for your code.** `fly launch` and `fly deploy` build from the directory you are standing in. A Phoenix project with no git remote at all deploys fine.

**A Dockerfile.** `fly launch` detects Phoenix, generates a release, and writes the Dockerfile. It lands in your repository where you can read it, edit it, and see it in a diff.

**A connection string.** Attaching writes `DATABASE_URL` onto the app as a secret. The password never lands in your clipboard or your shell history.

**A migration step in a deploy pipeline.** `release_command` runs migrations on a throwaway Machine before any Machine takes traffic. A migration that fails fails the deploy, instead of half migrating production.

**TLS and a hostname.** The app answers on `<app>.fly.dev` with HTTPS from the first request, and the certificate is issued and renewed for you.

**A load balancer or a VPC.** Fly Proxy is already in front of your Machines, and your app reaches Postgres over your organization's private network as soon as the cluster is attached.

None of that work is missing. It is done, and the record of it is a `fly.toml` you can read in one screen, diff in a pull request, and revert with git.