Skip to main content

​
Minimum Resource Requirements

Every project hosted on the Shard Cloud Platform has specific minimum resource requirements to ensure optimal performance:
  • Normal apps: A minimum of 256MB of RAM is required for hosting
  • Websites: A minimum of 512MB of RAM is required to ensure proper functionality
  • Databases:
    • MongoDB: 1024MB of RAM
    • PostgreSQL: 1024MB of RAM
    • Redis: 512MB of RAM
    • MySQL: 1024MB of RAM
The maximum RAM allocation for any application is 32GB (subject to change in future updates).

​
Service Limits

Shard Cloud enforces resource boundaries to maintain optimal platform performance and ensure equitable access for all users. These protective measures include:

​
OUT_OF_RAM

If a project exceeds the allocated RAM limit specified in its .shardcloud file (or defined in the configuration for databases), it will be flagged for violating OUT_OF_RAM and automatically shut down to preserve system stability and protect all users.

​
CPU Throttling

If a project exceeds its allocated processing capacity, it will be automatically throttled rather than terminated. The application will continue running but receive reduced CPU cycles to maintain system performance.

​
Network limit

Every project has a network bandwidth limit based on its allocated RAM over 3 days. This generous limit exists solely to prevent abuse from malicious users. If your application reaches this limit, it will be automatically stopped and blocked from restarting for 24 hours.

​
Bandwidth limit

Every project is limited to an egress/ingress bandwidth limit based on its allocated RAM. Applications and databases: the limit follows the table below, applied equally to egress and ingress. For RAM values between two tiers, the limit is interpolated linearly, and it stays at 2000 Mbps from 24GB of RAM upward. For example, an application with 512MB of RAM has 150 Mbps for both egress and ingress traffic. For databases with replicas, the limit is calculated from the RAM of each replica. Virtual machines: the limit is calculated using the formula 250 + (RAM_MB/1024) × 75, capped at 2000 Mbps. For example, a virtual machine with 4GB of allocated RAM will have 550 Mbps for both egress and ingress traffic.

​
Storage limit

Applications: All applications have a flat storage limit of 10GB. Databases: Storage limits depend on the allocated RAM using the following formula: 6 + (RAM_MB/512). For example, a database with 2GB of allocated RAM will have 10GB of storage space.

Virtual machines: Storage limits depend on the allocated RAM using the following formula: RAM_MB/60 . For example, a vps with 4GB of allocated RAM will have 68GB of storage space.

​
Max number of database connections

This limit applies only to databases (not applications). The maximum number of simultaneous connections to a database hosted on Shard Cloud is based on its allocated RAM and follows the formula: RAM_MB/6. For example, a database with 2048MB of RAM would support 341 simultaneous connections.

​
Http requests limit

This limit applies only to applications (not databases or virtual machines). Like the network limit, its main purpose is to prevent malicious users from making a large number of HTTP requests in a short period, which could result in our IPs being banned by external services. The monitoring window for this limit is 10 minutes, and if exceeded, your application will be stopped and blocked from restarting for one hour.

​
Vcpu allocation method

Every project gets a fixed amount of CPU calculated from its RAM and your plan. It is computed per project, so each app, database, and VM is sized independently, and it is recalculated whenever you resize. CPU is measured in mCPU (1000 mCPU = 1 vCPU). Your plan’s vCPU count is always the upper bound for a single project. No project can be allocated more CPU than the plan allows.

​
Apps and databases

Apps and databases use the same formula.
  • Under 1024 MB of RAM: 1 vCPU (1000 mCPU).
  • 1024 MB of RAM or more: 2 vCPU (2000 mCPU) for the first 1024 MB, plus extra CPU for every additional GB of RAM, only as far as your plan allows. The plan cap applies to the 2 vCPU too, so on a 1 vCPU plan a project never gets more than 1 vCPU.
On the 1 vCPU plans (Free and Basic 1 GB) every project stays at 1 vCPU, since that is the plan cap. Databases with the visualizer: the visualizer adds 512 MB of RAM to the database, but that extra RAM is not counted. The CPU is calculated from the database’s own RAM only. Examples (values in vCPU): n/a means the project would not fit in the plan’s RAM.

​
Virtual machines

VMs do not use the app formula. A VM gets a share of your plan’s vCPU that is proportional to its share of the plan’s RAM:
  • Reference RAM is your plan’s RAM. On Enterprise plans it is fixed at 32 GB, regardless of the plan’s total RAM, so larger Enterprise plans do not dilute the CPU of a 32 GB VM.
  • The result is capped at the plan’s vCPU.
  • A VM always gets at least 2 vCPU.
  • The result is rounded to the nearest whole vCPU, with halves rounded up.
Examples (values in vCPU): n/a means the VM would not fit in the plan’s RAM.