Reflex is a recent (but exciting!) entrant to the world of Python web frameworks. is a hosting provider that lets you host your applications in production really quickly. In this blog we'll have a look at how you can deploy your Reflex applications on


Before looking at how to deploy Reflex apps to Fly, we need to understand how to deploy a Reflex app on any platform. In our previous blog post we described how to run Reflex apps in production which also included the general setup of what a Reflex app looks like and what are the underlying deployment artifacts you need to account for.

If you haven't read that post, please read it now and come back to this post after you've read it. In the meanwhile, we'll prepare a coffee for ourselves and wait for you to come back.


Now that the background is out of the way, let's focus on putting Reflex apps on

In this blog post we'll assume that you have flyctl installed on your machine. If not, please follow their installation instructions to do so. We'll also, of course, assume that you have a deployment-ready Reflex application.

The first step is to authenticate yourself using the CLI. Run fly auth login on the command line. Running this command would open up a browser where you can enter your login credentials, and redirect you back to the terminal.

~/W/p/g/code main ❯ fly auth login
Opening ...

Waiting for session... Done
successfully logged in as

Deployment Artifact(s)

Fly uses Dockerfiles to run applications. Internally, they convert these Dockerfiles into micro VMs to finally run the app in production, but all that is not relevant to this blog post (although certainly very interesting!).

This means your application needs a Dockerfile to run on Fly. As we saw in the previous blog post, to run a Reflex app in production, we want to be able to run a FastAPI backend and a Next.js frontend. One approach to do this is to run the backend and frontend on different ports and put an Nginx server in front of them both. Nginx will intercept all HTTP requests, and based on what the request is for, relay it to either the backend or frontend. Additionally, to keep the three processes running, we can use an off-the-shelf process manager. Supervisord is one such popular tool, which we also mentioned in the previous blog post, so let's use that.

All this means that the architecture looks as follows:

  1. FastAPI server runs on port 8000 and serves backend requests.
  2. Next.js server runs on port 3000 and serves frontend requests.
  3. Nginx runs on port 80, intercepting all HTTP requests and relaying them to either FastAPI or Next.js.
  4. Supervisord runs as the process manager and keeps all three processes running.

Amongst these four components, FastAPI and Next.js processes are handled by Reflex out of the box (using reflex run --backend-only and reflex run --frontend-only). Let's look at how to how the Nginx and Supervisord configuration files look like, and close the loop with a Dockerfile that connects everything.

1. Nginx configuration

In the previous blog post, we showed what an example Nginx configuration file can look like, along with a description of how it works. Here's the code snippet again for easy reference:

server {
    # ...

    # backend
    location ~ ^/(admin|ping|upload) {
        # ...

    # websocket
    location ~ /_event/ {
        proxy_set_header Connection "Upgrade";
        proxy_set_header Upgrade $http_upgrade;
        # ...

    # frontend
    location / {
        # ...

The main thing to note is that we have location blocks configured for the backend, the frontend, and the websocket requests used internally by Reflex.

2. Supervisord configuration

As with Nginx, the previous blog post also showed what an example Supervisord configuration file can look like, along with a quick description of how it works. We'll repeat the code snippet here for easy reference.


command=poetry run reflex run --env prod --backend-only --backend-port 8000

command=poetry run reflex run --env prod --frontend-only --frontend-port 3000

command=nginx -c /app/nginx.conf

In this snippet we're asking Supervisord to run the backend, frontend, and Nginx processes, and keep them running in case they stop for some reason.

3. Dockerfile

The final piece of the puzzle is a Dockerfile that Fly can work with. Here's an example of what it could look like:

FROM ubuntu:22.04

# Install dependencies
RUN apt-get update
RUN apt-get install --yes build-essential curl nginx supervisor unzip
RUN curl -fsSL | bash -
RUN apt-get install --yes build-essential python3 python3-dev python3-venv nodejs
RUN ln -sf /dev/stdout /var/log/nginx/access.log && ln -sf /dev/stderr /var/log/nginx/error.log

# Set the main working directory

# Set up a virtual environment to install all Python packages
RUN python3 -m venv $VIRTUAL_ENV
RUN pip install poetry

# Copy all the source code to the main working directory
COPY pyproject.toml poetry.lock /app
COPY app /app/app
COPY assets /app/assets
COPY supervisord.conf /app/supervisord.conf
COPY nginx.conf /app/nginx.conf

# Install dependencies
RUN poetry install
RUN poetry run reflex init

CMD ["/usr/bin/supervisord", "-c", "/app/supervisor.conf"]


We've added inline comments to describe what's going on in each section of the Dockerfile.

Essentially, we start from Ubuntu 22.04 as the base image and install the core dependencies we'll need (eg. Python, Nginx, Supervisor, etc.). We then set the main working directory and set up a virtual environment where all the Python dependencies will be installed. Next, we copy our application source code to the main working directory, which is followed by installing the Python dependencies and running reflex init. Finally, HTTP port 80 is exposed to the outside world for Nginx to be able to receive and respond to requests.

Deployment Process

Now that we have all the deployment artifacts in place, let's move to the deployment itself!

1. Launch

In the terminal, run fly launch. It will ask you a few questions, such as what the name of your application should be, what region it should be launched in, etc. And after those are out of the way, it'll get to work to put your Reflex application into production.

~/W/p/g/code main ❯ fly launch
Scanning source code
Detected a Dockerfile app
Creating app in /tmp/example
We're about to launch your app on Here's what you're getting:

Organization: Personal               (fly launch defaults to the personal org)
Name:         example-2023-12-09     (derived from your directory name)
Region:       Frankfurt, Germany     (this is the fastest region for you)
App Machines: shared-cpu-1x, 1GB RAM (most apps need about 1GB of RAM)
Postgres:     <none>                 (not requested)
Redis:        <none>                 (not requested)

? Do you want to tweak these settings before proceeding? No

Waiting for launch data... Done
Created app 'example-2023-12-09' in organization 'personal'
Admin URL:
Wrote config file fly.toml
Validating /path/to/example/fly.toml
Platform: machines
✓ Configuration is valid

... output snipped ...

We've removed some of the output lines in the previous snippet to remove sensitive information. But towards the end you'll receive a message from that your application is ready!

2. Configure

Once the application is launched, you might need to set a few environment variables that it needs. Set them using flyctl secrets set.

$ flyctl secrets set API_KEY=example ...

3. Deploy

At this point your app should be ready for deployment! Run flyctl deploy to do that.

$ flyctl deploy

You'll see a lot of lines go by that tell you what the deployment process is currently up to, including building and pushing the Docker image and updating any existing machines. At the end, if everything went well, you'll see the following message on the console:

Visit your newly deployed app at

This means that your application is now deployed to the public internet and is ready to accept user requests. Go ahead and open the link in your browser and find it out for yourself!

Photo by Kyle Hinkson on Unsplash

Launch your next SaaS quickly using Python 🐍

User authentication, Stripe payments, SEO-optimized blog, and many more features work out of the box on day one. Simply download the codebase and start building.