Helm

This is the configuration reference for the Scrydon Helm chart. It documents a condensed install and the operationally significant value groups — what each key does, why you'd change it, and how. If you just want the fastest path to a running cluster, start from your Location page (On-Premise, Azure (AKS), Air-Gapped) and come back here for the options.

For an air-gapped cluster (no outbound internet), use Air-Gapped Deployment instead — the same chart ships inside a Zarf package.

How configuration works

Three layers, lowest to highest precedence:

1. Chart defaults — the chart ships sane production defaults for everything. The authoritative list is the chart's own values.yaml (see Inspect the chart locally).
2. Your values.customer.yaml — the file you pass with -f. Override only what you need; everything else inherits the default.
3. --set flags — highest precedence, useful for resolving secrets at install time from a secret manager.

helm install scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> -n scrydon-platform \
  -f values.customer.yaml \
  --set apiTable.secrets.STARROCKS_PASSWORD="$(vault kv get -field=password kv/scrydon/starrocks)"

Secrets live in your values file. values.customer.yaml and helm get values <release> both echo every user-supplied value. Keep the file out of source control, or manage it via Sealed Secrets / SOPS / External Secrets Operator, and restrict cluster RBAC on the release Secret.

Inspect the chart locally

The chart is an OCI artifact in scrydonops.azurecr.io — there is no public Git mirror. Pull it to read every template and the full default values.yaml:

helm pull oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> --untar
less scrydon/values.yaml   # the authoritative default for every key below

Validate your configuration

The chart ships a values schema (values.schema.json). It rejects unknown or mistyped keys at the top level and in high-risk strict groups such as routing, gateway, license, namespaces, Pod Security, and NetworkPolicy. Some application blocks — including nested runtimePlane keys in current charts — remain permissive, so schema validation is necessary but not sufficient. A typo like routing.mdoe fails immediately:

Error: values don't meet the specifications of the schema(s) in the following chart(s):
scrydon:
- routing: Additional property mdoe is not allowed

Before an install or upgrade, run a preflight against your values and your cluster version:

# 1. Schema + lint — catches typo'd keys and structural mistakes
helm lint ./scrydon -f your-values.yaml

# 2. Render and validate against your Kubernetes version
#    (kubeconform: https://github.com/yannh/kubeconform)
helm template scrydon ./scrydon -f your-values.yaml \
  | kubeconform --strict --ignore-missing-schemas \
      --kubernetes-version "$(kubectl version -o json | jq -r '.serverVersion.gitVersion' | tr -d v)"

# 3. Dry-run the install against the live cluster (server-side validation)
helm install scrydon ./scrydon -f your-values.yaml --dry-run=server

The chart requires Kubernetes 1.28 or later (kubeVersion: ">=1.28.0-0") — helm install refuses older clusters with a clear error rather than failing mid-deploy.

Quick install

The minimum to a running cluster. Each step is expanded with environment-specific notes on the Location pages.

# 1. Log in to the registry (username = ACR token name from your account team)
helm registry login scrydonops.azurecr.io --username <acr-token-name>

# 2. Create the release namespace + an image-pull secret in it.
#    The chart defaults every service to scrydon-platform; split namespaces
#    are opt-in via namespaces.* (create the secret in each one you target).
kubectl create namespace scrydon-platform 2>/dev/null || true
kubectl create secret docker-registry scrydon-registry --namespace scrydon-platform \
  --docker-server=scrydonops.azurecr.io \
  --docker-username=<acr-token-name> --docker-password=<acr-token-password>

# 3. values.customer.yaml — the entire minimal install.
global:
  imageRegistry: scrydonops.azurecr.io   # pull images from the ACR you logged into
  imagePullSecrets:
    - scrydon-registry
  storageClass: <your-storage-class>     # cloud default class name, or your on-prem provisioner

routing:
  host: app.example.com                  # the hostname your DNS points at

gateway:
  tls:
    enabled: true                        # browser reaches Scrydon over HTTPS — see Gateway below

infra:
  db:
    credentials:
      password: REPLACE-WITH-DB-PASSWORD          # openssl rand -hex 16
auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET         # openssl rand -hex 32
apiTable:
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PW # openssl rand -hex 24

# 4. Install
helm install scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> --namespace scrydon-platform \
  -f values.customer.yaml --wait --wait-for-jobs

Run the setup wizard

Open https://app.example.com/platform/setup (or /setup if you mounted platform at the root). Six steps:

Pre-seed the license

Skip the wizard's license step by giving the chart the jwt field of your license file on first install. The value is read once to seed the DB, after which the license lives in platform_config and is managed in the UI:

auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET
    LICENSE: "eyJhbGciOiJNTC1EU0EtNjUi…"     # the file's `jwt` field

When it is set, the wizard's License step opens already verified. There is no public-key value: auth.secrets.LICENSE_PUBLIC_KEY is ignored in production, and the upgrade deletes any public-key row it stored.

Configuration reference

Every group below maps to a top-level key in the chart's values.yaml, in file order. Defaults shown are the chart defaults; override only what you need.

global — registry, images, storage

Cluster-wide settings every service inherits.

global:
  imageRegistry: scrydonops.azurecr.io
  imagePullSecrets:
    - name: scrydon-registry
  storageClass: managed-csi

namespaces — workload placement

Every service defaults to scrydon-platform. Override per service for multi-namespace isolation; the chart auto-aligns Dapr ACL policies and the secret-reader RBAC.

namespaces:
  infra: scrydon-infra
  platform: scrydon-platform
  agentic: scrydon-agentic
  analytics: scrydon-platform
  cortex: scrydon-platform

gateway — exposure and TLS scheme

The edge is the Kubernetes Gateway API (Gateway + HTTPRoute), not Ingress. Ingress is frozen: it is still GA, keeps its stability guarantees, and Kubernetes has no plans to remove it — but it receives no further development, and Kubernetes recommends the Gateway API in its place. The chart follows that recommendation.

The chart renders one Gateway called gateway-frontdoor in the platform namespace and one HTTPRoute per enabled app in that app's own namespace, attached across namespaces to the single Gateway.

Three controls that used to be per-controller annotations are now core Gateway API and are rendered unconditionally, so they exist on every conforming implementation instead of only on Traefik:

• The Dapr / on-behalf-of header strip. Every forwarding route rule carries a RequestHeaderModifier filter that removes dapr-caller-app-id, dapr-api-token, x-scrydon-self-call, the x-on-behalf-of-* identity headers and x-scrydon-storage-scope from external requests. There is no class branch and no mode that can silently emit nothing, so ingress.stripDaprHeaders.* — and the install warning that went with it — is gone with no replacement.
• The HTTP → HTTPS redirect. A RequestRedirect filter on the HTTP listener, rendered whenever gateway.tls.enabled. ingress.middleware.forceHttps.* is gone with no replacement.
• Path precedence. The spec mandates longest-matching-prefix first across every route on a listener, so declaration order no longer matters and the apex / rule is simply the lowest-precedence one.

Internal service paths are not published. On every hostname, /api/internal beneath each app's root (/api/internal, /platform/api/internal, /agentic/api/internal, and so on) matches a rule with no backend, so the gateway answers 500 and never forwards the request; those routes are reachable only inside the service mesh. This is core Gateway API too.

Certificate choices for Let's Encrypt, private-only domains, internal ACME, and static corporate certificates are covered in TLS Certificates.

Listener ports: 8000 / 8443, not 80 / 443

gateway.listenerPorts.* is the port your controller listens on, not the port your users connect to. It is the one implementation-specific value in the whole edge.

Traefik matches a Gateway listener to one of its own entryPoints by port, and those entryPoints bind :8000 (web) and :8443 (websecure) inside the container while its Service publishes 80/443. A listener declared on port 80 is rejected outright (verified on Traefik v3.6.10, 2026-09-12):

Accepted=False  reason=PortUnavailable
"Cannot find entryPoint for Gateway: no matching entryPoint for port 80 and protocol HTTP"

A managed implementation that listens on the public port — Application Gateway for Containers, a cloud ALB — wants 80 / 443 here instead:

gateway:
  className: <your-gatewayclass>
  listenerPorts:
    http: 80
    https: 443

Other Gateway API implementations

Set gateway.className to your GatewayClass and the routing works unchanged: the chart emits only core Gateway and HTTPRoute resources, with no controller annotations on any route. Two things to get right before you switch:

Anything the chart does not express — request-body limits, read timeouts, WebSocket idle behaviour on the routing.paths.agenticRealtime route — is configured on your implementation itself rather than through this chart; gateway.annotations is the only annotation hook and it lands on the Gateway, not on the routes. Size the request-body limit at least as large as the platform's 100 MB upload cap.

One portable note: implementations whose backend health check defaults to / see a redirect chain from the SSR apps. Point the check at each app's /api/healthz using whatever health-check mechanism your implementation provides.

routing — subpath vs subdomain

Chooses how apps are exposed. Full discussion: Routing Modes.

routing.annotations is gone. It existed only because a subpath install had exactly one Ingress and no other way to annotate it; both routing modes now render one Gateway, so gateway.annotations is that place — see Other Gateway API implementations.

routing:
  mode: subpath
  host: app.example.com
  paths:
    cortex: /scrydon/cortex      # customize prefixes if needed
    platform: /scrydon/platform

dapr — service mesh and identity

Service-to-service calls use Dapr with mTLS; the chart's ACL policies key on the SPIFFE trust domain.

Bringing your own Dapr requires the chart-tested 1.18.1 version, trust domain scrydon (or match it via dapr.trustDomain), and a running sidecar injector. See Existing Dapr installations.

