Skip to content

Projects & accounts

Your account is the top-level container — it owns billing, members, and the resource pool. Projects live inside your account; each project is an isolated environment where your apps run. Most users start with one or two projects (e.g. staging, prod) and grow from there.

Each project has its own ceiling — CPU, RAM, and storage. Your account has a pool: the sum of your tier baseline plus any extra packs you’ve added. Project ceilings draw from that pool.

If your pool is 8 GB and you’ve assigned 5 GB to prod and 2 GB to staging, your remaining pool is 1 GB. Bumping staging to 4 GB would need either: a) shrinking prod first, b) buying an extra pack, or c) opting into overdraft.

Overdraft is opt-in headroom you control with a slider in the console. Default is 0 GB. You set the ceiling explicitly because overdraft adds to your bill the moment it’s used — we never silently exceed your tier.

A typical pattern: leave overdraft at 0 during normal ops; bump it to 2 GB before a known-spiky release, then dial back when the load settles.

When your agent wants to deploy something larger than the current project ceiling, the recommended pattern is:

  1. Check the pool: nyx_account_ram returns the pool baseline + remaining headroom.
  2. Check the project: nyx_project_state <project> returns the current allocation and floor.
  3. Resize: nyx_project_resize <project> --mb <new> if the pool covers it.
  4. Otherwise: the agent surfaces “subscription upgrade needed” with a link, rather than silently failing.

Your agent does this without prompting — the cookbook recipe for nyx_deploy_start includes the decision tree. You’d only see the upgrade prompt if the pool genuinely can’t accommodate the request.

Per-project gauge, account-pool gauge, and the overdraft slider live in the console at Projects → <name> → Resources. The same numbers are visible from the CLI via the nyx account / nyx project commands.

Next: The cookbook →