Scrydon
DeploymentPrerequisites

Kubernetes

Kubernetes and Helm requirements for Scrydon deployments

Before deploying Scrydon, ensure your cluster meets the Kubernetes requirements below.

  • Version: Kubernetes 1.28 or later. The chart enforces this; helm install refuses clusters below 1.28.

  • Helm: Helm 3.14 or later.

  • A namespace-scoped service account with permissions to create Deployments, Services, Gateways, HTTPRoutes, Secrets, and ConfigMaps.

  • At least two nodes for the full default stack. The control plane, databases, and apps starting together on a single small node can OOM-kill pods during the cold-start storm. See Resources.

  • A default StorageClass, or global.storageClass set explicitly. Every PVC the chart creates is ReadWriteOnce; without a usable class they stay Pending and the install appears to hang.

  • linux/amd64 nodes. Platform images are published for amd64 only — an arm64 node pool (AWS Graviton, Azure Ampere, Ampere/Raspberry-class on-prem) fails with exec format error.

  • The Gateway API CRDs and a GatewayClass. The chart's edge is Gateway + HTTPRoute (gateway.networking.k8s.io), not Ingress — and unlike Ingress, neither the CRDs nor an implementation is present in a stock cluster. Either install one yourself and set gateway.className to its GatewayClass, or set traefik.enabled: true and the chart installs a Traefik release that brings the CRDs and publishes the traefik GatewayClass. The HTTPS redirect, the Dapr identity-header strip and path precedence are core Gateway API and work on any conforming implementation; the one Traefik-only control is gateway.publicAuthRateLimit. See Other Gateway API implementations.

    Kubernetes Ingress is frozen, not deprecated: it is GA, keeps its stability guarantees and is not being removed, but it gets no further development and Kubernetes recommends the Gateway API instead. Note that ingress-nginx was retired — archived on 2026-03-24 with no further releases, bugfixes, or security fixes — so it is not a supported route into a Scrydon cluster.

    Whatever you run, check gateway.listenerPorts.*: it is the port your controller listens on, not the public port. Traefik binds :8000/:8443 internally (the chart default) while its Service publishes 80/443; a managed implementation that listens on the public port wants 80/443 there instead.

  • Outbound HTTPS to license.scrydon.com, or offline licensing. The default license.mode: online revalidates every 24 h and falls back to a 30-day grace period before stopping. Egress-restricted or disconnected clusters use -f helm/scrydon/values.airgapped.yaml (license.mode: offline).

Not currently supported without additional work: OpenShift — the bundled data services and the migration Jobs run as root and the Postgres pod needs a runAsUser: 0 init container, so they require SCC exceptions beyond restricted-v2. Point the chart at external data services, or contact us.

The runtime plane (isolated compute)

The runtime plane runs customer code — Agent steps and notebook kernels — in isolated pods. It is off by default (runtimePlane.enabled: false) because enabling it safely requires cluster capacity and policy decisions the chart cannot make for you.

What that means per feature:

FeatureWith the runtime plane disabled
Agent steps in workflowsRun in-process and audited, provided nobody explicitly required isolation and the host has no /dev/kvm. An organization that turns on Require isolated execution, or a deployment that pins it, fails closed instead.
Marimo notebook computeUnavailable. Notebooks still open and edit, but Connect fails with Compute could not start. There is deliberately no fallback onto the Analytics host.

Notebook compute has no in-process fallback. If your users need notebooks, the runtime plane is a hard requirement, not optional hardening — plan the node pool below before you promise the feature.

What enabling it requires

  • Dapr enabled for both the platform and runtime plane. It is the authenticated control path.
  • A CNI that enforces Kubernetes NetworkPolicy, with networkPolicies.enabled: true.
  • Separate controller and hostile-workload namespaces, plus a reviewed admission exception for the root, capability-limited egress-enforcer sidecar (NET_ADMIN and NET_BIND_SERVICE only), while the untrusted application remains non-root with all capabilities dropped.
  • Cluster-pullable runner and enforcer images, pinned by digest. The runtime plane refuses empty, untagged, or latest references. Released charts carry these digests; if runtimePlane.marimoRuntimeImage / enforcerImage / runnerImage are empty in your chart, set them explicitly before enabling.
  • A schedulable Kata RuntimeClass backed by KVM/nested virtualization, for the microVM tier. A RuntimeClass object alone is not capability proof: verify that a Ready eligible node can run the workload, and check the runtime plane's boot capability report. On AKS this means a separate Pod Sandboxing node pool--workload-runtime KataVmIsolation with --os-sku AzureLinux (the only supported SKU) and a Gen2, nested-virtualization VM size. It cannot be turned on for an existing pool. Keep runtimePlane.isolation.microvm.renderRuntimeClass: false, because AKS registers its own kata-vm-isolation RuntimeClass and rendering a second one conflicts. The Runtime Plane discovers that class and a compatible Ready, uncordoned node at boot.
  • Capacity for the workloads themselves. Each interactive notebook runtime reserves ~5.6 GiB and each notebook job ~4.25 GiB; see Resources.

Set executionFabric.managedProcess.enabled: false when the deployment must be physically microVM-only. When the managed backend is deployed, it is used only after MicroVM is unavailable and an organization admin turns off Require isolated execution. There is no hardened-container product tier.

On this page

On this page