Deploying a Wagtail site to Fly.io Part 5: Deploying

This post is part of a series:

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

With all that prep work done we can finally do what we said we’d do at the start - deploy a site to Fly.io.

To start, we’ll need to install the Fly command line tool, flyctl. Follow steps 1-3 over on the Fly.io docs and then come back. I’ll wait.


Great, so now you have a Fly.io account and the flyctl tool. Everything on Fly can be managed with this tool (not quite the nice GUI experience you get with Heroku, but it’s getting there).

Next up, let’s kick off the application on Fly:

flyctl launch --dockerfile Dockerfile --name my-bakerydemo

(You’ll need to come up with your own alternative to my-bakerydemo as app names need to be unique.)

You’ll be prompted for a region - pick your preference. You’ll also be asked whether you want to setup a Postgresql database, type Y and select the ‘Development’ configuration. Finally, you’ll be asked whether you want to deploy your application. Type N to say no for now.

In one command, Fly’s done a lot of work for you here:

One problem, we need to make sure your database is populated with the application models when it’s first deployed (and when migrations are added in the future). To do this, edit the fly.toml and add:

[deploy]
    release_command = "python manage.py migrate"

Now whenever Fly creates a new release, it will run Django’s migrate command.

While we’re editing this file, you’ll also want to change the internal_port line from 8080 to 8000 as this is the port the Dockerfile we’re working with serves the application on.

🍞

bakerydemo’s Docker image runs Python inside a virtualenv. To use the correct python instance, you’ll need to replace this with:

/venv/bin/python manage.py migrate

We’re also going to need to set a few other environment variables to make sure everything we works as we expect. In Fly, we set these using the ‘Secrets’ feature and the related flyctl secrets commands.

I find the easiest way to do this is to prepare a file called secrets with all the environment variables you want to set. It’ll look something like this:

ALLOWED_HOSTS=myappname.fly.dev
DJANGO_SECRET_KEY=my_secret_key
AWS_ACCESS_KEY_ID=[AWS Access Key ID generated by s3-credentials]
AWS_SECRET_ACCESS_KEY=[AWS secret key generated by s3-credentials]
AWS_STORAGE_BUCKET_NAME=[storage bucket name you defined]

The value of ALLOWED_HOSTS should be the name you gave your Fly app, followed by .fly.dev.

Generate a more secure secret key than I have by running:

python -c "import secrets; print(secrets.token_urlsafe())"

Then run

flyctl secrets import < secrets

This will create each line from your file as a Fly secret attached to your application. The application will be able to access each secret as an environment variable when it’s running.

Finally, we can deploy our app:

flyctl deploy

Visiting [yourappname].fly.dev will now reveal your site running on Fly!

You’ll probably want to set yourself up with a superuser. We can do this by accessing the server running your application and running the createsuperuser management command:

flyctl ssh console
>> /app/manage.py createsuperuser
🍞

If you’re following along with bakerydemo, you’ll need to run your commands preceded with /venv/bin/python so we use the python instance installed in the virtual environment. You’ll also need to replace the /app directory with /code.

You’re also probably expecting a bit more than just a boring ‘Welcome to your new Wagtail site!’. We need to get bakerydemo to generate its content, so let’s do that.

In a flyctl ssh console session, run /venv/bin/python /code/manage.py load_initial_data to prepare our content. Refresh the site and you should have a fully functional bakery!

Where Next?

Congratulations! You’ve got a Wagtail site running on Fly!

There’s a few things to consider now we’re here: