Clever Cloud: overview, cost and prerequisites

The team Studio (the Studio Server) puts one game's Studio online for a small team. This project documents one host for it, Clever Cloud, in detail. This page says what runs there, why it is cut that way, what you need before you start, what it costs to run and in which order to read the other Clever pages.

Why

A shared Studio has to keep three promises a local one never had to: no confirmed change is lost, people are told apart, and the game's own code never runs with a member's rights. Each part of the deployment answers one of them.

browsers ─HTTPS─▶ studio (Node app, one instance) ──signed jobs──▶ studio-worker (Node app, no secrets)
CLI, MCP ─Bearer─┘   │  publicUrl: the Studio and /api              ▲ presigned snapshot and result
                     │  playUrl:   the game (another origin)        │
                     ├──▶ PostgreSQL: journal, members, sessions, leases
                     ├──▶ Cellar (S3): the files' contents, the worker's snapshots ─┘
                     └──▶ OpenID provider: who people are (never what they may do)

• The game's files live in PostgreSQL (which version of each file) and Cellar (their contents). The app's disk is a cache: Clever Cloud's disk does not survive a restart (measured by spike S: a marker written, then clever restart, was gone), and nothing is lost when it goes.
• The game's code never runs in the Studio. Validating it, building its previews and reading it go to studio-worker, a second app that holds no password, key or database access (ADR 0028).
• The game is played on another origin (playUrl), so its code cannot act with a member's Studio session.
• The provider says who someone is, the Studio decides what they may do (ADR 0027).

What you need

• A Clever Cloud organisation where you may create apps and add-ons, and clever-tools logged in to it.
• Two Node.js applications (studio, studio-worker), a PostgreSQL add-on, a Cellar add-on with one bucket, and an OpenID Connect provider. Clever Cloud's managed Keycloak add-on works; another provider works for browser logins, with limits (Generic OIDC and GitLab).
• A domain of your own, for two subdomains of it (studio.example.fr, play.example.fr), never two *.cleverapps.io names (Domains and TLS).
• On your machine: the engine repository at the version you deploy, with npm ci done, to make the job keys and to run backups, restores and exports.

What it costs to run

No price was measured for this project: the repository holds no invoice and no dated price list, so this page gives the resources, not an amount. Price them on Clever Cloud's pricing page on the day you deploy.

The reference deployment of 19 October 2026 (docs/dev/QUALIF-4.2.3-REFERENCE.md §1) ran on the smallest sizes:

During a redeploy both instances of each app run for minutes, so you pay for that overlap too (Redeploys). Deleting everything is Costs and teardown.

The Clever pages, in order

1. Apps and add-ons
2. Domains and TLS
3. Keycloak, or Generic OIDC and GitLab
4. Configuration
5. First deployment
6. Backups, RPO and RTO, the restore drill
7. Redeploys, Upgrading the server, Limits of going back
8. Monitoring, Security, Rotating keys
9. When something goes wrong: Recovering admin access, Changing domain or OIDC provider, Worker, PostgreSQL or Cellar down, Troubleshooting
10. Leaving: Exporting the game, Retention, Costs and teardown

Alternatives set aside

• Other hosts. The maintainer chose to document Clever Cloud only, in detail (D50). The server itself reads a JSON configuration and a few secrets and runs anywhere Node.js, PostgreSQL and an S3 store are: nothing in it is specific to Clever, but no other host is documented or checked.
• One app instead of two. Running the game's code in the Studio's process would give it the Studio's secrets. On Clever Cloud's Node.js runtime there is a single system user (bas), and a child can read its parent's environment through /proc (spike S §1): a second app is the separation (ADR 0028).
• Docker. The native Node.js runtime has Python 3.13, pip and ffmpeg (spike S §5), enough for the worker's asset tools; Docker is never required.
• Two *.cleverapps.io names. They are two sites (the Public Suffix List): the game's cookie then depends on partitioned cookies, which some browsers refuse (Domains and TLS).

Trade-offs

• One instance. One game per instance, one instance serving writes (a service lease in PostgreSQL). There is no horizontal scaling.
• Redeploys refuse writes for a while. About a minute of slow or refused writes per redeploy, none lost (Redeploys).
• Backups live in the same bucket as the files. They survive the loss of the database, not of the bucket (Backups).
• Secrets in variables. Clever Cloud injects add-on credentials as environment variables: the server reads each secret once and removes it from its environment, which departs from the house rule "secrets in files" (ADR 0027).

Decisions and ADRs

• ADR 0025, the Studio Server; ADR 0027, identity, sessions, tokens; ADR 0028, where the game's code runs.
• Spike S, the runtime measured: docs/dev/SPIKE-4.2.1-CLEVER.md; the reference deployment: docs/dev/QUALIF-4.2.3-REFERENCE.md.
• What runs where, for members: What runs where.