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, ingress, 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.

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 ingress (e.g. app.example.com).
• cert-manager installed in the cluster for automatic TLS certificates.

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 ingress hostname. The chart's defaults — Traefik ingress, 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

ingress:
  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 ingress LoadBalancer IP assigned by Cloud Temple:

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.
• Ingress behind an external load balancer — if a Cloud Temple-managed L7 proxy terminates TLS in front of the cluster, keep ingress.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/integrations; 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