Prerequisites

Before deploying Scrydon, ensure your environment meets the requirements below.

Kubernetes

• Version: Kubernetes 1.28 or later
• Helm: Helm 3.14 or later
• A namespace-scoped service account with permissions to create Deployments, Services, Ingresses, Secrets, and ConfigMaps

PostgreSQL

The Helm chart bundles PostgreSQL 18 with pgvector by default (infra.db.enabled: true). No external database is required for standard deployments — the bundled instance pre-creates every database the enabled services need.

Bring your own (managed) Postgres

If you prefer a managed instance (RDS, Cloud SQL, Azure Database for PostgreSQL, Supabase, Neon, CloudNativePG, …), set infra.db.enabled: false and pre-provision the following before running helm install — the chart's migration Jobs will crash on first install otherwise.

Databases to pre-create. One per enabled component — every component is enabled by default in the chart, so plan for all five unless you've disabled something:

Apply this against your managed Postgres before helm install:

CREATE DATABASE auth;
CREATE DATABASE agentic;
CREATE DATABASE analytics;   -- if analytics.enabled (default)
CREATE DATABASE cortex;      -- if cortex.enabled (default)
CREATE DATABASE ontology;    -- if apiOntology.enabled (default)

\c auth
CREATE EXTENSION IF NOT EXISTS vector;

\c agentic
CREATE EXTENSION IF NOT EXISTS vector;

\c cortex
CREATE EXTENSION IF NOT EXISTS vector;

See Managed Postgres (BYO Database) for per-provider notes, the corresponding infra.db.external.* Helm values, and connection-pooling guidance.

DNS

The default and recommended routing mode is subpath — every Scrydon app lives behind a single hostname under a path prefix. You need one DNS A (or CNAME) record pointing at the cluster ingress IP:

Replace app.yourdomain.com with your actual hostname.

If you instead use subdomain routing (per-app hostnames), you will need one A record per app — see Routing Modes for the full mapping and the trade-offs.

TLS Certificates

All services must be served over HTTPS. We recommend cert-manager with Let's Encrypt for automatic certificate provisioning:

# Install cert-manager (if not already present)
helm repo add jetstack https://charts.jetstack.io
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set installCRDs=true

Alternatively, you can supply your own certificates as Kubernetes TLS Secrets and reference them in Helm values.

License Bundle

You must have a valid Scrydon license bundle before completing setup. Contact sales@scrydon.com to request one.

The bundle is a JSON file containing both the signed JWT and the matching RSA public key:

{
  "jwt":       "eyJhbGciOiJSUzI1NiIs…",
  "publicKey": "-----BEGIN PUBLIC KEY-----\nMIIBIjAN…\n-----END PUBLIC KEY-----"
}

After installing the chart, paste the bundle into the /setup wizard. Alternatively, pre-seed it via the auth.secrets.LICENSE and auth.secrets.LICENSE_PUBLIC_KEY Helm values — see Helm.

To inspect a bundle before installing — confirm the tier, entitlements, and expiry match what you ordered — use the in-browser License Checker.

License verification runs in the api-platform pod at runtime (the @scrydon/better-auth-license Better-Auth plugin) — there is no init container and no scrydon-license Kubernetes Secret to manage. The bundle lives in the platform_config table and is rotated through the platform UI.

See Licensing for the full lifecycle.

Resource Requirements

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 will reflect 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 Limits

The Helm chart applies the following memory limits per pod (single-replica defaults). Use these to size node pools and HPA targets — sum across enabled services, then add 30% headroom for kube system pods, Dapr sidecars (~250 MiB each), and burst capacity.

Limits were last revised on 2026-05-18 following the v1.3.5-rc.54 binary-minification rollout (PR #1142), which roughly doubled steady-state RSS for the SSR apps. If you upgrade across that boundary on a pre-existing cluster, verify your node pool has headroom for the new limits before running helm upgrade.

Key Environment Variables

The Helm chart injects these environment variables automatically from your values file. You do not need to set them manually, but you should understand what they configure:

Next step: Pick where you're deploying — On-Premise, Azure, or Air-Gapped — or go straight to the Helm reference.