Database — bundled Postgres or BYO

infra.db controls the bundled Postgres (pgvector). For an external/managed instance, the full recipe — per-provider notes, infra.db.external.* keys, pre-creating databases — is on BYO Database.

# Bundled (default) — just set a strong password:
infra:
  db:
    credentials:
      password: REPLACE-WITH-DB-PASSWORD
# BYO managed Postgres:
infra:
  db:
    enabled: false
    external:
      existingSecrets:
        auth: scrydon-auth-db
        agentic: scrydon-agentic-db
      lakekeeperUrl: "postgres://scrydon:REDACTED@pg.example.com:5432/lakekeeper"
      sslMode: require

StarRocks — Managed Tables (OLAP)

Single-pod allin1-ubuntu. Backs the Tables UI and the agentic schema-inference fallback. Pairs with apiTable.

For multi-AZ production, switch to the starrocks-kubernetes-operator (FE/BE split), set apiTable.starrocks.replicationNum to match its BE count, and point apiTable.starrocks.host at its FE Service.

SeaweedFS — object storage

Single-pod S3-compatible storage for uploads.

One replica on a ReadWriteOnce volume, so a rollout of it (a chart upgrade that changes its image or credentials) stops the old pod before the new one starts. Table writes during that window are answered 503 object_store_unavailable and retried. The pod is marked ready only once its master lists a storage node, which keeps the window to a few seconds. Point the platform at managed S3 if you need storage that stays up through upgrades.

Deployment default store

Where every organization without S3 or Azure storage of its own keeps its files, under orgs/<organizationId>/ in one bucket. Only auth (api-platform) resolves storage, so only it receives the STORAGE_DEFAULT_S3_* env. Without a default, those organizations cannot upload until an admin configures storage, and the setup wizard's storage step becomes mandatory.

Application services

The product apps — auth (api-platform), platform, cortex, horizon, analytics, apiOntology, apiTable, agentic (app + realtime). Each block shares a common shape (horizon is the stateless exception: no database, no Dapr sidecar, always in the platform namespace, and horizon.copEnabled gates only its tactical picture surfaces):

Notable app-specific keys:

auth:
  secrets:
    AUTH_SECRET: REPLACE-WITH-AUTH-SECRET   # session signing — openssl rand -hex 32
  auditLog:
    enabled: true                           # SIEM forwarding + retention crons (ADR 2026-04-16)
    chain:
      enabled: false                        # tamper-evident hash chain — opt-in, has signing cost
  maxInFlight: 64                           # open calls per pod, shared by router, platform API and MCP (429 past it)
  bodyRead:                                 # a request body must keep arriving (400 body_read_too_slow)
    graceMs: 10000                          # before the rate floor applies
    minBytesPerSecond: 65536                # lower both for clients that upload over slow links

analytics:
  marimoDocument:
    enabled: true                           # private, compute-free document renderer
  marimoRuntime:
    startupDeadlineMs: 300000               # Connect/Run preparation deadline
  appRevalidation:
    enabled: false                          # re-pin published apps after a runtime upgrade (staging first)
  secrets:
    MARIMO_RUNTIME_HMAC_SECRET: ""           # blank → generated and reused across upgrades

apiOntology:
  secrets:
    APP_PUBLICATION_SIGNING_SECRET: ""       # blank → generated and reused across upgrades

apiTable:
  starrocks:
    host: ""                                # blank → bundled FE Service; set for external StarRocks
    user: root
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PW

agentic:
  realtime:
    gateway:
      hostname: ws-agentic.example.com      # subdomain mode only
  passkey:
    rpId: example.com                       # subdomain mode: required, the domain every app host shares
    origin: https://app.example.com         # subdomain mode: required. Subpath mode derives both from routing.host

apiOntology.secrets.APP_PUBLICATION_SIGNING_SECRET — signs app-publication validation seals (Analytics signs, api-ontology verifies). At least 32 bytes. Set it only here; the chart renders the same value into both Secrets. Empty reuses the live value or generates one; with global.requireExplicitSecrets=true it must be set. The key lives only under apiOntology; setting it under analytics.secrets fails the render.

The realtime sticky-cookie annotations are gone. They only ever applied in subdomain mode, and session affinity for Gateway API backends is not part of the standard channel — so agentic-realtime has no affinity if you run it with more than one replica in subdomain mode. It ships replicas: 1, which is also what the PodDisruptionBudget settings below assume.

auth.secrets.SERVICE_ADMIN_TOKEN is deprecated — production uses Dapr mTLS (SPIFFE). Only set it for local dev without sidecars. Where underscore keys are disallowed (Azure Marketplace protected settings), use auth.authSecret instead of auth.secrets.AUTH_SECRET.

executionFabric and runtimePlane

