Fly.io bills Machines by the second a VM is actually running

The workload

Fly.io bills its Machines compute product by the second rather than by the month, which changes what a founder has to track. The pricing documentation, as retrieved 16 September 2026, states that a running Machine is charged according to a named CPU and RAM preset, plus roughly $5 per 30 days for each additional GB of RAM beyond the preset; the Machines documentation describes these as fast-launching VMs managed through the same platform. The workload this creates is operational: because the meter runs while a Machine is started, a founder has to decide, and periodically re-check, which Machines need to stay running versus which can be stopped between uses, since the two states are billed differently.

What the documents show

Verified: the pricing page states per-second rates that vary by region and preset. For the Amsterdam region, it lists a shared-cpu-1x preset with 256 MB of RAM at $0.00000078 per second, about $2.02 per month if run continuously; a performance-1x preset with 2 GB at $0.00001242 per second, about $32.19 per month continuous; and a performance-16x preset with 128 GB at $0.00039113 per second, about $1,013.80 per month continuous. Verified: the same page states a stopped Machine is billed only for its root filesystem storage, at $0.15 per GB per 30 days, not for compute. The current page does not describe a no-cost monthly allowance for new customers; a companion entry records that free allowances were deprecated for new plans as of October 2024.

The operating cost

Verified: cost is a direct function of seconds a Machine spends started, at the rate for its preset, per the pricing page; a stopped Machine instead costs only its root filesystem storage, at $0.15 per GB per 30 days. Estimated: a real app's monthly total depends on how many seconds its Machines are actually started, across however many regions it runs in, a number the page cannot supply without the operator's own usage data.

The stop condition

The documents do not name a spending ceiling. Editorially, the natural stop condition here is architectural: per-second, state-dependent billing only saves money if the workload actually stops when idle; a Machine left started around the clock is billed like continuous compute anywhere else, removing the advantage the model offers. The point to reconsider is when a Machine's started-time approaches 100% of the billing period without a workload that requires it.

• What fraction of the billing period does each Machine actually spend started, versus stopped?
• Does the app's traffic pattern suit start-on-demand Machines, or does it need something running continuously anyway?
• Is the workload's RAM need met by a named preset, or does it require the additional-RAM surcharge the page describes?

A per-second, per-state billing model rewards knowing exactly when compute is needed and idling it the rest of the time; the pricing page states the rate, but only the operator's own usage pattern determines whether that rate is ever an advantage.