Erastus on Fly

November 27, 2022

I deployed Erastus to Fly. You can play it at

It’s running on a single shared-cpu-1x, their smallest compute VM. Erastus seems to run with 40K iterations and 1 worker without issue.

The process was pretty simple. Here’s my fly.toml:

app = "erastus-ai"

  dockerfile = "Dockerfile-fly"

  UI_PATH = "/ui/index.html"

  guest_path = "/opt/erastus/ui"
  url_prefix = "/ui"

  internal_port = 5000
  protocol = "tcp"

    force_https = true
    handlers = ["http"]
    port = 80

    handlers = ["tls", "http"]
    port = 443

    interval = "10s"
    grace_period = "5s"
    method = "get"
    path = "/actions/0000000000000000000000000xxxxxxxx1"
    protocol = "http"
    timeout = "2s"

  type = "requests"
  hard_limit = 1
  soft_limit = 1

The file is pretty straightforward. The [build] section says that the app is deployed using an image built from Dockerfile-fly. This is just a slightly-tweaked version of the Dockerfile that builds the API, modified to use Fly’s static file feature to serve the UI (instead of relying on a separate Nginx app, like in the Docker Compose deployment).

The [env] block defines the environment variables that limit the playing strength. The [[statics]] block defines a mapping between the URL and filesystem for serving static files (double brackets indicate a TOML array, i.e. you can have multiple blocks with the same name).

I had to tweak a few things to support environment variable-based limits. I initially set up an entrypoint to updated the UI’s config.js with the limits when the app started. However, that wouldn’t work with Fly’s static file serving–apparently those files are pulled separately from the running image, so the entrypoint’s changes weren’t present in the file being served. I ended up creating a /limits endpoing in the API that the UI requests during setup, which is a much superior solution in any case.

The [[services]] block and its sub-blocks define a mapping of Erastus' internal port to external ports. Fly has a built-in system for managing certificates with Let’s Encrypt and redirecting HTTP to HTTPs.

The [[services.http_checks]] block tells Fly to use the /actions endpoint (with the starting position) to check if the app is healthy. The API uses the erastus binary to determine the available actions, so it vouches that the full Python+C stack is working. It is also computationally inexpensive.

I set hard_limit = 1, which means Fly will only send one HTTP request to the app instance at a time, holding others at the proxy level until space opens. This lets us cap iterations based on the VM’s total available RAM, without worrying about multiple erastus processes exhausting memory. Obviously this wouldn’t handle any real traffic very well, but that’s not a concern I have in this case. ;)

I could have mounted a Fly volume to store puzzle submissions, but I decided that the somewhat ad-hoc puzzle system wasn’t worth persisting.

Overall, the entire process was smooth. I like the Dockerfile-based deployment process (a fun fact is they’re not actually using Docker), and the CLI flyctl program is enjoyable to use (and open source!).