Suddenly needing to add a credit card - can I ensure it doesn't get charged?

1

I just tried to redeploy my app and I’m getting an error saying “We require your billing information”. This is new - I’ve been running my app on the “Trial plan” with no credit card details for some time. I have seen various other posts saying that you need credit card details nowadays, which is somewhat confusing because until now, I clearly haven’t. But I don’t have a problem adding a credit card, if it’s needed for verification. My app is barely used, so I don’t expect to ever go over any usage limits.

However, when I look at “my plan”, it claims I’m on the hobby plan, which is quoted as $5/mo (the “info” link next to my plan describes what I’m on as the “legacy hobby plan”, maybe that’s something different?). So I’m concerned that I might get billed for that, even though I have always until now been on a free tier.

Is there any way to add a credit card with a restriction that it can’t be charged without notice, and if there is an intent to charge, I can decline (obviously with the result that my app will be shut down)? I don’t want to open myself up to unexpected charges, or the hassle of disputing charges that I didn’t agree to.

If the reality is that fly no longer offer any sort of free tier, then that’s fine I guess. I’ll just have to shut down my app or find another provider who offers a free tier. I don’t want to, but it’s not worth the hassle to me of managing billing.

2 Likes
2

I think the same. Asked them in the support but still no limit charge settings neither pre-paid credits. DigitalOcean, Vultr, etc all works with pre-credits and most of them let you set a limit charging for month. I’m also afraid something strange happens to my machines and the costs goes crazy.

3

Precisely this. I would be 100% happy if I could simply configure my app to never use any non-free resources. The runtime could shut the app down if I’m about to go outside the free limits.

4

I think they’re loosing new customers because of this.

5

There isn’t, but let me give some more information on charges that might help alleviate concerns. I’ll refer to our pricing page.

Firstly, you’re on the legacy Hobby plan, which means you have no monthly subscription fee - as opposed to the (non-legacy) Hobby plan which has a $5/month fee.

It sounds like you’re running app(s) within our free allowances? If that’s the case, as long as you’re not provisioning resources beyond the free allowance, you basically don’t need to worry at all about getting charged. For example, if you have one shared-cpu-1x with 256mb RAM running, there’s simply no way for that setup to exceed our free allowance.

One caveat to that is outbound bandwidth, which you don’t necessarily have full control over. If your app receives abnormally large amounts of traffic, we’ll email you. If you end up with unexpected outbound bandwidth charges because of abnormal traffic, email billing@fly.io. We have refunded many people in a similar situation; we’re not interested in making money from surprises like this.

The other caveat is billing changes, e.g. upcoming rootfs billing. We will absolutely email you to let you know about these and explain how you might be affected/how to avoid being charged.

Ultimately, that might still not be enough reassurance, and I totally understand that. The request for card details is a fraud prevention measure that we’ve had to crank the dial on a bit recently, to deal with various fraudulent usage of our free allowances. I will say that I’m surprised your account was flagged, and I’ve initiated an internal discussion regarding your specific situation.

3 Likes
6

I agree, having billing limits would be a nice to have nice. that said, if the lack of that feature scares away customers who only want to use free resources, from a business perspective, that’s not a bad thing for fly.io, is it?

the only truly dynamic cost is outbound bandwidth, everything else is deliberately setup by the user. In the cases where fly has made a material change to billing and landed people with surprise bills (dedicated ipv4 comes to mind) they’ve backed out the charges in bulk without user intervention.

that is, if you provision:

  • Up to 3 shared-cpu-1x 256mb VMs
  • 3GB persistent volume storage (total)

and nothing else (and you can check out the usage panel in the dashboard) there won’t be surprise bills. stay under that and there really won’t be surprises

2 Likes
7

Thanks for the clarification. As you say, I really don’t expect to exceed the free tier (and just to be 100% clear, I’m extremely grateful for the fact that you even have a free tier - as someone else pointed out, you don’t get any revenue from me, so I don’t want to come across as demanding anything!) so this is more just about me better understanding how to manage things - while not wanting to have to think too hard about it all!

That’s really useful to know, thanks. And it’s not something I was aware of. So if I make sure my app is set up like that (which it is), I’m covered. My concern was that if something in my app got into an infinite loop, or I had some bug that caused me to write a massive data set to disk, I’d get charged for that rather than the app being prevented from doing it in the first place. If I can ensure by my app settings that this can’t happen, that’s a significant amount of my worries dealt with.

I do note that my builder shows as having a 50GB volume size for “machine data”, and the pricing suggests that up to 3GB is free. Do I need to do something to limit my disk usage to 3GB? Basically everything I have is on the basis of “just use the defaults”, so I don’t really know how to change these sorts of setting.

I understand that outbound bandwidth is one thing that can’t be controlled. I’m fine with that - to my knowledge, my app has only one user other than me, so I don’t think that’s going to be a problem :slight_smile:

And as regards billing changes, there was an example of this recently with static IP addresses. I’ll be honest, I didn’t completely understand the details behind that change, and I was a bit concerned that I’d followed the instructions correctly, but that’s my issue - the change was communicated to me, and ultimately the instructions were fine and I made the necessary change without issue. So I’m sure this will be fine in the future.

Wanting credit card details for fraud protection seems like a perfectly fair thing to me, so I don’t have a problem there. The main question I had was why I was suddenly getting this message, when the credit card requirement clearly wasn’t a new thing (I’ve seen messages dating back a few years) and I hadn’t to my knowledge changed anything in my usage. That in itself concerned me that I’d done something that affected billing. If I’d received a general email saying that you were adding a credit card details requirement for every user, and explaining how it applied to legacy free tier users, I’d have probably just added my card details and never worried about it.

Thanks for taking the time to explain the details for me.

8

If you created a Fly Volume with e.g. 2GB of space, your app won’t be able to write more than that. Volumes only auto-extend if you set them up to do so, so you don’t have to worry about ballooning usage with them.

Ah yeh great point - we could do a much better job of sign-posting that builder resources are free. Anything your builder has/does will cost you nothing. Believe it or not, this has actually been another source of abuse - fraudsters are creative :laughing:

So no action needed on your end regarding the builder - you only have to worry about resources you specifically provisioned.

Yup totally get that and it’s great feedback. The people dealing with abuse at fly.io have been working furiously recently to prevent fraud from impacting legitimate users, which has included adding new checks. Unfortunately, as always with this stuff, legitimate users like yourself can get caught in that net.

Thanks, you’re very welcome!

1 Like
9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.