Represent app state for immutable deploys

IIUC, fly.toml only represents a chunk of app config.

Regions, scale, custom domains etc aren’t represented.

Is there a way to represent an app config so that a perfect representation can source controlled? And deployed immutably (i.e. no deploy, then scale then certs add ...

2 Likes

You’re right, fly.toml only has enough to build and run the app. Storing placement and scale in the config is harder since those can change at runtime, such as autoscaling or balancing regions. We’ve been thinking about how to improve this but don’t have anything concrete yet. We’re also mulling over what belongs in our config vs what might be better in terraform or waypoint.

What’s your use case?

This is very tentative but I’m considering extending an in-flight PoC to deploy (containerized) apps to Fly. The PoC currently deploys to Google Cloud Run and DO Apps.

The plan is for customers to provide a ‘spec’ and the PoC will deploy suitably configured apps in a set of global locations.

The PoC currently (this may be discarded) uses a Kubernetes Operator to create Custom Resources that represent the apps as Kubernetes objects.

With both Cloud Run and Do Apps, I’m able to more completely define the app('s state) as a single object and there’s a singular deployment method that is ‘exhaustive’. Ironically both these platforms are Kubernetes under-the-covers and so this may explain why the experience feels like Kubernetes too (but it’s also a good experience).

The PoC infrastructure could be deployed using Terraform (it’s currently bash scripts, don’t shoot me) but, a customer’s apps will change over time and this can be achieved by mutating the config and ~= redeploying.

One (!) advantage in using Fly is the ability to deploy one to many regions which is not conceptually present in Cloud Run or DO Apps which are region-specific.