The runtime plane is opt-in until its Kata/KVM substrate and network controls are qualified. It owns fresh Agent exec pods, long-lived generation-fenced Marimo sessions, and fresh single-use notebook jobs. Opening a notebook still uses the compute-free document renderer; Connect, disconnected Run, and jobs refuse when the plane is unavailable. Marimo compute never falls back to a product-service process. Deployed backends and authenticated, profile-specific readiness determine which tiers are available. The resolver always tries microvm first, then managed_process only when the organization permits it. The generic managed-process actor host renders by default (the normal tier); enabling a qualified Runtime Plane adds the isolated tier without another allow-list or preference value. An organization admin turns on Require isolated execution under Settings → Platform → Compute to make the microVM a hard floor for that organization — its executions then refuse rather than use the managed-process tier. A bound execution never downgrades after it starts.

The chart refuses to render when neither execution backend is deployed. That combination used to install silently and every execution then failed at runtime with "No permitted … execution tier is currently ready"; it now fails at helm install time with the values paths to fix. A strict production posture that wants microVM only sets managedProcess.enabled: false explicitly — see values.production.example.yaml.

The managed tier is one generic Dapr actor-host Deployment and image. Dapr owns placement and horizontal routing; each invocation gets a fresh child process tree and workspace while reusing the same Agent, implementation, and notebook runners as the microVM backend. It shares the actor-host pod kernel and is explicitly weaker than a microVM.

Standard Agents always use AgentCapabilityContract with the fixed agent-capability-contract protocol. There is no integration-tool broker mode to enable during install or upgrade, and no operator value selects another Agent architecture. The chart pins the named protocol into Runtime Plane; an incompatible runner image is refused before an Agent workload is created.

The chart replicates your global.imagePullSecrets from the release namespace into the two runtime namespaces at install/upgrade time, so private registries work without extra steps. (helm template-then-apply pipelines have no cluster to read from — pre-create the pull secrets in both runtime namespaces in that workflow.)

Marimo runtime sizes

Each organization picks a size for notebook editors (default small) and for published apps (default xsmall) in Settings → Compute. On Kubernetes a size sets only the marimo container's resources; sidecars and ephemeral storage are fixed:

Lowering maxSizeTier takes effect when the Runtime Plane restarts with the new value, and that restart stops every runtime running above the new cap: each one ends with the failure code size_tier_above_ceiling and its resources are removed. Runtimes at or below the cap keep running. The first start of this release also rebuilds the plane's runtime registry table once, keeping its rows, so it can record that code. A size that no node can schedule is not refused up front: the pod stays pending until provisionTimeoutSeconds elapses and the attempt fails as a startup timeout. Keep maxSizeTier at or below what your Kata node pool can place.

Lower maxSizeTier only after API Platform and Analytics both run this release. The restart that stops a runtime above the cap records the stop as an audit event through API Platform, and an older API Platform rejects the new size_tier_above_ceiling reason. The plane does not start until that event is recorded, so it fails at startup and keeps restarting until API Platform is upgraded. An older Analytics also cannot read a runtime that ended with that code.

When upgrading, roll out the Runtime Plane before Analytics. Analytics sends a size only to a plane that reports size support. If Analytics is upgraded first, runtimes started in the meantime run at medium, and after the plane upgrade the next request for each of them, now at the organization's size, can fail once with an intent conflict. Upgrading Analytics also changes every runtime's request key once, because the organization's size policy is part of it.

The two deployment choices are microvm and managed_process. Historical Runtime Plane wire fields (require_true_vm, fallback, mediated, and hardened) are not Helm or organization tier controls. Tier-aware adapters emit a fixed microVM-only wire value after the shared resolver selects microvm, solely for rolling compatibility with the Rust plane.

networkPolicies:
  enabled: true

executionFabric:
  managedProcess:
    enabled: true

runtimePlane:
  enabled: true
  namespace: scrydon-runtimes
  workloadNamespace: scrydon-runtime-workloads
  persistence:
    size: 1Gi
  runnerImage: registry.example.com/scrydon/bundle-runner@sha256:<digest>
  enforcerImage: registry.example.com/scrydon/egress-enforcer@sha256:<digest>
  marimoRuntimeImage: registry.example.com/scrydon/marimo-runtime@sha256:<digest>
  blockedCidrs:
    - "10.0.0.0/8" # replace/extend with the actual pod + service CIDRs
    - "172.16.0.0/12"
    - "192.168.0.0/16"
  # upstreamDns is omitted on purpose: each pod uses the cluster DNS in its own
  # /etc/resolv.conf. Set it only to pin a different resolver ("<ip>:53").
  isolation:
    microvm:
      renderRuntimeClass: false # AKS owns kata-vm-isolation

