Resource Limits & Quotas

Resource limits decide how much CPU and RAM each preview environment can use. Quotas decide how many previews you can run in total. Both exist so that one runaway branch doesn't starve the rest of the network — or your own account.

Per-Application CPU and Memory Limits

Each project can specify CPU and memory limits that apply to the application container in every environment. These limits are enforced by containerd via Linux cgroups.

• CPU limit — Specified in cores (e.g., 0.5, 1, 2, 4). Uses CFS bandwidth control to throttle the process when the limit is exceeded. Your application slows down but is not killed.
• Memory limit — Specified in megabytes (e.g., 512, 1024, 4096). If your application exceeds this limit, the container is OOM-killed by the kernel and automatically restarted.

Set limits in the dashboard under project settings, or in your platform.yaml:

resources:
  cpu: 1        # 1 CPU core
  memory: 1024  # 1024 MB (1 GB)

If no limits are set, defaults from your pricing tier are applied. Hobby tier defaults to 2 CPU and 4096 MB. Pro defaults to 8 CPU and 16384 MB.

Build-Time CPU, Memory, and Timeout Limits

Builds run inside BuildKit and can consume significant resources. You can set separate limits for the build phase:

• Build CPU — Maximum CPU cores during the build. Higher values speed up compilation-heavy builds. Default: 2 cores.
• Build memory — Maximum RAM during the build. Increase this for builds that load large assets or run memory-intensive tools. Default: 4096 MB.
• Build timeout — Maximum build duration in seconds. Builds exceeding this limit are automatically cancelled. Default: 600 seconds (10 minutes).

resources:
  build_cpu: 2       # 2 CPU cores for builds
  build_memory: 4096 # 4 GB for builds
  build_timeout: 300 # 5 minute timeout

Build timeouts are particularly important for preventing hung builds from consuming node capacity indefinitely. If a build exceeds its timeout, the deployment is marked as failed and the node resources are released.

User Quotas

Account-level quotas prevent any single user or team from monopolizing the compute network. Quotas are determined by your pricing tier:

When you hit a quota limit, new deployments are queued rather than rejected outright. You receive a notification in the dashboard and can free up capacity by pausing or destroying environments you no longer need.

How the Scheduler Uses Resource Requirements

When a deployment is triggered, the scheduler reads the project's resource requirements (CPU, memory, storage) and uses them to select an appropriate node:

1. Filter — Nodes without enough free capacity are excluded from consideration.
2. Score — Remaining nodes are scored based on available resources, cache affinity (has this project been built here before?), and geographic proximity.
3. Select — The highest-scoring node is selected and the build job is dispatched via gRPC.
4. Reserve — The requested resources are reserved on the node until the environment is destroyed, preventing over-provisioning.

This means setting accurate resource limits is important not just for runtime behavior but for efficient scheduling. If you request 4 CPU cores but your app only uses 0.5, you are reserving capacity that other environments could use.

Quota API Endpoint

Check your current usage and limits programmatically via the quota endpoint:

GET /api/quota
Authorization: Bearer nxs_your_api_key

Response:

{
  "plan": "pro",
  "usage": {
    "projects": 12,
    "total_cpu": 14.5,
    "total_memory_mb": 29696,
    "build_minutes_used": 2340
  },
  "limits": {
    "max_projects": 25,
    "max_cpu": 64,
    "max_memory_mb": 131072,
    "build_minutes": 5000
  },
  "percentage": {
    "projects": 48,
    "cpu": 22.6,
    "memory": 22.6,
    "build_minutes": 46.8
  }
}

Use this endpoint to build internal dashboards, set up alerts when approaching limits, or automate cleanup of idle environments.