Your plan determines how much memory, CPU and storage your project may use and how many processes it may run. All containers in a project share these resources. The limits are fixed: reaching a limit causes no additional costs - but your applications notice it. How much depends on the resource.
Memory (RAM)
When the project approaches the limit, the server first releases cached files. From about 90 % of the limit it slows your containers down to free memory - applications become noticeably slower.
When the memory is full, the server terminates a process in the project, usually the one using the most. Depending on its restart setting, the affected container restarts. For your application this means:
- running requests are aborted, visitors briefly see an error,
- a database can lose operations that have not been saved,
- if it happens repeatedly, the container ends up in a restart loop.
The project overview shows a notice when processes were terminated due to lack of memory. If you have given a container its own RAM limit, only that container is affected - this protects important services such as the database from a container that uses too much memory.
CPU
The CPU limit states the computing power as a percentage of one core, 200 % equals two cores. At the limit the server throttles your containers evenly. Nothing crashes, but everything takes longer: pages load slowly, and for longer requests the web address may respond with a timeout.
Storage
Storage includes volumes, images, snapshots and the logs of your containers. When it is full, every write operation fails - this is the most critical limit:
- Databases can no longer write data, abort or no longer start. In the worst case, data is damaged.
- Uploads, sessions and caches of the application fail.
- New images or versions can no longer be loaded.
Important: snapshots retain deleted data. When you delete files, the space is only freed once the snapshots containing these files are deleted as well (Backup and snapshot).
Processes
The number of simultaneous processes is limited per project. At the limit, applications can no longer start new processes or connections, for example workers of a web server. The logs then usually show “Resource temporarily unavailable”.
What we do not do
We do not delete any data and do not book additional resources automatically. Your project is not suspended when a limit is reached. Whether you clean up, set limits per container or book more resources is your decision.
Being warned in time
In the Monitoring tab under Notifications you specify from which utilisation we warn you by email. You choose up to four thresholds between 50 and 95 %, for example 50, 80 and 95 %. We report each threshold once as soon as it has been reached for at least 5 minutes - for memory, CPU, storage and processes. If utilisation drops again, we only report the next higher threshold again (Monitoring).
For projects with databases we recommend an early first threshold, for example 70 % for storage: this leaves time to clean up before the disk is full.
You can also switch off the resource warnings. You will then only learn about a bottleneck when applications slow down or fail - we advise against it.
What helps
- Book more resources - a larger plan or additional memory, CPU or storage take effect immediately, without restarting the containers (Plan and options).
- Limits per container - give memory-hungry containers their own RAM or CPU limit in the container settings.
- Configure the application - many databases and caches use as much memory as they get. Limit it in the application, for example the buffer of a database.
- Clean up - delete old snapshots, unused volumes and large files (Volumes and file browser). We delete container logs ourselves after 7 days, at most 20 MB per container.
- Find the cause - the statistics in the Monitoring tab show which container needs how much, the logs show errors (Finding and fixing errors).