Clever Cloud : vue d’ensemble, coût et prérequis

English · Type : explication · Public : administrateur · Contexte : Studio hébergé · Statut : prête · S'applique depuis : 4.2.3

Le Studio Server (Studio d'équipe hébergé) · contrat : expérimental · vérifié par la CI (matrice de support de la 4.4.0, 2026-10-23) : Postgres, S3 et Keycloak en CI ; Chromium et Firefox (job studio-hosted) ; WebKit sous macOS, à la main seulement · vérifications automatiques : jobs studio-hosted, studio-install-smoke ; plan de CI studioHosted ; 3 fichiers de tests · passes humaines : studio-hosted pas faite (#149), studio-collab pas faite (#150), studio-preview pas faite (#166), studio-assets-hosted pas faite (#167), studio-mcp-remote pas faite (#196), studio-oidc-generic pas faite (#197) · limites connues : experimental

Le Studio d’équipe (le Studio Server) met en ligne le Studio d’un jeu pour une petite équipe. Ce projet documente un seul hébergeur, Clever Cloud, en détail. Cette page dit ce qui y tourne, pourquoi c’est découpé ainsi, ce qu’il faut avant de commencer, ce que cela coûte à faire tourner et dans quel ordre lire les autres pages Clever.

Pourquoi

Un Studio partagé doit tenir trois promesses qu’un Studio local n’avait pas à tenir : aucune modification confirmée n’est perdue, chaque personne est distinguée, et le code du jeu ne tourne jamais avec les droits d’un membre. Chaque partie du déploiement répond à l’une d’elles.

navigateurs ─HTTPS─▶ studio (app Node, une instance) ──jobs signés──▶ studio-worker (app Node, sans secret)
CLI, MCP ─Bearer─┘     │  publicUrl : le Studio et /api                ▲ instantané et résultat présignés
                       │  playUrl :   le jeu (une autre origine)       │
                       ├──▶ PostgreSQL : journal, membres, sessions, baux
                       ├──▶ Cellar (S3) : le contenu des fichiers, les instantanés du worker ─┘
                       └──▶ fournisseur OpenID : qui sont les gens (jamais ce qu’ils peuvent faire)

Les fichiers du jeu vivent dans PostgreSQL (quelle version de chaque fichier) et dans Cellar (leur contenu). Le disque de l’application est un cache : celui de Clever Cloud ne survit pas à un redémarrage (mesuré par le spike S : un marqueur écrit, puis clever restart, avait disparu), et rien n’est perdu quand il part.
Le code du jeu ne tourne jamais dans le Studio. Le valider, construire ses prévisualisations et le lire passent par studio-worker, une seconde application qui ne détient ni mot de passe, ni clé, ni accès à la base (ADR 0028).
Le jeu se joue sur une autre origine (playUrl) : son code ne peut pas agir avec la session Studio d’un membre.
Le fournisseur dit qui est quelqu’un, le Studio décide de ce qu’il peut faire (ADR 0027).

Ce qu’il vous faut

Une organisation Clever Cloud où vous pouvez créer des applications et des add-ons, et clever-tools connecté à elle.
Deux applications Node.js (studio, studio-worker), un add-on PostgreSQL, un add-on Cellar avec un bucket, et un fournisseur OpenID Connect. Le Keycloak managé de Clever Cloud convient ; un autre fournisseur convient pour les connexions du navigateur, avec des limites (OIDC générique et GitLab).
Un domaine à vous, pour deux de ses sous-domaines (studio.exemple.fr, play.exemple.fr), jamais deux noms en *.cleverapps.io (Domaines et TLS).
Sur votre machine : le dépôt du moteur à la version que vous déployez, npm ci fait, pour créer les clés des jobs et lancer sauvegardes, restaurations et exports.

Limite · experimental Le Studio Server est expérimental. Ses passes humaines (studio-hosted, studio-collab, studio-preview, studio-assets-hosted, studio-mcp-remote, studio-oidc-generic) étaient encore not-run pour la 4.4.0 (docs/dev/passes/4.4.0.md). Un vrai Safari, sous macOS et iOS, n’a pas été essayé contre un Studio hébergé.

Ce que cela coûte à faire tourner

Aucun prix n’a été mesuré pour ce projet : le dépôt ne contient ni facture ni grille de prix datée. Cette page donne donc les ressources, pas un montant. Chiffrez-les sur la page des tarifs de Clever Cloud le jour où vous déployez.

Le déploiement de référence du 19 octobre 2026 (docs/dev/QUALIF-4.2.3-REFERENCE.md §1) tournait sur les plus petites tailles :

Ressource	Ce qu’il utilisait	Suffisant ?
Application `studio`	Node.js, taille XS (1 vCPU, environ 1 Go), 1 instance	Pour un jeu et quelques membres
Application `studio-worker`	Node.js, taille XS, 1 instance	Un job à la fois par file
PostgreSQL	plan DEV (5 connexions)	Non pour une équipe : un redéploiement fait tourner deux instances, qui dépassent 5 connexions (Applications et add-ons)
Cellar	plan S, un bucket	Oui pour le jeu de démo (500 fichiers)
Keycloak	managé, plan BASE	Oui

Pendant un redéploiement, les deux instances de chaque application tournent plusieurs minutes : ce chevauchement se paie aussi (Redéploiements). Tout supprimer, c’est Coûts et démontage.

Les pages Clever, dans l’ordre

Applications et add-ons
Domaines et TLS
Keycloak, ou OIDC générique et GitLab
Configuration
Premier déploiement
Sauvegardes, RPO et RTO, l’exercice de restauration
Redéploiements, Mettre à jour le serveur, Limites du retour arrière
Supervision, Sécurité, Renouveler les clés
Quand quelque chose casse : Récupérer l’accès administrateur, Changer de domaine ou de fournisseur OIDC, Worker, PostgreSQL ou Cellar en panne, Dépannage
Partir : Exporter le jeu, Rétention, Coûts et démontage

Les autres possibilités écartées

D’autres hébergeurs. Le mainteneur a choisi de documenter Clever Cloud seul, en détail (D50). Le serveur lit une configuration JSON et quelques secrets, et tourne partout où il y a Node.js, PostgreSQL et un stockage S3 : rien en lui n’est propre à Clever, mais aucun autre hébergeur n’est documenté ni vérifié.
Une application au lieu de deux. Faire tourner le code du jeu dans le processus du Studio lui donnerait les secrets du Studio. Sur le runtime Node.js de Clever Cloud il n’y a qu’un utilisateur système (bas), et un enfant peut lire l’environnement de son parent par /proc (spike S §1) : la séparation, c’est une seconde application (ADR 0028).
Docker. Le runtime Node.js natif a Python 3.13, pip et ffmpeg (spike S §5), assez pour les outils d’assets du worker ; Docker n’est jamais requis.
Deux noms en *.cleverapps.io. Ce sont deux sites (la Public Suffix List) : le cookie du jeu dépend alors des cookies partitionnés, que certains navigateurs refusent (Domaines et TLS).

Les compromis

Une seule instance. Un jeu par instance, une instance qui sert les écritures (un bail de service dans PostgreSQL). Pas de montée en charge horizontale.
Un redéploiement refuse les écritures un moment. Environ une minute d’écritures lentes ou refusées par redéploiement, aucune perdue (Redéploiements).
Les sauvegardes vivent dans le même bucket que les fichiers. Elles survivent à la perte de la base, pas à celle du bucket (Sauvegardes).
Des secrets en variables. Clever Cloud injecte les identifiants des add-ons en variables d’environnement : le serveur lit chaque secret une fois et le retire de son environnement, ce qui s’écarte de la règle maison « des secrets dans des fichiers » (ADR 0027).

Décisions et ADR

ADR 0025, le Studio Server ; ADR 0027, identité, sessions, jetons ; ADR 0028, où tourne le code du jeu.
Le spike S, le runtime mesuré : docs/dev/SPIKE-4.2.1-CLEVER.md ; le déploiement de référence : docs/dev/QUALIF-4.2.3-REFERENCE.md.
Ce qui tourne où, pour les membres : Ce qui tourne où.

Modifier la source de cette page · Signaler une erreur