The controller Deployment and both workload identities consume global.imagePullSecrets. Single-use Agent/notebook-job pods use sa-runtime-exec; interactive Marimo pods use sa-runtime-workload. Both set automountServiceAccountToken: false, so untrusted code receives no Kubernetes API token while kubelet can still use the configured registry credential. Do not patch the namespace default ServiceAccount. When the registry requires a pull secret, create the same named Secret in runtimePlane.namespace, runtimePlane.workloadNamespace, and every enabled application namespace before installation, or provide equivalent node-level registry access.

After deployment, check the controller's boot capability report and prove the selected tier separately for Agent exec, Marimo interactive, and notebook-job profiles. Also prove that opening a notebook creates no runtime, Connect runs no cells, and disconnected Run executes the selected cell once. A Ready controller alone does not prove Kata, image pulls, callbacks, DNS, dependency installation, cleanup, or egress enforcement.

Shared managed Valkey — events, model cache, and Agentic rate limits

The chart ships a durable event backbone (committed workflow-editor synchronization, organization event streams), a model-discovery cache, and durable Agentic webhook/form rate limits. They share one bundled persistent Valkey instance; the rate limiter does not deploy a second database.

networkPolicies.providerEgress — outbound HTTPS to data sources

Data sources and connection endpoints call the provider address an organization admin configures: connection-endpoint tools from api-platform, and every data source — poll, on-demand, stream — from api-ingestion. With networkPolicies.enabled, this rule lets those two services — and no other — reach public HTTPS addresses. It never allows private (RFC 1918), carrier-grade NAT, link-local or loopback addresses, Azure's platform address 168.63.129.16, or any other special-purpose range; in IPv6 it admits global unicast (2000::/3) only. Which host a connection may reach is still decided for each connection by the organization's egress allowlist.

networkPolicies.telemetry — your OpenTelemetry collector

If you run an OpenTelemetry collector, dapr.tracing.otel.endpointAddress and observability.otlpHttpEndpoint point Scrydon at it. A collector in a namespace the chart does not manage is reachable only through this route, because neither default-deny policy admits that namespace. Without the route, a workload that a NetworkPolicy isolates cannot export telemetry. With networkPolicies.enabled: false, that workload is marimo-document, whose own policy always renders. With networkPolicies.enabled: true, it is every Dapr workload. The same applies to your scraper's collection of daprd metrics on dapr.metricsPort.

networkPolicies:
  telemetry:
    collectors:
      - namespace: observability
        podSelector:
          app.kubernetes.io/component: otel-collector
        ports: [4317, 4318]   # OTLP gRPC (daprd), OTLP HTTP (applications)
    metricsScrapers:
      - namespace: observability
        podSelector:
          app.kubernetes.io/component: otel-collector

The route opens only the directions you configure. It selects only pods that another chart policy already isolates, so turning it on cannot restrict a workload that was unrestricted. The NATO UNCLASSIFIED profile leaves both lists empty.

global.egress.privateNetworks — private networks

A connection endpoint (a poll, on-demand or stream source whose URL comes from its connection) reaches public addresses on port 443 only, and a query source's database is reachable through no network at all. Two more kinds of address an organization admin configures are called from Scrydon's own servers: a Log Receiver URL, and an extension's OAuth provider endpoints (its sign-in, token and user-info URLs, which the organization's provider settings can put on its own host). Both reach public https:// addresses only. All of them stay there until you, the operator, open a private network. A private network names address ranges, the ports on them, what may use them and which organizations may:

Only the operator opens a network: no organization setting widens one. For a connection endpoint or a query source the organization still decides for itself as well: its egress allowlist must name the host (an IP address exactly), and a network in a private range also needs its Private networks switch (Settings → Governance → Egress). A Log Receiver or an OAuth provider setting needs only a network opened to its organization. Loopback, link-local, metadata and the other reserved addresses can never be opened, and every address a name resolves to is checked again each time a source connects, on each delivery and on each provider call. With no network, Log Receivers and provider endpoints stay public-only.

With networkPolicies.enabled, the chart renders one NetworkPolicy per workload and address family: each network's ranges on its own ports, for api-platform and api-ingestion when it serves http, and for api-table when it serves query. The broad HTTPS rule (providerEgress) and the managed-execution tier exclude the private ranges and runtimePlane.blockedCidrs together, so narrowing the floor never opens private space outside a network.

queryJdbc.remoteCidrs and queryJdbc.remotePorts were removed: the render fails while either is set. Move each database range to a network with uses: [query], its ports and trustedCaRefs. The query gateway requires at least one such network, and each trustedCaRefs entry must be distributed by a query driver profile.

Worked example: Azure Private Link on AKS

An AKS cluster with Azure CNI overlay: VNet 10.224.0.0/12, nodes 10.224.0.0/16, pods 10.244.0.0/16, services 10.0.0.0/16 (read yours with az aks show -g <rg> -n <cluster> --query networkProfile). Contoso's private endpoints live in subnet snet-pe, 10.225.8.0/24, in the same or a peered VNet — not a pod, service or node range. The identity provider every organization signs in against sits in 10.225.9.0/28.

