Is this a scenario which sounds like a good fit for Machines v2?
Hmm, there’s a lot to answer here, so I’ll break this into each need and goal of yours:
Some sort of custom stateless Machine vending service which is being called from our frontend
You could make calls to the machines api to make machines with custom sizes, names, and other settings.
There’s a few ways that you could do this. For one, you could create an app for each user, since each app automatically gets a URL. Another way would just be having a subdomain for each user on top of your domain, like billy.mycoolapp.fly.dev
The frontend communicates with that machine via REST and Websockets (code updating, invoking functions / services)
We have pretty solid support for HTTP apps and websockets.
You could use the existing autostop feature for * After a defined idle time, the Machine will stop automatically
machines, which will stop a machine when it hasn’t received any traffic for a few minutes. As for defining the specific idle time, I think we support that through setting kill_timeout on that specific machine, but I could be wrong. However, you could always create your own service that uses the machines api to stop machines.
A cron job or something like this will clean up stale Machines
This would also be well serviced by an app that uses the machines API
Overall, I’d say yes, machines would be a pretty great candidate for this.
2. Is it one app with multiple machines, or many apps with a dedicated machine each?
You can do either! It really just depends on what your requirements and needs are.
3. Are there defined or practical limits in terms of apps / machines we could provision? (resource requirements more on the lower end)
You can view the machine preset sizes here. The lowest you can go in 1 shared CPU that uses 256 MB of memory.
Could we map our own domain somehow?
You should be able to, though I have less experience on this. See these docs for more information
We have default limits for each organisation for abuse prevention and so you don’t accidentally create way more machines than you expect to, but we’re happy to raise them if you need - just send us an email at billing@fly.io
Great, thanks - that helps. Any info about the exact default quotas?
One more question: This tutorial states that an ip needs to be allocated to an app in order to be reachable from the public internet. Other places in the docs are talking about a shared ip v4 address for all apps.
Also, allocating a dedicated ip address is 2 USD / month, correct?
This tutorial states that an ip needs to be allocated to an app in order to be reachable from the public internet
Yes, you need to assign an IP to your “app” in order for it to be reachable over public internet.
We have 2 types of ip’s, shared & dedicated. Shared ip’s are free, dedicated ip’s cost 2 usd per month. You can assign either to your app, it just depends on your use case.
Getting this raised to a 1000 or even 10k would be possible? In terms of usage, I think it’s gonna be low baseline with some spikes and rather short lived instances. As stated above, we’d aim to create these machines close to the user, which means the machines would not all be started in the same data center.
Really interested in the practical upper limit to get a sense for the constraints.
I raised your limit to 1,000. We can make it higher, too. This is mostly an abuse prevention measure.
The upper limit depends mostly on size of machines and geo placement, and how fast you grow. You can organically grow to as big as you want because we’ll just keep adding capacity. Going from zero to 50,000 is something we’ll want to talk to you about.
The best thing to do when you’re ready is to get a paid plan, and send us a support request when you start growing.
Sometimes, Fly runs out of capacity in some of the regions; so you may not always get a Machine nearer to the user. At that scale, better to pool it continent-wise, me thinks. I think, you might even want to create multiple Fly orgs (even accounts if you’re not reliant on Fly’s 6pn?) instead of creating 50K machines in a single org / account. I shudder to think how flyctl / the REST API would behave in face of such gigantic use. With AWS, at that scale, we’d normally create multiple accounts, usually one per-region (iad, bah, hyd etc) per-stage (prod, test, dev etc). Unsure what is the general recommendation here (I guess orgs?).
@rohitpaulk was / is building something similar to what you’re, I believe. May be they’ll reply.
Thanks! This won’t be running under my account though. We’ll reach out to support for the correct account.
Of course, I don’t think we’ll reach that anytime soon
Thanks for the info, was very helpful. We’ll start building a proof of concept (see playground on the backend · Issue #3050 · winglang/wing · GitHub) and will either create new posts here or get in touch with support if we have more questions along the way.
