This has arisen before but I think it bears repeating because, pricing is important and because it’s presented confusingly.
When I saw the the “Try it for Free”, I naively assumed it was free (as in beer) but it’s free (as in “after you given Stripe your credit card details”). I don’t have a problem with this as I assume, in part, it’s to protect you from bad actors, but… it’s free with a catch
Then, I was confused as to how the Free Tier works. Because I’d provided my cc deets, I wondered whether Free becomes not-Free after resource use. The documentation is OK at this point, once I reread it a couple of times. IIUC, I can use 3x shared-cpu-1x full time (though is your seconds in a month calc correct?).
So, I want to corroborate my use with what’s been billed.
The billing page (https://fly.io/organizations/personal/usage) describes VM exec time in the form of micro-1x. I assume (!?) these are shared-cpu-1x 1 shared 256MB and, from other questions, I’m confident 256MB shareds are the free tier.
I appreciate that pricing is confusing but, I think clarity on this would help you by discouraging developers from being fearful of what they’re getting into.
I’ve seen the documentation but I’m looking for the page again that explains how I can explicitly constrain my apps to only use <3 shared-cpu-1x 256MB instances.
It is! We like metered pricing because you get all the features without having to “upgrade”, but it’s definitely confusing.
The billing page does have old, outdated VM sizes. We keep having to redo how we work with Stripe because Stripe is really bad at doing metered billing, what you’re seeing is data from our previous billing code in a UI we haven’t rebuilt yet. It’s still useful, but a little surprising.
I’m considering Stripe for a project and will want metered billing too, so that’s helpful insight.
I saw another of your (many) interesting posts about your Prometheus (Victoria Metrics) endpoint. I was unfamiliar with Victoria Metrics but your post led me to interesting research, thanks.
I find it confusing that the scale settings don’t appear in the app’s config TOML.
The referenced commands both appear (!) to work (using flyctl scale ..) because the CLI gives me success (changed,Scaled) but I would expect to see settings applied to the app’s TOML (and these are evidently applied elsewhere).
Ideally, I’d check the TOML into source control as the app’s definition but it’s incomplete.
We’re torn on this, but we’ve so far used fly.toml to define app requirements, not necessarily where it runs or what scale. This is for two reasons: (1) we have quite a few users who deploy the same app with different scale configs and (2) when we autoscale, things like count change and would get a config out of sync.
