That relates to how we allocate project resources, and is a bit involved.
There is your plan size, and then there’s your container size.
- Each container (your application, a Solr instance, a DB instance, etc.) comes in one of a fixed number of sizes: S, M, L, XL, which correspond to “I need at least X much CPU and Y much RAM”.
- Your plan also comes in its own S, M, L, XL, 2XL sizes, which mean “I have this much total CPU and RAM”.
On a Development environment (anything but master), the plan size is irrelevant and all containers are created as size Small (S). Development environments only have 1-2 users in practice so giving them any more resources is a waste 99% of the time.
On Production (master, with a domain attached), the system will give you the largest set of containers whose CPU and RAM “ask” will fit within the available CPU and RAM on the plan. The more apps and services you have, the smaller each one is likely to be. You can also specify a specific size for a certain app or service using the
size key in
services.yaml, which may result in other containers being larger or smaller than they would be on their own. See the documentation for more on that attribute.
The end of the deploy log includes a list of what containers were created and what container size each one is using.
If the system cannot fit a Small version of each container within the plan’s available resources, some version of the above error will be shown. That means the containers you are trying to deploy are, in aggregate, asking for more CPU and RAM than your plan allows for.
So for example if your plan includes 3 GB of RAM, but your application and services are, in total, asking for 3.5 GB of RAM, you will get an error.
The possible solutions are:
- If you have an explicit
size set, try reducing it. (Ask for fewer resources.)
- Reduce the number of containers you have. Note that a
worker application counts as another container. (Have fewer containers asking for resources).
- Increase your plan size. (Give it more resources to split up between containers.)
Note that the specific RAM and CPU size that each container asks for is not a fixed number but a soft-capped range, so we do not release specific numbers.