Leaderboards and cloud saves for HTML5 games: an SDK guide

Your browser game runs. Then a player switches from a laptop to a phone and their progress is gone, and the high score table only ever shows their own runs.

That is usually the moment an HTML5 developer starts pricing a backend: accounts, a score table, a save blob per player, and something that stops the most obvious cheating.

Most small teams do not need to build that from scratch. The category is well served, and the interesting decision is not which database to run. It is who owns the player account your saves and scores hang off.

This guide covers what you actually need, the three shapes the market comes in, what each option costs and caps as of August 2026, and where the Bounty Board Arcade SDK sits among them.

The direct answer

• Want infrastructure that follows your game anywhere? Use a standalone backend. Talo is free up to 10,000 players and MIT licensed if you want to self host it. LootLocker gives you player files of up to 5 MB each.
• Already publishing on a portal? Use that portal's SDK. It reuses the portal's player account, which is the hard part to reproduce elsewhere.
• Shipping to several portals? GamePush wraps more than 30 of them behind one integration.
• Hosting on an arcade? The arcade's own SDK often reduces integration work, at the cost of tying those features to that arcade.

Standalone backends are portable but bring no players. Portal and arcade SDKs bring players but lock the features to that surface. That is the main tradeoff.

What you need

Three capabilities, usually in this order.

Score submission with basic abuse resistance. A score posted from the browser is a number a player can edit. Useful services give you some combination of a signing key for client submissions, a separate server key so you can post scores from your own backend instead, bounds on accepted values, and a cooldown between submissions. CrazyGames documents all four, which makes its leaderboard docs a good checklist even if you never publish there.

Persistent saves that survive a device change. A localStorage save is tied to one browser and origin. Syncing progress across devices requires a player identity, which is why almost every option in this guide is really an accounts product with storage attached.

Optional multiplayer. Real time rooms are the most expensive thing on any of these price lists. Do not buy them before your game needs them.

The three shapes

Standalone backends are game backends you point anywhere: your own domain, itch.io, a portal, a native build later. You own the data and reduce dependence on any one portal. They bring you no players on their own.

Check the integration list before committing, because most of this category grew up around native engines. Talo ships official Godot and Unity plugins plus an HTTP API and WebSockets, with no dedicated browser SDK listed, so a JavaScript game talks to it over REST. LootLocker's SDK and guide material is similarly engine first.

Portal SDKs reuse the portal account. The player is already signed in to Poki or CrazyGames, so saves and scores attach to an identity you did not have to build. The cost is scope: the features exist on that portal, under that portal's program rules, and porting your game elsewhere means porting the integration too.

Aggregator SDKs sit in between. GamePush offers one integration that fans out to Yandex Games, CrazyGames, GameDistribution, Telegram, VK Games and others, with its own cloud saves, leaderboards, and achievements behind it. If you publish to many portals, this is the pragmatic answer.

Arcade or platform SDKs are portal SDKs with a narrower audience and can bundle platform-specific features alongside saves and scores.

The landscape as of August 2026

Every row below comes from the vendor's own docs or pricing page, checked on August 19, 2026. Commercial terms move; recheck the linked source before you commit.

Two limits worth checking before you build

Both of these surface constantly in summaries of this category, and both hold up against current docs.

CrazyGames leaderboards are invitation only. The docs are blunt: "The leaderboard feature is only available for invited games," and only one leaderboard per game is supported. Scores can be submitted from the client with an encryption key or from your server with an API key, but neither matters until you are invited. Do not plan a launch around a feature you have to be selected for.

Portal cloud saves stop at 1 MB. CrazyGames rejects game data above 1,048,576 bytes as JSON. Poki caps the payload at 1 MB after gzip compression, and past that, cloud saves are disabled for that player and their progress stops syncing. GamePush sets the same ceiling and recommends staying under 10 KB gzipped.

One megabyte is plenty for scores, unlocks, currency, and settings. It is not enough for a level editor with player made content, or a save that embeds images. If your progress model can grow without bound, keep the large parts somewhere else and store references. LootLocker is the outlier here: 50 files per player at 5 MB each is a different order of storage, which is part of why its pricing is quote based.

Where the Bounty Board Arcade SDK fits

@bountyboard/arcade-sdk is the SDK for games hosted on Bounty Board Arcade. It is MIT licensed, has zero runtime dependencies, ships ESM, CommonJS, global and TypeScript declaration builds, and is safe to import during server rendering. You install it from npm, or drop in a script tag that installs window.BBArcade if your build has no bundler.

What it provides:

• Scores. submitScore() during a run and gameOver() once at the end, bracketed by gameplayStart() and gameplayStop() so the host knows when play is active. Scores are integers. Passing { mode: 'daily' } puts the run on a shared seed daily board.
• Cloud saves. save() takes your whole progress model as one string blob of about 1 MB, load() returns a string or null. Rejections are real errors carrying a typed code: unsupported, unauthenticated, too_large, rejected, or error, so you can branch on them rather than guess.
• A storage shim for engine exports. GameMaker, Godot, Unity and Construct builds route their save layer through localStorage and cannot be rewired without patching engine internals. storage.install() replaces it with a Storage shaped object backed by the cloud save, and storage.ready() resolves cloud, memory, or native so you know what you got.
• Public display identity. getPlayer() returns a name and an avatar URL, never account ids, emails, or roles, and onPlayerChange() fires when a player signs in or out mid session.
• A/B variants, rewarded ads, site lock, and multiplayer rooms. Variant assignment is stable per player, game and key. Rewarded ads are prepared first and shown from the player gesture, and only a viewed result grants anything. Multiplayer runs on relay rooms with no server code, refereed modules, or your own registered server.

The design rule worth borrowing regardless of which SDK you pick: it is never allowed to be required. With no host present, fire and forget calls do nothing, init() resolves after a short grace, getPlayer() resolves null, getVariant() returns the alphabetically first control, and saves settle with a documented unsupported outcome. Your game must still boot and play with all of that happening at once.

The honest limits

Cloud save works for signed in players on a build hosted by the Arcade. A game embedded into the Arcade by URL, or played standalone on your own site, does not get it, and multiplayer is unsupported standalone. The save cap is the same 1 MB the portals enforce. There are no engine plugins the way Talo and LootLocker ship for Unity and Godot; the storage shim covers engine exports instead.

Most of all: this is a distribution choice as much as a technical one, exactly like the portal SDKs. The features exist because the game is on the Arcade.

That is also the argument for it. Scores submitted through the SDK render on your game's Arcade page, so the site's traffic can help populate the board instead of leaving all discovery to you. That is a different starting position from a standalone backend where an empty board is entirely your problem to solve. Eligible Arcade studios also keep 90% of finalized ad revenue attributed to their game, settled monthly via Stripe once the $50 minimum is reached.

The Arcade is smaller than Poki or CrazyGames. If raw browser reach is the job, a major portal is still the better answer, and there is no reason not to do both. If you want a hosted build with leaderboards, saves, and an audience attached, submit a game, and check what makes a browser game ready for the Arcade before you do.

Sources worth reading

• Talo pricing
• Talo documentation: integrations
• Talo open source and self hosting
• LootLocker pricing
• LootLocker guide: cloud saves with player files
• GamePush cloud saves
• GamePush platform overview
• CrazyGames SDK: leaderboards
• CrazyGames SDK: data module
• Poki SDK: HTML5 documentation
• Poki: player accounts and cloud saves