I’m having some trouble understanding how pricing works with multiple processes. According to the documentation, the Hobby Plan includes up to 3 shared-cpu-1x 256mb VMs, between apps and machines.
If i set the [processes] section in my .toml config, let’s say to run app, queue and schedule in a Laravel app, then it is one app but each process seems to be running in a separate VM. Does it mean that this 3 process setup uses the 3 available VMs?
To make a practical example, in case I had the described setup with 3 processes, and I added a Postgres machine, that would be outside the free allowance and paid per use since?
If you’re running multiple heavy-weight things in a single container, you might explore just running them as separate Fly.io apps. The advantage to doing this, apart from the apps not fighting over the same CPUs and memory, is that you can scale separate apps independently, and put them in different sets of regions.
As I understand it, you should think of your app as a distinct thing rather than as a Virtual Machine. Your app may run on one or more Virtual Machines at different times (for example, during a blue-green deployment, or when you’re configuring multiple processes) but you’ll be billed according to the resources allocated to the app because it’s Fly’s responsibility to manage the resource allocation according to what you’ve configured as being available to your app.
The reason the pricing page talks about VMs is because Fly does allow a user to go more granular than an app by using machines which do offer direct control over the underlying Virtual Machines and in that case you are responsible for choosing what resources are allocated where.
The Machines API gives you efficient, low-level control over VM provisioning, supported by Fly.io infrastructure and networking features
– Fly Machines
So in your case, because you’re using apps, you can read “VM” as “app” when looking at pricing
HI @lc91! You’re correct that if you configure three processes using [processes] in fly.toml, that is provisioning three VMs. So in your scenario, yes, adding Postgres to that would definitely take you beyond the free allowance.
@shrink We charge according to the resources provisioned, not per app. An app can run tons of VMs, if you configure it to. Process groups are one example. Or you might want an instance in every city in fly platform regions for a globally deployed service. That costs us many times more to run than one VM! So a one-size-fits-all per-app price wouldn’t work.
Thank you for the correction, apologies for the misinformation! That said, with that in mind, I’m confused by the documentation I quoted:
[…] the advantage to doing this, apart from the apps not fighting over the same CPUs and memory, is that you can scale separate apps independently, and put them in different sets of regions. […]
If each process is its own Virtual Machine with its own resource allocation, what does this mean?
That’s just with reference to the previous sentence, “If you’re running multiple heavy-weight things in a single container, you might explore just running them as separate Fly.io apps.”
This part may have been written before we introduced process groups, not sure! That’s not our favourite doc and it needs a redo!
Ah! Thank you very much. I understand now, the documentation is not in the context of the Process Groups feature, it’s in the context of running multiple processes with Fly, and thus, that quote is from the part of the documentation specifically about not using Process Groups. Got it! Thank you. The documentation is a little unclear but I think this is more deserving of a mea culpa on my part than a complaint about the documentation
and it needs a redo!