Cloud Temple

Cloud Temple is a French sovereign cloud provider whose infrastructure is SecNumCloud-qualified, HDS-certified, ISO 27001, and German C5 attested. Scrydon runs on their Managed Kubernetes offering as a standard Helm install — the same chart used on AKS or on-prem, with Cloud Temple specifics for storage, the edge, and egress called out below.

There is no Cloud Temple Marketplace listing for Scrydon today, so this page is the Helm path. If you need stricter network isolation than a registry pull allows, see Air-Gapped Deployment instead.

Quick start

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

The guided installer asks which version you want, where you are deploying, and for the registry credential and licence bundle your account team issued. It checks your cluster before it changes anything — including that the routing class and cert-manager issuer you name actually exist — installs, and then confirms the platform answers on your hostname.

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

The manual steps below remain supported, and are what the installer runs for you.

Before you start

• A Cloud Temple Managed Kubernetes cluster running Kubernetes 1.28+ with kubectl access.
• A license bundle from Scrydon — { "jwt": "…", "publicKey": "…" } JSON.
• Registry credentials for scrydonops.azurecr.io (the ACR token name + value from your account team).
• A single DNS name pointing at your edge load balancer (e.g. app.example.com).
• A Gateway API implementation — the gateway.networking.k8s.io CRDs plus a GatewayClass. Set traefik.enabled: true to have the chart install a Traefik release that brings both, or point gateway.className at a class the cluster already runs.
• cert-manager installed in the cluster for automatic TLS certificates, with its Gateway API support on (config.enableGatewayAPI: true) — see TLS prerequisites.

Full sizing and checklist: Prerequisites. For the list of external hosts the install reaches, see Egress allow-list below — share this with your network team before starting if your cluster sits behind a restrictive egress policy.

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:

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

The Cloud Temple specifics are global.storageClass (point it at the CSI provisioner exposed by your cluster — query with kubectl get storageclass) and the public hostname. The chart's defaults — the traefik GatewayClass, letsencrypt-prod issuer, bundled Postgres / StarRocks / SeaweedFS — work unchanged.

# Replace REPLACE-WITH-* with values you generate. Keep this file out of source control.

global:
  imageRegistry: scrydonops.azurecr.io  # pull images from the ACR you logged into
  imagePullSecrets:
    - name: scrydon-registry            # from Step 2
  storageClass: <your-storage-class>    # query: kubectl get storageclass

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

gateway:
  tls:
    enabled: true                       # browser reaches Scrydon over HTTPS

# Secrets — generate fresh per deployment.
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

Step 5: Configure DNS

Find the LoadBalancer IP Cloud Temple assigned to your Gateway API implementation:

kubectl get svc -n scrydon-platform -l app.kubernetes.io/name=traefik \
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}'

Create one A (or CNAME) record pointing app.example.com at that IP. With the default subpath routing mode one record covers every Scrydon app — /cortex, /agentic, /analytics, /platform, /api/auth, /api/ontology, /api/table, /agentic/realtime, /marimo. For per-app hostnames see Routing Modes.

Step 6: Run the setup wizard

Open https://app.example.com/platform/setup and complete the five steps — paste the { jwt, publicKey } bundle, create the admin account, name your organization, configure email (or skip), finish. Then sign in at https://app.example.com/. Details: Helm → Run the setup wizard.

Cloud Temple specifics

• Storage class — Cloud Temple Managed Kubernetes ships its own CSI provisioner; pick the class you want via global.storageClass in Step 3 (kubectl get storageclass to list them).
• Database — the bundled Postgres works out of the box; or point at Cloud Temple Managed PostgreSQL via BYO Database. The managed offering keeps your operational data inside Cloud Temple's qualified perimeter.
• Object storage — the chart's bundled SeaweedFS works unchanged. To use Cloud Temple Object Storage (S3-compatible) instead, configure it under https://app.<domain>/settings/platform/storage after install — the platform supports any S3 endpoint via the same Settings screen used on the hyperscalers.
• Managed Tables (StarRocks) — the bundled single-pod StarRocks runs fine. For multi-AZ production, either disable Tables (apiTable.enabled: false) or run the starrocks-kubernetes-operator in a separate namespace and point apiTable.starrocks.host at it. Cloud Temple has no managed StarRocks offering today.
• Behind an external load balancer — if a Cloud Temple-managed L7 proxy terminates TLS in front of the cluster, keep gateway.tls.enabled: true (so the public URL scheme, CORS, and secure cookies stay HTTPS) and follow TLS Offloading to trust the proxy's source range.

Egress allow-list

If your cluster runs behind a restrictive egress policy, allow the hosts below before helm install. The list is small because the chart's runtime is self-contained inside the cluster — outbound traffic is the registry pull, certificate issuance, and any LLM / STT / embedding vendors you enable in the platform.

The chart image registry is hosted on Azure ACR. If reaching an Azure-hosted endpoint from inside Cloud Temple is not acceptable for your sovereignty posture, switch to the Air-Gapped deployment path — Zarf packages every image into a single archive that you transfer in over your approved channel and deploys to an in-cluster registry with no outbound pulls.

Per-integration egress. Each platform integration you enable (OpenAI, Anthropic, Mistral, Azure OpenAI, ElevenLabs, Resend, …) reaches its vendor endpoint directly from the cluster. The hosts depend entirely on which integrations you configure in https://app.<domain>/settings/platform/extensions; allowlist them per the vendor's documentation. The Helm install itself reaches none of these — they are runtime, not install-time, dependencies.

All options

Everything beyond this minimal path — routing modes, BYO StarRocks, pod scheduling, low-resource trims, an existing Dapr control plane, and day-2 operations — lives in the Helm reference.

Upgrades

Standard helm upgrade against the same values.customer.yaml. See Upgrades for the version-skew policy and migration notes.

Troubleshooting

Pods stuck in ImagePullBackOff

• Verify the pull secret is in the right namespace: kubectl get secret scrydon-registry -n scrydon-platform
• Re-run helm registry login and re-create the secret if the ACR token has rotated
• Check that egress to scrydonops.azurecr.io is allowed (see Egress allow-list)

TLS certificates not provisioning

• Verify cert-manager is installed: kubectl get pods -n cert-manager
• Check certificate status: kubectl get certificates -n scrydon-platform
• Confirm egress to acme-v02.api.letsencrypt.org is allowed

Setup wizard unreachable

• Verify DNS resolves: nslookup app.<domain>
• Check pod status: kubectl get pods -n scrydon-platform
• Verify Traefik is healthy and has a LoadBalancer IP: kubectl get svc -n scrydon-platform -l app.kubernetes.io/name=traefik
• Verify the front door is programmed: kubectl get gatewayclass, kubectl get gateway -n scrydon-platform, kubectl get httproute -A. A listener stuck on Accepted=False reason=PortUnavailable means gateway.listenerPorts.* does not match the controller's entryPoint ports — Traefik binds :8000/:8443, not 80/443.