runtimePlane:
  # The floor: the cluster's own ranges. 168.63.129.16 is always refused already.
  blockedCidrs: [10.224.0.0/16, 10.244.0.0/16, 10.0.0.0/16]
global:
  egress:
    trustAnchors:
      existingSecret: scrydon-egress-trust   # key: contoso-internal
    privateNetworks:
      - name: contoso-pg
        cidrs: [10.225.8.0/28]
        ports: [5432]
        uses: [query]
        organizations: [<contoso organization id>]
        trustedCaRefs: [azure-db]
      - name: contoso-api
        cidrs: [10.225.8.16/28]
        ports: [443, 8443]
        uses: [http]
        organizations: [<contoso organization id>]
        caRef: contoso-internal
      - name: corporate-idp
        cidrs: [10.225.9.0/28]
        ports: [443]
        uses: [http]
        allOrganizations: true

• Database (Azure Database for PostgreSQL, private endpoint). The organization admin enters the server's public name, contoso-pg.postgres.database.azure.com. Inside the cluster, CoreDNS forwards to Azure DNS, and the privatelink.postgres.database.azure.com zone linked to the VNet answers 10.225.8.4; the driver verifies the certificate against the name that was typed. Never enter the privatelink. name: the server's certificate does not carry it.
• HTTP API (Private Link Service). Contoso publishes its API behind a Private Link Service; its private endpoint gets 10.225.8.20. Add an A record for api.contoso.internal in a private DNS zone linked to the VNet, and put the CA that signs the API's certificate in the trust-anchor Secret under contoso-internal.
• Log Receiver. Contoso's SIEM collector has a private endpoint in the same range, 10.225.8.21, with a certificate from Contoso's internal CA. Contoso's admin saves https://siem.contoso.internal:8443/ingest as a Log Receiver (a private DNS zone linked to the VNet answers 10.225.8.21). A Log Receiver needs no allowlist entry and no switch.
• Identity provider. Any organization can set its extension's identity-provider domain to the IdP's host, which corporate-idp opens to every organization.
• The organization. Turn on Private networks and add contoso-pg.postgres.database.azure.com and api.contoso.internal to the egress allowlist.

AWS PrivateLink (interface endpoints in your subnets) and Google Private Service Connect (a consumer-subnet address; drop the trailing dot from the DNS name) work the same way: the endpoint's subnet is the network, and the cluster's own ranges stay in the floor. On-premises and air-gapped installs list the database's, API's, collector's or IdP's own subnet.

ingestBuffer — durable buffer for stream and push sources

Stream and push data sources accept input into a dedicated buffer before it is committed to its table, and a stream's lease is held there too; neither runs without it. Poll sources do not need it: the lease that keeps each one on one replica is held in the platform's database. ingestBuffer.enabled (default false) turns it on. By default the chart runs it as a single in-cluster Valkey that writes every accepted input to disk before answering (ingestBuffer.existingSecret and ingestBuffer.tls.existingSecret are then required). To use a managed Redis or Valkey service instead, point ingestBuffer.external at it:

The service must be non-clustered and use maxmemory-policy noeviction, and for replicated it needs at least one replica. Supported configurations: Azure Managed Redis with the Non-clustered policy and high availability; Amazon ElastiCache with cluster mode disabled and Multi-AZ; Google Memorystore for Redis (Standard tier) or Memorystore for Valkey with cluster mode disabled; or your own Valkey or Redis 6.2+ with replicas. Azure Cache for Redis (Basic, Standard, Premium), ElastiCache Serverless, Amazon MemoryDB and any cluster-mode service are not supported. The services that consume the buffer refuse to start, with a message naming the setting to change, when the service does not meet these requirements.

apiIngestion — the ingestion service

Every data source that fetches or receives data runs in its own service, api-ingestion: a person's on-demand fetch and file upload, and poll, stream and push sources. It is deployed on every installation (while dapr, auth and platform keep their defaults), and runs poll sources on every installation. Stream and push sources also need the ingest buffer: with ingestBuffer.enabled off, api-ingestion runs poll sources, on-demand fetches and uploads, and the push URL is not published. It keeps no database and stores no credentials: the platform issues it the credential of a source's connection for each run, connection attempt or delivery, and it holds that credential only for that attempt.

The URL a provider delivers to is https://<routing.host>/api/platform/data-sources/push/<binding id> in subpath mode and https://<auth.gateway.hostname>/api/platform/data-sources/push/<binding id> in subdomain mode. gateway.publicAuthRateLimit never applies to it; each source has its own delivery limit.

What each platform needs — none of these combinations has been validated by Scrydon yet. The chart's side of outbound HTTPS is networkPolicies.providerEgress:

opa — authorization decision point

Every workspace/workflow/ontology authorization decision is evaluated by OPA.

license — validation posture

The license itself is entered in the setup wizard and stored in the platform database; auth.secrets.LICENSE only pre-seeds it. Scrydon must run on a dedicated cluster because capacity includes all schedulable worker nodes. See Licensing and License capacity reporting.

When networkPolicies.enabled=true, set networkPolicies.kubernetesApiEgress.enabled=true and its cidr to the Kubernetes API endpoint as your CNI sees it. cidr has no default — the address differs per cluster — and the chart refuses to render while it is empty and the egress is on. Use the ready kubernetes EndpointSlice address rather than the Service ClusterIP, because policy is evaluated after service DNAT. Three pod-selected policies reuse that destination: api-platform is limited by RBAC to get/list on nodes, the PSS labeler to get/patch on exactly the Helm release namespace, and in strict isolation the Runtime Plane controller to its own pods.

kubectl get endpointslice -n default -l kubernetes.io/service-name=kubernetes \
  -o jsonpath='{range .items[*].endpoints[?(@.conditions.ready==true)].addresses[*]}{.}{"\n"}{end}'

packSources — chart-managed pack distribution

responseCompression — compressed pages

The platform, agentic, analytics, cortex and horizon apps compress their own pages, server-function data and JSON: brotli for a browser that accepts it, gzip otherwise. It works behind any edge, so you do not need compression on your gateway or load balancer for these apps. Event streams and responses under 1 KB are left as they are.

