Prérequis

Avant de déployer Scrydon, assurez-vous que votre environnement satisfait les exigences ci-dessous.

Kubernetes

• Version : Kubernetes 1.28 ou ultérieur
• Helm : Helm 3.14 ou ultérieur
• Un compte de service limité à un espace de noms avec les permissions de créer des Deployments, Services, Ingresses, Secrets et ConfigMaps

PostgreSQL

Le chart Helm intègre PostgreSQL 18 avec pgvector par défaut (infra.db.enabled: true). Aucune base de données externe n'est requise pour les déploiements standard — l'instance intégrée pré-crée toutes les bases de données dont les services activés ont besoin.

Apporter votre propre Postgres (géré)

Si vous préférez une instance gérée (RDS, Cloud SQL, Azure Database for PostgreSQL, Supabase, Neon, CloudNativePG, …), définissez infra.db.enabled: false et provisionnez les éléments suivants avant d'exécuter helm install — les Jobs de migration du chart planteront lors de la première installation dans le cas contraire.

Bases de données à pré-créer. Une par composant activé — chaque composant est activé par défaut dans le chart, planifiez donc les cinq sauf si vous en avez désactivé certains :

Appliquez ceci sur votre Postgres géré avant 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;

Consultez Postgres géré (BYO Database) pour les notes spécifiques à chaque fournisseur, les valeurs Helm correspondantes infra.db.external.* et les conseils de connection pooling.

DNS

Le mode de routage par défaut et recommandé est sous-chemin — chaque application Scrydon se trouve derrière un seul nom d'hôte sous un préfixe de chemin. Vous avez besoin d'un seul enregistrement DNS A (ou CNAME) pointant vers l'IP d'entrée du cluster :

Remplacez app.yourdomain.com par votre nom d'hôte réel.

Si vous utilisez plutôt le routage sous-domaine (noms d'hôte par application), vous aurez besoin d'un enregistrement A par application — consultez Modes de routage pour la correspondance complète et les compromis.

Certificats TLS

Tous les services doivent être servis via HTTPS. Nous recommandons cert-manager avec Let's Encrypt pour le provisionnement automatique des certificats :

# 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

Vous pouvez également fournir vos propres certificats sous forme de Secrets TLS Kubernetes et les référencer dans les valeurs Helm.

Bundle de licence

Vous devez disposer d'un bundle de licence Scrydon valide avant de terminer l'installation. Contactez sales@scrydon.com pour en faire la demande.

Le bundle est un fichier JSON contenant à la fois le JWT signé et la clé publique RSA correspondante :

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

Après avoir installé le chart, collez le bundle dans l'assistant /setup. Vous pouvez également le pré-configurer via les valeurs Helm auth.secrets.LICENSE et auth.secrets.LICENSE_PUBLIC_KEY — consultez Helm.

Pour inspecter un bundle avant l'installation — confirmer le niveau, les droits et la date d'expiration correspondent à ce que vous avez commandé — utilisez le Vérificateur de licence dans le navigateur.

La vérification de la licence s'exécute dans le pod api-platform au moment de l'exécution (le plugin Better-Auth @scrydon/better-auth-license) — il n'y a pas de conteneur init et pas de Secret Kubernetes scrydon-license à gérer. Le bundle réside dans la table platform_config et est renouvelé via l'interface utilisateur de la plateforme.

Consultez Licences pour le cycle de vie complet.

Ressources requises

Minimum (Évaluation / Petites équipes)

Ces chiffres supposent la pile complète par défaut (Interface Plateforme, Agentic, Cortex, Analytics, le Postgres intégré, SeaweedFS et un StarRocks à un seul pod pour les tables gérées). Pour fonctionner sur des nœuds plus petits (4 vCPU / 16 Go), réduisez les composants optionnels — consultez Helm → Réduction pour les installations à faibles ressources.

Recommandé (Production)

Remarque : Les ressources GPU sont sous licence contractuelle (votre JWT de licence reflète vos droits), mais Scrydon n'applique pas les limites GPU au moment de l'exécution. Les nœuds GPU ne sont nécessaires que si vous prévoyez d'exécuter des modèles d'inférence locaux dans votre cluster.

Limites de mémoire par service

Le chart Helm applique les limites de mémoire suivantes par pod (valeurs par défaut à un seul réplica). Utilisez-les pour dimensionner les pools de nœuds et les cibles HPA — additionnez les services activés, puis ajoutez 30 % de marge pour les pods système de Kubernetes, les sidecars Dapr (~250 Mio chacun) et la capacité en rafale.

Les limites ont été révisées pour la dernière fois le 18 mai 2026 suite au déploiement de minification binaire v1.3.5-rc.54 (PR #1142), qui a environ doublé le RSS en régime permanent pour les applications SSR. Si vous effectuez une mise à jour au-delà de cette limite sur un cluster existant, vérifiez que votre pool de nœuds dispose de la marge nécessaire pour les nouvelles limites avant d'exécuter helm upgrade.

Variables d'environnement clés

Le chart Helm injecte ces variables d'environnement automatiquement depuis votre fichier de valeurs. Vous n'avez pas besoin de les définir manuellement, mais vous devez comprendre ce qu'elles configurent :

Étape suivante : Choisissez où vous déployez — Sur site, Azure ou Air-gappé — ou accédez directement à la référence Helm.