rembrembdocs

Illustration by Annie Ruygt of a Frankie the hot air balloon tallying up a total on a paper-tape calculator

Predicting your Fly.io bill and avoiding surprises

We’ve done our best to make billing on Fly.io something you can reason about. Machines don’t appear out of nowhere. If something is running, it’s because you launched it, or you configured something that did. In general, when we talk about autoscaling, we mean starting or stopping machines you’ve already defined. We don’t quietly spin up extras in the background that turn into mystery charges on your bill. The idea is that your bill should always be traceable to something you can see, name, and plausibly explain when someone asks. If it’s not, we’re happy to help you sort it out.

Need more help understanding your bill? Reach out to us at billing@fly.io.

A few examples

So when you’re budgeting, you can look at what you’ve provisioned and do some quick math. Let’s say you’ve deployed three “shared-1x 1GB” machines in sjc. That’s $20.37/month, tops. If you let them stop when idle, you might only pay for a few hours of compute—but the worst-case scenario is still capped at that monthly rate.

Here are a few more grounded examples:

We recommend budgeting for the “always-on” cost. You can get under that number with auto-stop or bursty usage, but don’t depend on it to hit your budget.

If your estimate seems high, the most predictable way to save money isn’t fiddling with auto-stop/start settings (since any random request might spin a machine up again), but by just…running fewer machines. Or smaller ones.

Want to play with numbers? Try the Fly.io pricing calculator to get a rough sense of what your setup might cost. For the full breakdown, here’s our pricing page.

Metrics-based autoscaling can affect costs

There is one important exception to the rule that Fly.io doesn’t create machines on your behalf. If you use the metrics-based autoscaler, for example to scale a background worker based on queue depth, it can create or destroy machines automatically.

When can the metrics-based autoscaler create machines? When you deploy and configure the Fly Autoscaler, and use FAS_CREATED_MACHINE_COUNT instead of FAS_STARTED_MACHINE_COUNT, you’re giving it permission to create and destroy machines on your behalf. It still uses the machine sizes and regions you specify, and anything it spins up counts toward your bill. Read more in the docs.

Other Stuff to Watch For

A few more things that can quietly run up your bill if you’re not paying attention:

Understanding Free Usage and Overages

Want to go deeper on scaling strategies, autoscaling configuration, or controlling concurrency? These docs walk through the mechanics: