I am using the free tier, but I want to prevent going beyond that and being charged.
How do I do this?
Hello! We don’t have any way to limit billing to $0. With the exception of bandwidth, you only pay for what you manually provision. So anything paid is intentional. This isn’t a pay-per-request product where 10 million people show up and you get a big bill at the end.
We do have prepaid support. You can buy $25 or more of credits and we suspend the account when credits are exhausted.
For what it’s worth, we probably won’t build a way to prevent accounts from using paid services. We pay the cost to run free services with the hope that people will deploy projects that are worth paying for when we’ve proven that what we’re doing is valuable.
4 Likes
In lieu of billing limits, is there a place to see what their estimated monthly spending will be?
It’s pretty opaque from both flyctl as well as from the fly.io dashboard how much your resources should generally cost per month.
1 Like
@kurt Some of the items are billed on a “per request” basis (bandwidth) which is what I am concerned about.
I like Fly and would pay for it in the future, but at the moment I have a demo app that I do not want racking up large bills without me knowing.
I think I may use the credits, thanks for the reply.
You can see “usage so far this month” here: https://fly.io/organizations/personal
Stripe doesn’t give us much better data than that, and all our billing is “fire off metrics to stripe, let them generate invoices”. We’ll have to build a new billing system sometime in the next year and I think it’ll improve then.
Ah, yes this is a fair point. Bandwidth is incredibly cheap on Fly, but it costs us money when you use it. We’ve debated ways of making it “safe” to handle unintentional bursts, but so far it hasn’t hit anyone. People pay us for VM time long before bandwidth surpasses the limit. We give away a lot. 
Hi Kurt, I was wondering if I could ask about this.
I completely understand your point about Fly having to pay for free users’ bandwidth. But just to be clear, are you saying that my current free app could rack up a bill, if say someone on the internet found my app and started refreshing it over and over, using lots of bandwidth?
Perhaps that’s not a realistic scenario, especially since you give a 100GB free allowance for North American + European traffic. But it’s possible, from what you’re saying? And even though I don’t have any payment methods attached to my account right now, I would still be legally liable for that bill? Although I don’t live in the US so I don’t know how that legally works.
Like I say, I completely understand your point about Fly having to cover the costs even of free users, that makes complete sense. I just wanted to be clear about how your billing works.
Thanks if you’ve read my post, I appreciate it.
1 Like
I would like to pick this topic up again. I really like using fly. Therefore, I’m currently recommending fly.io to my new customers, and use it accordingly for their applications.
However, I personally believe every cloud provider that offers any kind of “per request” pricing, and ideally every cloud provider with an API that incurs costs, must enable the user to set a maximum of expenditure for a certain time period.
Has there been any changes on the fly side which enables this?
I simply do not feel comfortable using and recommending this service otherwise in the future!
1 Like
Have you seen Accident Forgiveness · The Fly Blog ?
Hi @rubys
Thanks for your answer. I went ahead and read the blog article…
I think it’s nice that you promise not to charge people for obvious usage accidents. However, it does not alleviate my concerns for the following reasons: what if this blog post suddenly changes or disappears in the future? Why is this a blog post and not part of your GTCs? What exactly constitutes an accident? What if for me, an order of magnitude increase is peanuts to another company, but it’s already an accident I and my client would want to avoid with a billing limit?
I hope you understand my point of view. It would be so much simpler to just have a budget limit feature. This would provide me with enough confidence to justify using Fly as safe option for my clients.
After reading the blog post, I am not sure whether Fly is planning to build a “Budget Limit” feature, like other clouds have it. Can you elaborate on that? If it is planned, is there an ETA for this?
If we focus on now; if a client prepaid a certain amount, will services stop once that amount is used up? Right now I have prepaid credits and I wonder what would happen once I run out - would my card be charged, or would all services be stopped to not incur more cost?
Thank you for your continued support!
2 Likes
Hi @rubys - I’d greatly appreciate any updates on this topic.
The key questions are:
(1) is fly.io planning a billing limit feature (similar to how it’s implemented e.g. on the Azure), and (2) will services be stopped, and no further costs incurred, once the prepaid amount is used up?
I’m not in billing; perhaps try: Support · Fly Docs ?
That being said, I am not aware of anybody working on a billing limit feature. That’s not to say that nobody is, just that I’m not aware of it.
every cloud provider that offers any kind of “per request” pricing, and ideally every cloud provider with an API that incurs costs, must enable the user to set a maximum of expenditure for a certain time period
@flyingoutthedoor I don’t oppose this request, but I wonder if it comes with the implication that cloud services, or Fly in particular, are a scam or are inherently untrustworthy.
I like how open things are here, and how many Fly/Tigris people are on this forum to answer questions or to help with config (even for folks who have clearly not made an earnest effort with their own problem). So for me the Accident Forgiveness article is more than enough, and I could understand why adding billing limits might not get much engineering priority.
Thanks for your replies. Just to clarify: My request isn’t about trust—it’s purely practical. A billing limit feature would guarantee no unexpected (however that is defined) charges due to unforeseen usage. While the Accident Forgiveness policy is nice, it’s informal and could change.
True, but the billing systems are per-second, as far as I know. Put the billing page on your org dashboard if you’re truly worried; you can then tear things down if you don’t like the size of your bill 
Seems like we have completely different views on what makes sense in this regard: I think it makes much more sense that Fly.io implements a billing limit feature serving every client they have, rather than every client needing to spend time to implement their own solution or strategy to avoid being charged more than planned.
The challenge any online service provider will have is how to sort people into reasonable categories (a good faith desire to control spend) and unreasonable categories (affluent professionals who will only ever stick on a free tier).
As clearly stated before, my interest in the billing limit functionality is not related to free tier usage, but to have a solution in line with my company’s values that I feel comfortable recommending to my paying customers. I’m simply asking questions, and explaining why a missing feature has value for me and my clients.
This question has been asked multiply times since 2021 in this forum, which illustrates that multiple fly.io customers and potential customers have been interested in it. I wonder how much business was lost because the feature does not exist (potential customers finding these forum entries and not converting to customers).
With all due respect @halfer - from my perspective, a paying user (albeit a very small fish), I find it a bit odd to see a random user commenting on my legitimate questions in this forum, while not providing any information and only bringing up non-applicable topics.
I got my answer from Fly.
This seems a bit heated. Let’s call it here for now? We (Fly) are aware this is a requested feature, there’s no plans to add it at the moment but it hasn’t been rejected either. It’s not really useful to argue on it further.
7 Likes