On-Premise

This is the quickest route to a working Scrydon install on a self-managed Kubernetes cluster that can pull images over the internet. Follow the guided installer or the five manual steps below. For every override the chart exposes — routing, BYO database, TLS offloading, pod scheduling, low-resource trims — see the Helm reference.

Quick start

curl -fsSL https://get.scrydon.com | bash

The installer asks which version you want, where you are deploying, and for the registry credential and license file your account team issued. It checks your cluster before it changes anything, then installs and verifies.

Prefer to inspect it first, or need a pinned copy?

curl -fsSL https://get.scrydon.com -o setup.sh
curl -fsSL https://get.scrydon.com/setup.sh.sha256 | shasum -a 256 -c -
bash setup.sh

If your cluster is not reachable from your machine, run the installer anyway — it saves your answers and tells you to copy three files (the values file, scrydon-install.conf, and your pull-secret manifest) to a bastion host that can reach the cluster, then run:

curl -fsSL https://get.scrydon.com | bash -s -- \
  --conf scrydon-install.conf --pull-secret <path-to-your-pull-secret>

The pull-secret manifest is the file issued by your account team. The registry credential is not stored in the conf (credentials never travel in the conf), so it must be supplied again on the bastion.

Unattended installs

To run without any prompts — in CI, or from a configuration-management tool — pass --non-interactive together with every value the interview would have asked for:

curl -fsSL https://get.scrydon.com | bash -s -- \
  --non-interactive \
  --context <your-kubectl-context> \
  --version <version> \
  --namespace scrydon-platform \
  --host app.example.com \
  --storage-class <your-storage-class> \
  --gateway-class traefik \
  --tls-issuer letsencrypt-prod \
  --license <path-to-your-license.json> \
  --pull-secret <path-to-your-pull-secret>

--non-interactive also means "yes": the installer proceeds without the final confirmation prompt.

--gateway-class names the GatewayClass Scrydon's front door is published under. Without it the installer takes the first GatewayClass on the cluster, and stops if there is none: a front door published under a class no controller claims leaves the install reporting success while the platform stays unreachable. On a cluster with no Gateway API controller yet, pass --bundle-traefik instead: the chart installs Traefik, which brings the CRDs and the traefik GatewayClass.

With --license the installer checks the license file before it installs, as the interview does, and pre-seeds it so the setup wizard opens with it already verified.

Version strings are the chart's published tags and carry a leading v (v1.3.23, not 1.3.23). Run --list-versions to see the installable set.

Which cluster?

Before anything else, the installer asks which Kubernetes context to install into, listing what kubectl knows about and defaulting to your current one. Every command it runs afterwards is pinned to that choice.

This exists because the target used to be ambient: whatever context happened to be current, stated nowhere. Pass --context <name> to answer it up front — and do so in any script, where there is no one to ask.

The three answers that decide whether Scrydon is reachable

The installer detects a default for each of these from your cluster and shows you what it found. They are called out here because each one fails in a way that is easy to miss.

Preflight checks all three before anything is applied: the GatewayClass and the ClusterIssuer must exist on the cluster, and the StorageClass must exist. A missing cert-manager is a failure only when you named an issuer; an empty issuer is the supported bring-your-own-TLS path.

After the install the installer makes an HTTP request to the hostname you gave it. If nothing answers it says so plainly rather than printing a setup URL that does not work.

Manual installation

Before you start

• A Kubernetes 1.28+ cluster with a working storage provisioner (Ceph, vSphere, local-path, …) and kubectl access.
• A Gateway API implementation — the gateway.networking.k8s.io CRDs plus a GatewayClass. Either run one already and set gateway.className to it, or set traefik.enabled: true and let the chart install a Traefik release that brings both. See Kubernetes prerequisites.
• cert-manager with its Gateway API support on, when you want the chart to issue the HTTPS certificate — see TLS prerequisites. Not needed if you terminate TLS yourself.
• Your license file from Scrydon — JSON shaped { "jwt": "…", "publicKey": "…" }. See Licensing.
• Registry credentials for scrydonops.azurecr.io — one scoped token covers both chart and image pulls. Your account team issues the ACR token name (the username) and token value (the password).
• A single DNS name pointing at your cluster's edge load balancer (e.g. app.example.com).

