Domains and TLS

Français · Type: how-to · Audience: admin · Context: hosted Studio · Status: ready · Applies from: 4.2.3

The Studio Server (hosted team Studio) · contract: experimental · verified by CI (support matrix of 4.4.0, 2026-10-23): Postgres, S3 and Keycloak in CI; Chromium and Firefox (job studio-hosted); WebKit on macOS, by hand only · automated checks: jobs studio-hosted, studio-install-smoke; CI plan studioHosted; 3 test files · people's passes: studio-hosted not run (#149), studio-collab not run (#150), studio-preview not run (#166), studio-assets-hosted not run (#167), studio-mcp-remote not run (#196), studio-oidc-generic not run (#197) · known limits: never-cleverapps

The Studio and its game need two origins, and they must be two subdomains of one domain you own. This page gives them to the studio app, gives the worker its own name, and says why *.cleverapps.io names are not enough.

What you get

Three HTTPS names, all under your domain: studio.example.fr (the Studio and its API, publicUrl) and play.example.fr (the game, playUrl), both served by the studio app, and worker.example.fr (worker.url) served by the worker app.

Context and versions

A hosted Studio on Clever Cloud, from 4.2.3.
Verified on: not verified on a live installation for this page. Two names on one application, routed by Host, was confirmed by spike S on 17 October 2026, and the reference deployment of 19 October 2026 ran with three *.cleverapps.io names. Nobody has yet deployed the Studio on a custom domain and recorded it: the studio-hosted pass ("a TLS domain") is not-run for 4.4.0.

Prerequisites

The apps of Apps and add-ons.
A domain of your own, and access to its DNS zone.

Where to run the commands

clever …: on your machine, in the engine repository where both apps are linked under their alias. The DNS records: at your DNS provider.

Steps

Give the studio app both of its names, and the worker its own:

# on your machine, in the engine repository
clever domain add studio.example.fr --alias my-game-studio
clever domain add play.example.fr --alias my-game-studio
clever domain add worker.example.fr --alias my-game-worker

At your DNS provider, point each name at Clever Cloud with the record Clever's console shows on the app's domain names page (for a subdomain, a CNAME). Clever Cloud then serves it over HTTPS with a certificate it obtains itself; this project has not recorded how long that takes.

Write the same names in the configuration: publicUrl, playUrl and worker.url (Configuration). The server keeps only their origins, and refuses to start when publicUrl and playUrl are the same origin ("playUrl must be another origin than publicUrl").

Why two subdomains of one domain

The game runs in a frame of the Studio, on playUrl, behind its own session cookie (Secure; HttpOnly; SameSite=None; Partitioned). With two subdomains of your domain, the Studio and the game are one site, and the frame keeps its cookie in every browser.

cleverapps.io is on the Public Suffix List (a private entry, Clever Cloud's): studio-x.cleverapps.io and play-x.cleverapps.io are two sites. The game's cookie then lives in a frame of another site only because it is partitioned (CHIPS):

Measure · cross-site-cookie A cross-site game frame on two cleverapps.io names: a SameSite=None cookie was kept by Chromium and Firefox 157 and blocked by WebKit (Safari 27.2 engine); a Partitioned (CHIPS) cookie was kept by all three.

date: 2026-10-17

version: 4.2.1

volume: one page /iframe-test, three authentications per browser

conditions: spike S, Clever Cloud test organisation, region par; browsers driven by Playwright; real Safari on macOS and iOS not measured

source: SPIKE-4.2.1-CLEVER.md §7

Limit · never-cleverapps Never use two *.cleverapps.io names for publicUrl and playUrl in a deployment people use. The hosted e2e shows Chromium, Firefox and WebKit on macOS keeping the partitioned cookie; WebKit on Linux (GNOME Web) stores no cookie a frame of another host sets, even on one site, so the game's frames stay empty there. A real Safari, on macOS and iOS, is the studio-hosted pass, not done yet.

Expected result, and how to check it

clever domain --alias my-game-studio lists both names; clever domain --alias my-game-worker lists the worker's.
Once deployed (First deployment), https://studio.example.fr/livez answers {"ok":true} with a valid certificate, and https://play.example.fr/ answers 401 ("open the game from the Studio"): the game's origin refuses any request without the game's session.
In the Studio, the room view and the Play tab show the game.

Common errors

Symptom	Cause	Fix
`playUrl must be another origin than publicUrl (plan §6.1)` at start	The same name in both	Two names, `studio.` and `play.`
The game's frames stay empty in one browser	Two sites (`*.cleverapps.io`), or WebKit on Linux	Two subdomains of one domain; see Troubleshooting
A certificate error	The DNS record does not point at Clever Cloud yet	Check the record; wait for propagation

Files or data changed

The apps' domain lists in Clever Cloud, your DNS zone, and later the configuration's URLs.

Recovery or going back

clever domain rm <name> --alias <app> removes a name. Changing the names of a running Studio is Changing domain or OIDC provider: the provider's redirect URIs change with them.

References

The game origin's cookie: studio-server/src/server/play.ts; the origins checked: studio-server/src/server/config.ts.
Spike S §7 and §9: docs/dev/SPIKE-4.2.1-CLEVER.md.
Security, for the cookie policies.

Edit the source of this page · Report an error