Resource limits and quotas

The portal displays the exact orderability and configuration limits currently available to an App or Team. The following rules remain stable when numeric ceilings change.

Purchased shape

• The purchased CPU, memory, and storage amounts are the billing and enforcement envelope.
• Customer service reservations and platform workload floors must fit inside that envelope.
• Extra copies of the PHP runtime that synsmarts adds under load, up to the App’s maximum copies, can run above the purchased shape. Their CPU and memory use is metered as burst. With Never spend more than my plan or a spending limit, PHP stays at the copies the plan includes.
• A smaller shape is rejected if a required service minimum no longer fits.
• Storage can grow but can’t be reduced through self-service.

Memory classes

• MySQL, the Valkey session/cache/config-cache roles, OpenSearch, RabbitMQ, Varnish, and NFS are reservable services. Customer memory is the request and reservation, so these services don’t memory-burst past it.
• NFS is the exception: its reservation is the request and its limit is 1 GiB or the reservation, whichever is larger.
• PHP-FPM, Nginx, the managed shell, and the WAF are dynamic workloads. They have platform floor requests, no memory limits, and no customer memory fields.
• Scheduled Jobs run outside the purchased shape: a fixed platform floor, no memory limit, and their CPU and memory use metered as burst.
• Dynamic workloads consume the unallocated headroom left after platform costs, service reservations, and workload floors. PHP-FPM worker count and OPcache derive from that headroom.
• Each shell or scheduled PHP command has a separate finite memory_limit. Reaching it stops that command and reports a PHP fatal to stderr with default logging settings. Node memory pressure can still end the shell and all its sessions. Files in the shell’s /tmp count toward actual memory usage.
• Legacy dynamic memory fields are ignored on read and rejected on write with DYNAMIC_MEMORY_NOT_EDITABLE.

CPU burst

• The portal offers four spike modes: Always keep my site fast, Keep my site fast, with a spending limit, Never spend more than my plan, and Custom, per container.
• Custom, per container exposes Off, Capped, and Unlimited for CPU where the container class allows it.
• A cap is a multiple of the configured request, above 1× and inside the allowed platform range. The multiple is what’s stored, so a plan resize re-derives the cap.
• The App’s total CPU and memory use above the purchased shape is metered as burst. A share of each month’s burst minutes is included at no charge.
• CPU burst choices apply to every container, managed services included. The Burst tab has no dynamic-workload memory control.

Storefront request rate

• Each hostname of an App accepts up to 300 requests per second per purchased CPU core at each edge proxy, with a burst of twice that. A 2-core App gets 600 requests per second and a burst of 1,200 on every hostname.
• Fractional cores round up. A plan resize applies the new rate when the resize finishes.
• The platform runs three edge proxies, and each one counts its own requests. A CDN reaches the origin over few connections, which can land on one proxy, so plan on the single-proxy figure rather than three times it.
• A request above the rate gets 429 Too Many Requests from the edge before it reaches the WAF or the App.
• This limit is per hostname. A WAF rate limit rule limits one visitor on one path, and both apply.

Request time

• Every hop the platform runs in front of PHP (the edge proxy, the WAF, the page cache, and the web server) allows a request 300 seconds, the highest max_execution_time you can set.
• Cloudflare’s proxy ends a request after 100 seconds with HTTP 524. A request to a hostname served through Cloudflare’s proxy can run for 100 seconds; run longer work, such as a large import or reindex, from the managed shell or a scheduled job.

Storage expansion

• Database and workspace storage can use automatic expansion.
• Media storage isn’t automatically expanded by this control.
• Each expansion permanently raises the purchased amount.
• A configured ceiling is never silently exceeded.

Message broker queues

• RabbitMQ queues have no message-count limit. The broker doesn’t delete queued messages to make room, so a large bulk import keeps every operation.
• Queued messages use the broker’s storage, which is sized from the purchased shape with a 5 GB minimum. When free space falls to a quarter of that storage, the broker holds every publisher until consumers free space. Requests that publish, such as Magento’s asynchronous bulk API, wait instead of losing a message.

Configuration counts

• An App can have up to 50 scheduled jobs.
• An App can define up to 50 domains.
• An App can have up to 32 SSH users.
• A Team can save up to 10 payment cards.
• A Team can have up to 50 active members by default, and support can raise a Team’s limit. The limit is enforced when an invitation is accepted; pending invitations don’t occupy a seat.

Configuration sizes

• A settings file can be at most 256 KiB.
• Each secret value must be 60 KiB or smaller.
• Maintenance-page assets and support attachments have their own size and format limits, listed with those features.

Source of truth

Use the limit shown in the portal for the current App or Team. App limits also depend on region, framework, and service catalog. If a documented numeric example differs from the portal, the portal’s validated value controls the accepted configuration.