HELIX 3 Docs
Platform API

Cloud Save

Durable, authoritative per-world key–value storage. The source of truth for anything that must survive a session.

Helix.cloudSave is HELIX's durable key–value store, scoped per world. It's the right place for anything that must outlive an instance: player progress, settings, world state. If you know Roblox, this is DataStore.

Cloud Save vs Memory Store

Cloud Save is durable and authoritative — the source of truth. Memory Store is volatile and fast — caches, leaderboards, matchmaking — and always expires. When in doubt about where data belongs, ask: "would losing this be a bug?" If yes, it's Cloud Save.

API

Prop

Type

Example

type Progress = { level: number; coins: number };

// load on join
const progress = (await Helix.cloudSave.get<Progress>(`progress:${playerId}`)) ?? {
  level: 1,
  coins: 0,
};

// save on change
await Helix.cloudSave.set(`progress:${playerId}`, progress);
UHelix::Get()->CloudSave()->Get(
    FString::Printf(TEXT("progress:%s"), *PlayerId),
    FOnJson::CreateLambda([](const FHelixJson& Value) { /* ... */ }));
local key = "progress:" .. playerId
local progress = Helix.cloudSave.get(key) or { level = 1, coins = 0 }
Helix.cloudSave.set(key, progress)

Semantics & guarantees

  • Per-world namespace. Keys are isolated to your world; you can't read another world's data.
  • Authoritative. Writes are durable once set resolves.
  • Write from the server for value-bearing data. Persisting currency/inventory-adjacent state belongs to server-authoritative code — never let a client write its own balance. See the golden rule.
  • No direct database access. Creator code reaches persistence only through this API, never a raw DB connection.

Concurrency

Two instances of the same world can run at once. For counters or state edited by many players, prefer an atomic update pattern (read-modify-write guarded server-side) or use Memory Store's increment for hot, transient counters and flush to Cloud Save periodically.

Reference

On this page