Skip to main content

Limits & quotas

Every platform boundary on one page. Where a limit is a default rather than a hard ceiling, it says so; project quotas in particular are raised on request.

Deployment size

Set per app in Settings; every deployment of the app runs at this size. See CPU, memory & storage.

ResourceValues
CPU0.5, 1, 2, or 4 cores
MemorySteps from 0.5 to 16 GB, between 1× and 4× the CPU cores (see the matrix)
Storage5–100 GB, in 5 GB steps
Default size (new apps)0.5 CPU · 1 GB memory · 5 GB storage

Storage is all-inclusive (volumes, database data, and backup history share the one budget) and can grow but never shrink. Size changes apply on the next deploy of a stopped deployment (how to resize).

Project quotas

Counted across a project's running deployments; enforced when a deploy is submitted. Defaults shown; contact support to raise any of them.

QuotaDefault
Total CPU2 cores
Total memory4 GB
Total storage25 GB
Running deployments5

Stopping a deployment releases its CPU, memory, and deployment slot. Its storage stays counted until the deployment is deleted.

Manifest

RuleLimit
Services per appAt least one; see services
Managed database services per deployment4
PostgreSQL versions"17"
Service and volume names1–64 characters: letters, digits, _, -; must start with a letter or digit (naming rule)
Ports1–65535

Healthchecks

Full field reference in Container services: healthchecks.

FieldRangeDefault
interval1s–5m10s
timeout1s–5m3s
retries1–203
start_period0s–5m0s

Logs

LogBehaviour
Build logsCaptured for every build, success or failure, and kept as the deployment's build history. Very long build output keeps its final portion: the end of the log, where errors live.
Container logsFetched on demand from the running containers, newest first, with paging back through history.
Crash outputWhen a deployment fails, the final output of its containers is captured and kept with the deployment.

Logs belong to their deployment and are removed when the deployment is deleted.

Where to go next