I’ve launched two Rails applications on my hobby plan. These apps are basically purely proof-of-concepts with near 0 daily users – just me something logging in and checking a few things, or showing it off to some friends.
I launched the first application a month or so ago. The bill was as expected: $0.
I just launched my second application a week ago. Same kind of usages:
Average Data In (1h): 66 B/s
Average Data Out (1h): 75 B/s
Average Memory Used (1h): 242 MB/1 GB
But my bill is now an astronomical $13.61 ! For a week of a hobby project !
I would love to contact support but it seems this isn’t available for hobby projects. I’m hoping this is bug in the billing report.
I found that the default vm size is not the free size. I had to scale down: ~/.fly/bin/fly scale vm shared-cpu-1x
I also found the at the default postgres db size is not the free size – where most of the cost above comes from. I have yet to figure out how to scale it down.
Looks like the database volume is reporting I have used 2GB of 40GB (default, very costly apparently). My app has 4 simple models. Summing the records between all of them: 54 records.
The metrics are reporting high usage from the “repmgr” vs my app at a ration of 26:0.3
From what I gather, the database can’t be modified after creating the application. Thankfully my stuff is purely hobby so I will throw it away and re-create it without any of the default settings.
I’m okay paying the future rootfs prices but these default predatory prices are concerning. I would suggest making changes to be more friendly to new users.
While you have to be on a higher plan to contact support, you can still contact them for billing related issues even on a hobby plan my emailing billing@fly.io. I’d suggest trying that to have a better chance at getting an official response, they might even be willing to credit some or all of that usage back as a gesture of good faith, their team is generally very helpful.
I, too, have noticed the default vm size is beyond the parameters of the free allowances. I usually work around this by editing the settings before deploying, but it is rather annoying.
What we try to do with defaults is give users useful settings for production apps. Some apps might not deploy with 256MB RAM. Supplying useful defaults is difficult when there’s such a variety of apps and requirements. And we know users will have to adjust the settings to work for their project.
That’s why we include dropdown lists with different options. You can choose your VM size and memory easily, for example. For Postgres, we include a description of what kind of deployment option you’re choosing in the dropdown, so you can pick the one that best suits your project:
