Deploying a Wagtail site to 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

Not interested in the preamble? Jump to part 2.

Migrating from Heroku or similar? Your app is probably ready to go. Jump to part 5.

Need a hand? I offer Wagtail, hosting and DevOps consulting services - drop me an email and we’ll have a chat.

I’ve been playing with 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.

Although I’m referencing Wagtail in particular in this post, almost everything I discuss here is also relevant to “pure Django” applications.

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

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:


If you want to experiment with a more fully-featured Wagtail site, follow along with bakerydemo. It’s a great example of a Wagtail site that will demonstrate all the features we’ll be dealing with.

Any bakerydemo-specific changes or notes will be in these 🍞-boxes.

Let’s get started in Part 2.