Skip to content
quest'n'click

Clever CloudHow-toFor adminsApplies from 4.2.3

Domains and TLS

Cette page en françaisThis page on the GitHub wiki

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

  1. 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
  1. 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.
  1. 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):

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

SymptomCauseFix
playUrl must be another origin than publicUrl (plan §6.1) at startThe same name in bothTwo names, studio. and play.
The game's frames stay empty in one browserTwo sites (*.cleverapps.io), or WebKit on LinuxTwo subdomains of one domain; see Troubleshooting
A certificate errorThe DNS record does not point at Clever Cloud yetCheck 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