Sign-in and session answers (routing.paths.apiAuth, and the platform app's /api/auth proxy) are never compressed, because they carry session tokens and a compressed secret can be recovered (BREACH). The platform's proxy marks them Cache-Control: no-transform. If your own edge compresses, keep routing.paths.apiAuth out of it, and honour no-transform.

Pod security and disruption budgets

Pod scheduling

Chart-wide nodeSelector, tolerations, and affinity apply to every Deployment, StatefulSet, and migration Job — so pods can land on tainted or dedicated nodes. Per-component overrides are not exposed.

tolerations:
  - { key: workload, operator: Equal, value: scrydon, effect: NoSchedule }
nodeSelector:
  workload: scrydon
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - { key: node-role.kubernetes.io/scrydon, operator: Exists }

Trimming for low-resource installs

Defaults assume the minimum cluster (8 vCPU / 40 GB across two or more nodes). On a smaller eval cluster, disable the heaviest optional pieces. The three below take the memory the scheduler must reserve from about 24 GiB to about 14 GiB, which fits in roughly 24 GB of node memory:

infra:
  starrocks:
    enabled: false     # 5–8Gi RAM, 20Gi PVC — only Managed Tables + agentic schema-inference affected
apiTable:
  enabled: false
analytics:
  enabled: false       # drops the analytics UI (2 replicas × 1.5Gi) and the marimo-document renderer

Common configuration recipes

Customizing routing paths

Mount apps under different prefixes (e.g. everything under /scrydon/...) via routing.paths.* — see the routing table above and Routing Modes.

Rendering without a live cluster (GitOps / offline)

Use this whenever the chart is rendered without a connection to the target cluster — anything that runs helm template under the hood:

• ArgoCD (its default renderer)
• Kustomize's helmCharts: inflator
• helm template … | kubectl apply -f -, the usual offline air-gap flow
• helm install --dry-run, helm diff

Flux's HelmRelease drives a real helm upgrade --install and does not need this. Neither does a direct helm install/helm upgrade, nor zarf package deploy.

Why it matters. Every chart-managed secret resolves live cluster Secret → value you provided → generate a random one. Helm's lookup returns empty with no API connection, so the third branch fires and produces a different value on every render. Applying that rotates 38 secrets on each sync, and some rotations cannot be undone:

What to do. Set global.requireExplicitSecrets: true. Each generate branch becomes a render-time failure naming the exact values path, so a missing entry is loud instead of destructive. Start from values.gitops.example.yaml, which lists the full required set and the kubectl commands to read the current values out of an existing install before you adopt it:

helm template scrydon ./helm/scrydon \
  -f helm/scrydon/values.yaml \
  -f helm/scrydon/values.gitops.example.yaml \
  -n scrydon-platform

Generate each value once, store it in your secret manager, and inject it at render time (ArgoCD valuesFrom, a sops-decrypted overlay, --set-file). Keep the values stable — changing one here changes it in the cluster. The example ships every secret as REPLACE-ME-WITH-A-REAL-VALUE-FROM-YOUR-SECRET-STORE, and the render fails, naming the values path, while any value is still that placeholder.

Existing Dapr installations

If the cluster already runs Dapr, set dapr.installControlPlane: false so the chart doesn't try to manage it, and point dapr.controlPlaneNamespace at where Dapr lives:

dapr:
  installControlPlane: false
  controlPlaneNamespace: dapr-system

Set both. installControlPlane: false alone leaves the chart assuming Dapr runs in the release namespace, and the install waits on a marimo-document pod whose sidecar times out reaching dapr-sentry. The installer (setup.sh) detects an existing control plane and passes both flags for you. The air-gapped (Zarf) package always installs its own Dapr, so next to an existing one its preflight fails and points you at --backend mirror, which reuses it.

Your Dapr must satisfy three prerequisites or sign-in works but account creation / cross-service calls fail with PermissionDenied:

kubectl -n <dapr-ns> get deploy dapr-sentry \
  -o jsonpath='{.spec.template.spec.containers[0].image}'   # expect sentry:1.18.1

Advanced edge: behind a TLS-terminating load balancer

App Gateway / ALB / GCP LB / F5 setups need Traefik-controller tuning (trustedIPs, externalTrafficPolicy: Local, the gateway.tls.enabled public-scheme rule, a private edge, 502 troubleshooting). Full playbook: TLS Offloading.

StarRocks credentials

The bundled StarRocks ships root with no password. If you set a non-empty apiTable.secrets.STARROCKS_PASSWORD, the chart applies it for you — a password-reconciler sidecar inside the starrocks-fe pod reconciles the root password on every boot and then re-verifies it once a minute: it applies the password on a password-less root, no-ops when it already matches, rotates root automatically when you change the value (a checksum annotation restarts the pod; the sidecar re-keys from the previous password it recorded on the StarRocks PVC), and logs loudly — without clobbering anything — if root was changed out-of-band. No manual step is required; leave the value empty for a password-less root.

Two behaviors worth knowing:

• First passworded boot may restart starrocks-fe once. The image's own boot check races the very first password apply and shuts the container down if it loses; the password is already persisted by then, so the next boot is clean. One restart on a fresh install is benign — CrashLoop or repeated restarts are not.
• Rotation order is handled for you. Changing the value and running helm upgrade restarts starrocks-fe (sidecar rotates root) and api-table (its secret checksum changed) — no manual SET PASSWORD.

NEW_PW="<your-starrocks-password>"   # same value as apiTable.secrets.STARROCKS_PASSWORD
# StarRocks runs in the release namespace by default (namespaces.infra → scrydon-platform).
kubectl -n scrydon-platform exec -it deploy/starrocks-fe -- \
  mysql -h127.0.0.1 -P9030 -uroot -e "SET PASSWORD FOR 'root'@'%' = PASSWORD('${NEW_PW}');"
kubectl -n scrydon-platform rollout restart deployment/api-table

If the password never reaches StarRocks (older chart with the hook Job failed or the manual step skipped), api-table stays 1/2 Running — Ready container plus a sidecar, but the app fails its readiness probe (/api/table/health/ready → 503, "starrocks": false). It does not CrashLoop, so the pod looks healthy at a glance. Because a not-Ready pod is removed from its api-table-dapr service endpoints, any service that calls api-table over Dapr (api-ontology, for one) gets ERR_DIRECT_INVOKE: failed to resolve address for api-table-dapr…. See Troubleshooting. (replication_num is auto-clamped to the live BE count, so a single-pod StarRocks no longer fails table provisioning on its own.)

The root password is stored in FE metadata on the StarRocks PVC, so it survives pod restarts, and the reconciler sidecar re-verifies it continuously.

To bring your own StarRocks instead:

infra:
  starrocks:
    enabled: false
apiTable:
  starrocks:
    host: starrocks-fe.starrocks.svc.cluster.local
    user: scrydon
  secrets:
    STARROCKS_PASSWORD: REPLACE-WITH-STARROCKS-PASSWORD

Verify the deployment

kubectl get pods -n scrydon-platform      # all Running, 2/2 with the Dapr sidecar
kubectl get gatewayclass traefik          # ACCEPTED=True
kubectl get gateway -n scrydon-platform   # PROGRAMMED=True, and an ADDRESS
kubectl get httproute -A                  # one per enabled app, Accepted by the Gateway
kubectl get certificates -A               # cert-manager Certificates READY=True

A Gateway that is Programmed but whose listeners are not Accepted is the case to look at closely — kubectl describe gateway gateway-frontdoor -n scrydon-platform prints one condition block per listener.

License claims (tier, entitlements, days-to-expiry) appear under Settings → Organization → License after /setup. Sign in at https://app.example.com/platform and switch apps via the product switcher without re-authenticating.

Troubleshooting

Day-2 operations

• Renew the license — paste the renewed license file under Settings → Organization → License → Update license; no restart. Licensing.
• Backup & restore — bundled Postgres CronJob (infra.db.backup) or your managed provider. Backup & Restore.
• Upgrades — Upgrades.
• Observability — Observability.