Retention
Français · Type: reference + 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 planstudioHosted; 3 test files · people's passes:studio-hostednot run (#149),studio-collabnot run (#150),studio-previewnot run (#166),studio-assets-hostednot run (#167),studio-mcp-remotenot run (#196),studio-oidc-genericnot run (#197) · known limits:no-erasure-command
What a hosted Studio keeps, where, and for how long, read from the code of the current version; then what you can delete, and how. Most of the project is kept for good on purpose: the journal is the game's history.
Verified on: not verified on a live installation for the deletions below (gc --delete was not run on the
reference deployment); --keep was (Backups). Applies from 4.2.3.
The journal and the game's files
| What | Where | Kept |
|---|---|---|
| Every confirmed operation (who, when, which files, their contents' hashes before and after) | PostgreSQL, studio_ops | For good. Nothing deletes a confirmed operation: it is the history undo, the diff and the replay read |
| The head: each file's current version | PostgreSQL, studio_files | While the file exists |
| The files' contents (blobs, by hash) | Cellar, sha256/<hash> | While a row names it (the head, any operation, a preview, a build, a prepared set), and at least a day; after that, only gc --delete removes it |
| The journal shipped to the bucket | Cellar, journal/<epoch>/<line>/<rev>.json | For good: nothing deletes a segment |
Previews, builds, prepared assets
| What | Kept |
|---|---|
| Each revision's preview (its paths and hashes, or why it failed) | For good, with its blobs: about 1 MB per revision for the sample game, few files shared between revisions. No command deletes previews in this version |
| Published builds | For good |
| Prepared asset sets | The rows for good; on the instance's disk only the current set (an older one is removed when a new one is served) |
| The worker's staging (a job's snapshot and result) | staging/ in the bucket: deleted after each job; anything left older than an hour is removed by gc --delete |
Backups
The daily backup keeps the STUDIO_BACKUP_KEEP most recent (14 by default) of the backups it wrote; a backup taken by
hand with backup --to-bucket and no --keep is counted among them at the next daily run, as it has the same name
form. Copies you make elsewhere are yours to delete (Backups).
People and sessions
| What | Kept |
|---|---|
Users (the provider's iss, sub, email, name), seen at first login | For good, also after a member is removed (their email and name follow the provider at each login) |
| Members and roles | Until removed by an owner |
| Invitations (stored by their hash) | Used once, valid 7 days; the rows stay |
| The audit log (logins, invitations, role changes, removals, revocations; the actor's id) | For good. GET /api/audit shows the 200 most recent |
| Comments, with their author's name | For good: a comment is edited or resolved, never deleted |
| Browser sessions | 8 h idle, 24 h in all (configurable); a session row is deleted at logout, removal, revocation, or when presented after it ended. No periodic sweep |
| Logins under way | 10 min; deleted at the next login |
| The game origin's tickets and sessions | 60 s and 15 min; expired ones deleted at the next use |
| Answers kept for a client's retry (by operation id) | 7 days |
| Back-channel logout tokens seen | Until their own expiry |
Limit ·
no-erasure-commandThere is no command to erase a person from a project: removing a member ends their access, but their user row, the audit entries and the operations they wrote (authored by them in the history) remain, in the database and in every backup. Erasing them means editing the database by hand, which this project does not document.
In memory, and the logs
- Jobs (Prepare, cuts) are kept in the instance's memory, the 50 most recent ended ones; a restart forgets them.
- The metrics live in memory and restart from zero.
- The logs go to Clever Cloud's log service; how long Clever keeps them is Clever's setting, not this project's. Request lines carry the path, the status and the client's address; never a secret.
Deleting what can be deleted
List what the collection would delete, without deleting anything:
# in a shell on the studio app (clever ssh --alias my-game-studio) cd "$APP_HOME" && npm run -s studio-server -- gcIts line,
{"event":"collectable","referenced":…,"unreferenced":…,"removed":0,"staging":…}, counts the blobs no row names (older than a day) and the stale staging objects.
Take a backup first, then delete:
# in a shell on the studio app (clever ssh --alias my-game-studio) cd "$APP_HOME" && npm run -s studio-server -- gc --deleteAn older backup restored after a collection loses only the previews, builds and prepared sets whose blobs the collection took (counted as
dropped). Never run it against a drill's database: it would delete blobs production still names.
Guarantee ·
gc-keeps-referenced· referenced · executed onaff6caab7514· scope self-checked by the author (AI), not reviewed The collection keeps every blob a row names and every blob still in its grace period (a write may be storing it now), and deletes the rest only with--delete.
The grace period is a day by default.
Related identifiers
npm run studio-server -- gc,backup --to-bucket --keep,STUDIO_BACKUP_KEEP.- The code:
studio-server/src/ops/gc.ts,studio-server/src/ops/backup.ts(what a backup keeps or skips, and why),studio-server/src/server/auth/store.ts; the test:tests/studio-backup.test.ts. - Leaving altogether: Exporting the game, Costs and teardown.