Scaling and RAM

RAM is the one dial. Set a project’s RAM in 256 MB steps and its CPU cap follows; there is no separate CPU setting.

Scaling RAM

Your agent reads and sets it over MCP:

1. Read the state. nyx_project_state <project> returns allocatedMb, reservedMb, floorMb, and remainingPoolMb: what’s allocated, what running pods hold, and what’s free in the account pool.
2. Size from the repo, not a guess. The framework, sidecars, and ML libraries tell you what the workload needs.
3. Set it. nyx_project with action: ram and mb: <needed> rounds up to the next 256 MB step. The CPU cap rises with it.

The CPU cap is derived from RAM at allocatedMb * 500 / 1024 millicores, summed across every pod in the project:

RAM	CPU cap
256 MB	125m
512 MB	250m
1024 MB	500m

If the account pool has no room, shrink another project or have a person book RAM packs in the console. Never half-apply a deploy that’s short on RAM.

Every project and app shows live memory and CPU against its allocation, so you size from what actually runs:

Memory · 24h3.4 GB used · 4 GB allocated

What changes the bill

Three numbers are easy to mix up. Only the first one costs money beyond your plan:

• Your plan fee covers the baseline pool (8 GB on Starter, 48 GB on Business).
• RAM packs add 1 GB each to the account pool at €5 per month, billed by the day you hold them (at least one day). A person books and releases them under Settings → Subscription in the console, within the spend limit you set there. Your agent can read the pool (nyx_project_list) but not book packs.
• Project allocations and pod usage only divide the pool. Lowering an allocation with nyx_project (action: ram) frees room in the pool for other projects; kubectl scale or deleting an app frees room inside the project. Neither changes the bill.

To save money after a peak: lower the project allocations with nyx_project (action: ram), then release the packs you no longer need. The console refuses a release while allocations still need that capacity.

Scaling out: more than one replica

Vertical scaling covers most workloads. To run several replicas behind one Service:

• Stateless tiers scale freely. No local state between requests (no SQLite on disk, no local uploads, no in-process sessions) and no PVC, or only an emptyDir. Set replicas as high as the project’s RAM allows.
• Stateful tiers stay single-replica or go StatefulSet. App PVCs are ReadWriteOnce and bind to one node, so a second replica on another node can’t mount the volume and sits in ContainerCreating. Databases, caches, and queues run at replicas: 1; real HA is a StatefulSet with one PVC per pod plus app-level replication. The access mode is set when the volume is provisioned; editing the Deployment can’t widen it.

Rule of thumb: scale the stateless tier out, the stateful tier up. Shared read-write storage across replicas isn’t offered to apps today.

Sizing a pod

Size small web pods around 50 to 100m CPU; don’t copy a flat "1" or "200m" from elsewhere. Every container needs requests and limits for CPU and memory:

• Deployed with nyx_deploy_manifests, a container without them gets small defaults filled in (requests 50m / 64Mi, limits 100m / 128Mi), and the tool says so. Treat that as a floor and set real values.
• Applied any other way (for example kubectl apply), a container without limits is refused by the project’s quota.
• limits.cpu over the cap fails with exceeded quota: limits.cpu (FailedCreate); no pod is created.

Note: Shrinking a project’s RAM below what its running pods reserve fails with a 409 (below_reserved), returning requestedMb, reservedMb, and floorMb. Delete an app first, or pick an mb value at or above floorMb.

Limits outside the dial

• Pod count per project is capped by plan.
• Storage comes from a separate pool: your plan’s storage plus storage packs (100 GB each), not from RAM.
• LoadBalancer / NodePort services are always 0; the ingress is the one way in from outside.

See Projects & accounts for how workspaces, projects, and the pool relate.