Recompute your weekend project's bill after a Fly.io pricing flip

When a cloud bill flips, the useful move is a two-number audit. You have a few evenings, a small app, and a bill that should stay boring. The audit asks for the changed resource you actually need at its new rate, then one agent run at the new sandbox rate, then a comparison with the first full invoice.

The changed line is the first number

Check the line you actually need. Fly.io, a platform for running small cloud apps, gave notice on September 21, 2026 that Machine memory rates would climb 20 percent starting October 1, 2026. Machine CPU prices stay the same in that change.

The new extra RAM rate is $6.00 for each GB each month, capped at 128GB. Before the change, extra RAM ran about $5 per GB per 30 days. Pull the invoice or the pricing page for the resource that changed, not the whole product. Write the resource, the quantity, the old rate, the new rate, and the monthly delta. The result is one sentence you can paste into a note.

If your app uses the changed memory line, the delta is the first number. If your app is unmanaged Fly Postgres, a self-run database, the memory increase lands on the Machine part of the cluster, because the cluster combines a Machine with a volume.

One agent run is the second number

Price one run, not a whole month. Sprites, Fly's sandbox product, gets a 45 percent CPU cut and a 50 percent memory cut. A 2 vCPU, 4GB Sprites instance running flat out for 720 hours costs $118.08 after the change, down from $226.80.

Start with the task you would actually give the agent: a fix, a test, a refactor, or a small feature. Note the resources it needs and the hours it runs. Done looks like a single line: task, resources, hours, rate, total. The usual mistake is to treat the sandbox rate as the rate for your app. They are different products, and the audit needs the rate for the product you will use.

The first invoice is the judge

Compare both numbers to the first full invoice after the change. The first number shows what the changed resource costs you. The second shows what one agent run costs you. Put them beside the invoice line you expected, not beside the old total. The result is a small table: old line, new line, delta, and the decision it forces.

If either delta is larger than the line you expected, stop and recheck the quantity, the rate, and the hours. A small app can hide a big line when a resource runs longer than you think. A weekend project can also hide a small line that is still worth fixing. The audit is done when you can say which number changed, why it changed, and what you will do about it.

You are done when you can make a decision in one evening: keep the current setup, move the agent work to the sandbox, or shrink the memory line. You do not need a full migration. You need two numbers, a first invoice, and a clear next step. If the delta is small, note it and move on. If it is large, make the change before the next weekend.

A small audit survives a pricing flip

Keep the audit to one note, one table, and one decision. Do not rebuild the app while you are checking the bill. Do not open a migration plan until the two numbers are written down. A weekend project should survive a pricing flip without becoming a full-time job. The scope is small: find the changed line, price one run, and compare both to the first invoice.

The end state is a note you can close and forget. The note should say what changed, what it costs, what one run costs, and what you decided. If you cannot write that in a few lines, the audit has grown too big. Trim it back to the two numbers. The bill should stay a line item. Use it to keep the weekend project small enough to stay a weekend project.