> ## Documentation Index
> Fetch the complete documentation index at: https://docs.squarecloud.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Resource Limits: RAM, CPU, Bandwidth and Storage

> Square Cloud resource limits: minimum RAM per project, vCPUs by RAM, dedicated bandwidth, 10 GB NVMe storage and the LACK_OF_RAM and LACK_OF_CPU statuses.

Square Cloud implements container-based resource limits to ensure isolation, stability, and fair distribution of infrastructure across applications.

## Minimum resource requirements

Each project hosted on the Square Cloud Platform has specific minimum resource requirements to ensure optimal performance:

* **Bots:** Minimum of 256 MB RAM required.
* **Websites:** Minimum of 512 MB RAM required.
* **Cache Databases:** Minimum of 512 MB RAM required.
* **General Databases:** Minimum of 1 GB RAM required.

### Why do RAM minimums exist?

Containers have mandatory operational overhead: language runtime, OS libraries, and network buffers. Below 256 MB, the kernel's OOM Killer tends to terminate processes during boot or garbage collection, making the application inviable.

**Technical implications:**

* Each container consumes 1 dynamic IPv4 and NVMe storage IOPS
* Minimum allocations prevent resource fragmentation (noisy neighbor effect)
* Daily snapshot formula: `(Total RAM / 256) * 2` (approximate; the exact per-plan allowance may be lower on higher tiers)

<Note>**Impact Data:** After implementing the 256 MB minimum limit, application stability increased drastically, reducing the crash rate due to OOM (Out of Memory) by **97.7%**.</Note>

## CPU allocation

Short answer: CPU is allocated based on configured RAM. Increasing RAM typically grants more vCPUs.

### Rules

#### Single vCPU plans

Applications on 1 vCPU plans receive full capacity without throttling.

#### Multicore plans (≥2 vCPU)

* Performance floor: applications with ≥512 MB RAM receive at least 2 vCPUs.
* Proportional scaling:
  * Hobby (≤2 vCPU): +1 vCPU per 512 MB RAM
  * Standard / Pro / Enterprise: +1 vCPU per 1 GB (1024 MB) RAM

### Examples

| Plan | Plan capacity | Configured RAM | vCPUs allocated |
| - | - | -: | -: |
| Standard | 4 GB / 4 vCPU | 1 GB | 2 vCPUs (floor) |
| Standard | 4 GB / 4 vCPU | 4 GB | 4 vCPUs (max) |
| Enterprise | 128 GB / 16 vCPU | 2 GB | 2 vCPUs |
| Enterprise | 128 GB / 16 vCPU | 16 GB | 16 vCPUs |

### Throttling and safety limits

The system enforces the plan vCPU limit and applies leveling to keep distribution fair. Short-term elasticity may grant extra vCPUs during spikes but is not guaranteed.

Prohibited CPU uses:

* Cryptocurrency mining
* Unrestricted, intensive ML workloads without authorization
* Deliberate resource abuse

These uses break the [policy against abuse, crypto mining and spam](https://help.squarecloud.app/en-us/article/policy-against-abuse-crypto-mining-and-spam-vih8tf/). Separately, an application that keeps all of its vCPUs busy is stopped with [`LACK_OF_CPU`](#lack_of_cpu).

## Network limits

Every application gets **dedicated bandwidth**, the same for upload and download, that scales proportionally to the RAM allocated: **+50 Mbps per 256 MB**. It is reserved for your container, never shared with neighbours, and traffic is never metered or billed.

Some examples:

| RAM allocated | Bandwidth |
| -: | -: |
| 256 MB | 50 Mbps |
| 512 MB | 100 Mbps |
| 1 GB | 200 Mbps |
| 2 GB | 400 Mbps |
| 4 GB | 800 Mbps |

For sustained high-throughput workloads, support can set up a dedicated cluster.

**Boot turbo.** Every start gets a burst well above the plan's bandwidth, so installing dependencies, pulling models or rebuilding caches is fast regardless of your allocation.

Databases have their own dedicated bandwidth, in both directions, sized to their RAM.

## Storage limits

All projects receive **10 GB NVMe** storage by default.

Characteristics:

* Enterprise-grade NVMe
* Persistent across deploys and restarts
* High IOPS and throughput

## Limit exceeded statuses

When an application goes over its resources, Square Cloud stops it, writes a `[SQUARE-SHIELD]` line with the reason to its logs and sends you an email. This table is the reference the other pages link to; the fixes are below it.

| Log line | What happened | What Square Cloud does |
| - | - | - |
| `[SQUARE-SHIELD] LACK_OF_RAM` | The application used all of its RAM. | Stops the application. |
| `[SQUARE-SHIELD] LACK_OF_CPU` | The application kept all of its vCPUs busy across consecutive checks. | Stops the application. Databases are never stopped for CPU. |
| `[SQUARE-SHIELD] ABUSE_REQUESTS` | The application sent requests to Discord or to `squareweb.app` sites at an abusive rate for a sustained period. | Stops the application, and starting it fails with `CONTAINER_TEMPORARILY_SUSPENDED` for a short period. |

The help center explains the alert emails in [downtime alerts: RAM, CPU and request blocks](https://help.squarecloud.app/en-us/article/downtime-alert-ram-cpu-and-request-blocks-12ivqus/).

### LACK\_OF\_RAM

The application reached its allocated RAM, so the process was stopped to protect the host.

How to fix:

1. Find memory leaks with a profiler (Node.js: `--inspect`, Python: `memory_profiler`). See [memory leaks in Node.js](https://help.squarecloud.app/en-us/article/memory-leak-in-nodejs-how-to-find-and-fix-it-1bvgprf/).
2. Reduce in-memory caches or move them to Redis.
3. Increase the application's RAM in the dashboard, or raise `MEMORY` in the [configuration file](/en/getting-started/config-file#memory).

### LACK\_OF\_CPU

The application used all of its vCPUs for a sustained period, so the process was stopped.

How to fix:

1. Profile CPU hotspots (Node.js: `0x`, Python: `cProfile`). See [CPU at 100%: optimization tips](https://help.squarecloud.app/en-us/article/cpu-at-100-optimization-tips-nvjqse/).
2. Optimize hot loops, database queries and I/O-bound operations.
3. Increase RAM to get more vCPUs (see [CPU allocation](#cpu-allocation)).
4. Move heavy work to asynchronous workers or batch jobs.

Trade-off: increasing RAM to gain CPU raises costs. Measure whether optimizing the code is cheaper than scaling up.

### CONTAINER\_TEMPORARILY\_SUSPENDED

The logs showed `[SQUARE-SHIELD] ABUSE_REQUESTS`: the application sent requests to Discord or to `squareweb.app` sites at an abusive rate for a sustained period. This is almost always an infinite loop, a retry without a delay or a missing cache, not real popularity. The application was stopped, and until the block ends, starting it fails with `CONTAINER_TEMPORARILY_SUSPENDED`.

How to fix:

1. Read the email and the last logs to find the code that sends the requests.
2. Cache what you fetch, add a delay between retries and respect the rate-limit headers of the API you call. See [Discord API rate limits](https://help.squarecloud.app/en-us/article/discord-api-rate-limits-429-error-how-to-avoid-them-mkkz7n/).
3. Wait a moment and start the application again.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.