Full resource sizing and the complete checklist live in Prerequisites.

Step 1: Log in to the registry

helm registry login scrydonops.azurecr.io --username <acr-token-name>
# (paste the token value at the password prompt)

Step 2: Create the namespace and pull secret

By default the chart deploys every service into one namespace, scrydon-platform. Create it and add the image-pull secret there:

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>

Splitting services across namespaces is opt-in via namespaces.* (see the Helm reference). If you do, create the same pull secret in each namespace you target.

Step 3: Write values.customer.yaml

This is the entire minimal install. The chart defaults to subpath routing, the traefik GatewayClass, a letsencrypt-prod issuer, and bundled Postgres / StarRocks / SeaweedFS / OPA. The one on-prem-specific value is global.storageClass: the chart ships no cloud default, so point it at your provisioner. Keep traefik.enabled: true unless the cluster already runs a Gateway API controller, in which case remove it and set gateway.className to that controller's class.

global:
  imageRegistry: scrydonops.azurecr.io  # pull images from the ACR you logged into
  imagePullSecrets:
    - name: scrydon-registry            # from Step 2
  storageClass: <your-storage-class>    # e.g. ceph-rbd, vsphere-csi, local-path

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

gateway:
  tls:
    enabled: true                       # browser reaches Scrydon over HTTPS (the default)

traefik:
  enabled: true                         # installs Traefik in the `traefik` namespace, with the Gateway API CRDs

These three secret values are optional. On a live helm install the chart generates every secret it needs and preserves them across upgrades. Set them explicitly only when you manage secrets externally, or when rendering without a live cluster (ArgoCD, helm template) — see Rendering without a live cluster.

# Optional — only needed for lookup-free rendering or external secret management.
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

Step 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

The chart deploys the bundled Postgres and every Scrydon service into scrydon-platform, and runs the migration Jobs as Helm hooks.

Step 5: Run the setup wizard

Open https://app.example.com/platform/setup and complete the six steps: paste your license file, create the admin account, name your organization, point it at object storage (or skip), configure email (or skip), and finish. Then sign in at https://app.example.com/.

The wizard, the license format, and pod/gateway/certificate verification are documented in full on the Helm reference.

On-prem specifics

These are the places an on-prem cluster differs from a managed cloud one:

• Storage class — set global.storageClass (Step 3) to your provisioner. There is no cloud default.
• The edge — there's no cloud load balancer. The chart's Traefik publishes a LoadBalancer Service, scrydon-traefik in the traefik namespace; give it an address with MetalLB, or expose it through NodePort or your own L4/L7 load balancer. Remember that gateway.listenerPorts.* is what the controller listens on — Traefik's entryPoints bind :8000/:8443 while its Service publishes 80/443. See Routing modes.
• TLS — choose Let's Encrypt, internal ACME, or corporate certificates with TLS Certificates. If a hardware or edge load balancer terminates TLS in front of the cluster, see TLS Offloading.
• Database — the bundled Postgres works out of the box; point at an external instance via BYO Database.
• Stream and push data sources — off until you set ingestBuffer.enabled (poll sources run without it). The buffer writes every accepted input to disk, so back it with a storage class that honours fsync. Providers must be reachable at a public HTTPS address; providers on a private network are not supported yet. Details: Helm → apiIngestion.
• No outbound internet? If the cluster is fully isolated, use Air-Gapped Deployment instead — it ships every image in one Zarf package.

All options

Everything beyond this minimal path — per-app subdomain routing, custom path prefixes, an existing Dapr control plane, StarRocks credential lock-down, low-resource trims, pod scheduling, and day-2 operations — lives in the Helm reference.