As I explore fly.io a bit (it looks great) I’d love to set a 50/month billing limit just to avoid surprises down the line. Once I’ve got a feel for costs won’t be needed. Has a feature like this been considered or did I maybe miss something somewhere?
Can I just buy credits and remove my billing method maybe?
Hey @RandomAdmin11, we just released support for buying credits New: Prepaid Credits (and a bonus story).
We don’t have spending limits yet, but we might have something that can alert you when usage goes over a threshold in a month or two.
@michael i remember when fly.io was mentioned on hacker news with this:
(Launch HN: Fly.io (YC W20) – Deploy app servers close to your users | Hacker News)
"
Max monthly spend: unexpected traffic spikes happen, and the thought of spending an unbounded amount of money in a month is really uncomfortable. You can configure fly.io apps with a max monthly budget, we’ll suspend them when they hit that budget, and then re-enable them at the beginning of the next month.
"
so, does this exist or not?
We’ve changed how we do this a bit, you now prepay for credits to control spending limits.
i see, and what happens if i consume more than my credits allow? for example, consider this scenario:
what happens now:
A: i owe fly.io 30$
B: my stuff is turned off, i do not owe fly.io any extra $$$
i obviously prefer B and hope that’s the case, but want to be sure. this is not really explained in the “prepaid credits” post, or anywhere else i could find 
When you exhaust your credits, we suspend apps. You won’t be billed any extra with a few exceptions.
If you provision persistent volumes or extra IPs, we continue to bill for those.
Most people haven’t needed these limits. The only portion of our service that could grow unbounded is bandwidth, and we forgive those charges when it was a mistake. We don’t add VMs unless you enable autoscaling, and other features require manual provisioning.
thanks,that is ok for me.
maybe having this as part of the documentation (or FAQ) (“what happens when i exhaust my credits”) or something like that would be nice. (at least the what-is-stopped-what-is-not, i understand the forgiving part needs certain flexibility 
)
Great - this covers my use case well enough I think - thanks.
Just found this thread after one of my colleagues asked about setting budgets. Prepaid credits work well enough; we’re mostly worried about e.g. someone maliciously or accidentally creating a whole bunch of instances we don’t expect. To that effect:
When using prepaid credits, if they are exhausted, do you delete data in postgres volumes? thanks