Resources

Use these requirements to size the cluster before running helm install.

Minimum (evaluation / small teams)

These numbers assume the full default stack: Platform UI, Agentic, Cortex, Analytics, the bundled Postgres, SeaweedFS, and a single-pod StarRocks for Managed Tables. To run on smaller nodes (4 vCPU / 16 GB), trim the optional components. See Helm → Trimming for low-resource installs.

Recommended (production)

Note: GPU resources are contractually licensed (your license JWT reflects your entitlement), but Scrydon does not runtime-enforce GPU limits. GPU nodes are only needed if you plan to run local inference models inside your cluster.

Per-service memory

The Helm chart sets these per-pod memory requests and limits for single-replica defaults. The request is what the scheduler reserves. Your node pool must satisfy the sum of requests for enabled services before pods will schedule, so it is your reserved floor. The limit is the burst ceiling before a pod is OOM-killed.

To size node pools: sum the requests as the reserved floor, check the sum of limits for worst-case burst, then add ~30% headroom for kube-system pods, Dapr sidecars (~250 MiB each), the Dapr control plane, and small bundled infra such as OPA / Lakekeeper (~128 MiB each).

Isolated notebook compute is additional and schedules in runtimePlane.workloadNamespace. Each active interactive runtime reserves 4 GiB for Marimo plus 1 GiB for source control, 512 MiB for its broker, and 128 MiB for the egress enforcer (5.625 GiB total). A notebook job reserves 4 GiB for its runner plus 128 MiB each for its broker and enforcer (4.25 GiB total). Size the Kata/KVM node pool for expected concurrent sessions and jobs; opening documents does not consume this capacity.

Limits were last revised on 2026-05-18 (v1.3.5-rc.54 binary-minification rollout, PR #1142, which roughly doubled steady-state RSS for the SSR apps; the platform limit was subsequently raised to 2 GiB on 2026-05-29). Requests were right-sized on 2026-07-06 (PR #2257) to track measured steady-state RSS. The previous requests understated real usage 2-4x, so the scheduler over-packed nodes and pods were evicted mid-rollout under memory pressure. If you upgrade across either boundary on a pre-existing cluster, verify your node pool has headroom before running helm upgrade.

AI Gateway

The AI Gateway runs inside the api-platform pod, so its cost lands on that Deployment's CPU rather than on a service of its own. The chart ships auth.resources at a 500m request and a 2000m limit. That default carries the control-plane traffic api-platform already serves; router traffic is additional, and is the one workload on this page that scales with how your people work rather than with how many services you enabled.

What one turn costs

A turn's CPU cost is a small fixed part plus a part that scales with the number of streamed events, not with the number of bytes. Your DLP posture changes the per-event term, so there are three curves rather than one:

The event term is the one that matters. A coding agent streams roughly one event per generated token, so a turn that writes 600 tokens costs about five times a turn that writes 100 — even though both are small responses. Note that DLP is almost entirely a per-event cost, not a fixed one: it inspects the stream as it passes, so a longer answer pays more.

Prompt size is close to free by comparison: a 150 KB prompt costs about the same as a 16 KB one, because the router parses a request once and does not re-read it.

enforce also adds a consistent ~11 ms to time-to-first-token — it releases the stream in governed 512-character windows and holds back a 256-character tail so a finding straddling a boundary is still caught. That cost is flat: it does not grow with the length of the answer. audit adds no measurable TTFT, because it inspects without holding anything back.

Sizing for a developer population

Size from turns per second, not from how many developers hold an account. A developer with an agent open is not streaming continuously — they read, edit, and think between turns. The fraction of time their tool is actually streaming is the duty cycle, and it is the number that decides your CPU.

For 1 000 developers issuing typical 600-token turns of roughly 15 seconds each:

Provisioned vCPU below is at a 65 % utilisation target, for all three DLP modes:

Turning DLP on costs roughly 25 % more CPU per turn in audit and 50 % in enforce, on a typical agent turn. That is a real cost but rarely the deciding one — the replica count below moves first.

Validating your own numbers

The figures above are a starting point, not a substitute for measuring your own traffic. Turn length, DLP posture, and how agent-heavy your developers are all move the result by more than the modelling error. Once traffic is real, the metrics on the AI Gateway capacity section tell you where you actually are:

• scrydon_llm_router_streams_in_flight against your maxInFlight — how close a pod is to shedding.
• scrydon_llm_router_admission_rejections_total — sustained non-zero at steady state means add a replica, not client retries.
• scrydon_llm_router_overhead_ms versus scrydon_llm_router_provider_ttfb_ms — separates time your platform spent from time the provider spent, so you can tell a capacity problem from a slow model.