Limits

Time, memory, bundle, request and response ceilings — and why.

The ceilings

Limit	Default	Enforced by
Execution time	10 s	PHP's own limit and a wall-clock kill in the parent — a sleeping function burns no CPU, so the wall clock is the one that always fires.
Memory	128 MB	The runtime's memory limit. Exceeding it ends the invocation with a stated reason.
Request body	1 MB	The gateway, before dispatch — an oversized body is 413 and is not billed.
Response / output	5 MB	The parent stops reading and ends the invocation.
Bundle	10 MB, 500 files	Deployment validation, before anything is written.
Invocation rate	600 / minute per project	The gateway. Refusals are 429 and are not billed.

Higher ceilings are a plan matter; the platform maximums are 60 s and 512 MB.

The isolation guarantees

Customer code is untrusted code. Each invocation runs in a dedicated process that cannot:

read the host filesystem — /etc/passwd, C:\Windows, the platform's .env or its source;
read another project's bundle, even given its exact path — the directory does not even list;
spawn processes — exec, shell_exec, system, passthru, proc_open, popen, pcntl_fork are all disabled;
open outbound connections — allow_url_fopen off, curl and socket functions disabled;
discover platform secrets from its environment — they are not in the process;
run as a privileged user, or outlive its limits.

Each of these is a test in the platform's suite that deploys genuinely hostile PHP — an infinite loop, a memory bomb, a process-spawn probe, a file thief, an environment thief, a network probe, an output bomb — and asserts what the attacker actually got. They run on every build.

Designing within the limits

Do long work in pieces: accept the request, record it in Basket, return quickly.
Nothing persists on disk between invocations — write state to Basket, not to a file.
Install dependencies at deploy time via Composer, never at request time.