This is true, but we aren't going to bill per request. We really can't, since we support arbitrary UDP and TCP services.
I don't really want to promise anything we haven't shipped yet. But my perfect cloud service (a) charges me when VMs are alive and (b) gives me the tools I need to create/remove/stop/start/suspend/resume VMs based on either network activity or metrics.
One flaw of Fly.io right now is that it's relatively expensive to run a side project in 10+ regions. Most apps benefit from 10+ regions, but $50/mo to try it out is prohibitive. We want to make this more accessible.
Docker also seems like the quickest option to come out of AWS (ie, ECS or friends) and try fly - so I'd continue chasing a bit of a docker story if you could (even just in docs -> getting going with Docker).
The nice thing about mapping peoples apps to overpowered hardware is that it flattens bursts. We need capacity for, say, 10% of apps to burst at any given time.
The nice thing about spreading hardware around the world is that we have excess capacity wherever it's dark. If you're doing latency insensitive work like batch jobs, we can schedule it somewhere that would otherwise be idle.
Aggregate capacity is smaller than the sum of the individual apps capacity requirements. So we both benefit.
Can you scale each region based on usage i.e. have a huge server in US or Europe and a tiny one in a market you don't have many users in? fly.io is really an incredible piece of work, I'll probably just default to it as I am a massive Elixir fanboy :-)
As others have said $50 seems a very low starting point but if you can make it cheaper why not, just means you've helped more people onto your service and they will grow with you.
Autoscaling and balancing regions is something we launched with, but it ended up not making much sense. Our load balance sends traffic to the next nearest region when an app is too busy. It's usually better to spread capacity around to lower latency for users, and then eat the additional latency when a region gets overloaded.
In most cases "the next nearest region" is less than 15ms away.
I don't fault you guys for being a growing startup (we have all been there), but it would be awesome to have a way to flag an issue as "email me when this is fixed so I can come back."
You're not crazy! We still don't do v6 UDP (there's no good reason for us not to, but it'll be a week of rebuilding a BPF engine while the plane's still in the air, so this task never hits the top of our stack and won't until someone really pressures us on it). Full honesty! That's how we roll on HN. :)
I don't really want to promise anything we haven't shipped yet. But my perfect cloud service (a) charges me when VMs are alive and (b) gives me the tools I need to create/remove/stop/start/suspend/resume VMs based on either network activity or metrics.
One flaw of Fly.io right now is that it's relatively expensive to run a side project in 10+ regions. Most apps benefit from 10+ regions, but $50/mo to try it out is prohibitive. We want to make this more accessible.