Deploying a Wagtail site to Fly.io Part 1: The Plan

This post is part of a series:

1. The Plan
2. Configuration
3. Dockerising & Requirements
4. Static & Media Files
5. Deploying

I’ve been playing with Fly.io quite a bit recently.

Yes I’m drawn to the exciting tech, the fascinating blog posts, the attractive pricing and generous free tier (for now…), but more importantly, Fly are one of the few new breed ‘PaaS’ tools that realise what Heroku got right with its excellent developer experience, and are on a fast-track to replicating and eventually exceeding what Heroku offers.

While Fly is quickly establishing itself as my go-to hosting platform for personal/hobby projects (even before the “sunsetting” of Heroku’s free tier), Wagtail has been my go-to platform for almost all the sites I build for quite a while.

In this series, I’ll run through how to get a Wagtail site running on Fly.io.

We’ll need to sort out a few things before our application is ready to be served from Fly:

1. How do we configure our application so its easily ported between different environments? (dev, staging, production, etc.)
2. How are we going to bundle up our application ready for pushing to Fly?
3. How are we going to serve our ‘static’ files (CSS, JavaScript, etc.)
4. Where are our media files (or Wagtail Images/Documents) going to be stored?
5. Where’s our database going to live?

There are, as always, many answers to these questions but we’ll pick a few answers and run with them.

1. For configuration (and for everything else for that matter), we’ll be following the Twelve-Factor App methodology. This means storing any configuration that might vary in the environment - Fly’s Secrets in this case.
2. We’ll bundle up the application using a Dockerfile - while there are certainly merits to Fly’s other option, Buildpacks, I consider having a good Docker set up to be super useful for portability and a great local development experience.
3. Django has no built-in way (outside of development) to serve static files - it expects you to figure out how to serve these yourself with a separate web server or from a separate cloud service. We’ll use the very useful WhiteNoise package to give Django the ability to easily and safely serve its own static files.
4. When Fly runs your application, it gets a bit of the hosts’ file system to write to, but whatever you write to it is ‘ephemeral’ (fancy for ‘not gonna last’). When that application stops, your data is gone. That’s no good when you want to store things like images or documents uploaded by users.
5. Our database is going to live on Fly too! We’ll use their built-in Postgres support for this project, but do be aware it is largely ‘unmanaged’ - meaning you don’t get backups, disaster recovery and the other niceties you’d get with a managed service.

Before we kick-off, a few final things:

• We’re going to be preparing and deploying a fresh Wagtail site in this series. If you have your own site ready to go, these steps should all be transferrable to whatever you’re building.

• This series focuses on preparing and deploying a Wagtail site - I won’t be going in to detail about setting up your development environment, installing dependencies or potential differences when working with different operating systems.
• Some knowledge of git, Wagtail/Django, managing requirements files and general command line usage is expected.

Let’s get started in Part 2.