Capacity & Limits

Detected per-process limits plus admin-declared ceilings, with Docker / Kubernetes guidance.

Detected limits (this process)

Cgroup-aware. Reflects what the running backend can actually use.

Disk (process root)

What df sees from inside the process. In a container this is the overlay/bind.

Capacity targets

Human-known ceilings auto-detection can't see — set these to make the gauges meaningful.

Declared ceilings

Resources the platform was sized for. Super-admin only.

Postgres disk capacity

Volume size provisioned for the database (EBS / managed-DB plan).

Unset

MinIO storage quota

Total quota for object storage. Leave 0 for unbounded host-disk.

Unset

Target total users

What this deployment is sized for. Drives the headroom indicator.

Unset

Target concurrent users

Peak online users you've sized the WebSocket layer for.

Unset

Target messages / day

Daily message volume the storage + queue is sized for.

Unset

Expected backend replicas

Number of pods / uvicorn workers. Used to compute total platform capacity.

How this works in Docker & Kubernetes

Why "true system capacity" is non-trivial in orchestrated deploys

The bare-metal trap. Inside a Docker container or Kubernetes pod, naive Python (psutil.virtual_memory()) returns the host's memory and CPU — not the cgroup limit the container is bound by. A 4 GB pod on a 64 GB host would report 64 GB and the pressure gauge would always show ~6%. This backend reads cgroup v2 (/sys/fs/cgroup/memory.max, cpu.max) first, falls back to v1, then psutil as a last resort.

"Detected limits" means this process. The tiles above reflect what one running backend container/pod can use. If you scale horizontally (3 replicas × 4 GB each), the platform's total backend RAM is 12 GB — the multiplier card above shows that.

Shared services are not per-replica. Postgres, MinIO and Redis live outside the backend process. Their capacities are not bounded by the backend container's cgroup, so admins must declare them above. The Redis gauge already uses an admin-controlled max; Postgres and MinIO use capacity_postgres_disk_bytes and capacity_minio_bytes respectively.

For accurate Kubernetes detection, inject the downward API into your pod spec so the page can label things:

env:
- name: POD_NAME
  valueFrom: { fieldRef: { fieldPath: metadata.name } }
- name: POD_NAMESPACE
  valueFrom: { fieldRef: { fieldPath: metadata.namespace } }
- name: NODE_NAME
  valueFrom: { fieldRef: { fieldPath: spec.nodeName } }

Verify cgroup limits are actually set. If you see the "no cgroup memory limit detected" warning above, your container is running unconstrained. Add limits to your runtime:

docker run --memory 4g --cpus 2 …
kubectl … resources.limits: {memory: 4Gi, cpu: '2'}
For docker-compose: deploy.resources.limits.memory: 4G