How to Add Leaderboards to Your Game Without a Backend

A leaderboard needs three things: a way to tell players apart, a place to write scores that survives a page refresh, and a way to read the ranking back. Nothing in that list is a server you have to run. If you publish on Steam, Google Play or the App Store, the platform already operates the whole thing and hands you an API. If your game lives in a browser, the engine's own services or a managed game backend cover it. Building a backend of your own is a fourth route, and for most indie games it is the worst of the four.

The pattern repeats across indie forums and it showed up again in our latest community read: a developer finishes a web demo, wants a high-score table, and resigns themselves to "learning backend" for a feature that should cost an afternoon. This article walks the four routes that exist right now, what each one costs, where each one breaks, and how much to worry about cheating. One honest note before we start: this blog belongs to Egmatic, a no-code 2D editor in pre-alpha; where leaderboards sit in our own plans is covered at the end.

The short answer#

Your situation	Use this	Why
Shipping on Steam	Steam leaderboards	Free, part of Steamworks, every player already has a Steam identity
Shipping on Google Play or the App Store	Play Games Services or Game Center	The platform runs the board and the stock UI players recognize
Web build on itch.io or your own site	GDevelop's built-in leaderboards, or a backend with a REST or JavaScript API	A browser game has no store service to call, so the scores need an HTTP home
One game, several platforms	A game backend: Nakama, LootLocker or PlayFab	Cross-platform player identity in one table
You want to learn servers	Roll your own	Fine as a learning project, expensive as a product decision

One question decides the whole table: where do your players log in? A score is only as meaningful as the identity behind it. A Steam player is already signed in; an Android player has a Google account one tap away; an anonymous browser player is nobody until you give them a nickname or a login. Choose the route that already owns your players' identities and most of the work disappears.

What a leaderboard actually needs#

It helps to see the feature as four jobs, because each route below is just a different answer to who does each job.

1. Player identity. Every score needs an owner. Stores solve this with the account the player already has. Web games need nicknames, device IDs or a login, and the choice sets how seriously the ranking can be taken.
2. A score write that survives. When the run ends, the number leaves the player's machine and lands somewhere that outlives the session. This is the only part that feels like "backend", and it is one API call on every route here.
3. A ranked read. The menu screen asks for the top 50 and the player's own rank. Sorting millions of rows fast is a solved problem; you should never be solving it yourself on a Friday night.
4. Integrity. Scores that arrive from a player's device can be forged. Stores give you tamper protection or server-only writes; backends give you server-side handlers. How much of this you need is a design decision, covered below.

The myth to drop is that "no backend" means no servers exist. Every route in this article runs on servers. The real question is whose servers, and who gets paged when they fall over.

Route 1: The store you publish on already runs one#

Steam#

Steam leaderboards are part of Steamworks, free with your publishing account. You create them in the App Admin, or the game can create them at runtime through FindOrCreateLeaderboard, which is how per-level boards get made cheaply. Each board gets a sort method (ascending for time-based runs, descending for high scores), a display type (numeric, seconds or milliseconds) and an upload rule: keep-best, where Steam keeps the player's best score automatically, or force-update.

Two details deserve attention. Steam leaderboards can be flagged as Trusted: writes from clients are then rejected outright, and scores can only arrive through the SetLeaderboardScore Web API from your server, which is the clean anti-cheat path if you compute results server-side. And entries can carry user-generated content attached after upload, which is how games implement replay ghosts: beat a score, race the replay that set it. For an indie, that single feature is a retention mechanic disguised as a technicality.

Google Play Games Services#

On Android, Play Games Services leaderboards are configured in Play Console (Grow users, Play Games Services, Setup and management, Leaderboards), exist as drafts while you test, and publish with the game. Two operational facts matter more than any API detail. First, player progress resets are only possible while a leaderboard is still a draft; once published, wiping the board takes the Management API, so decide your reset policy before launch, not after the first balance patch. Second, Play Games Services ships tamper protection that automatically hides suspected tampered scores: on by default for new leaderboards, Android-only, up to 24 hours to take effect, and not retroactive. If your game also runs on the web and shares boards across platforms, that is the documented case for turning it off.

Apple Game Center#

On iOS and macOS, Game Center stores leaderboards natively; GKLeaderboard is the GameKit type your code talks to, and the boards themselves are configured in App Store Connect. Players are signed into their Apple ID, friends leaderboards come for free, and there is nothing to run. For a first iOS game, this is the entire answer.

The limitation all three share: they are silos. A Steam score will never meet a Google Play score in one table. If your game ships on several stores and players should compete across all of them, you need the next route.

Route 2: A game backend service#

A managed game backend is a service whose product is exactly the four jobs above: identity, writes, reads and integrity, with SDKs shaped for games. For web builds, it is the default answer, because itch.io serves your HTML5 game as static files and offers nothing server-side to call.

Service	What it is	Leaderboard specifics	Cost shape
Nakama	Open-source game server (Apache-2.0), self-hosted or managed	Operators per board: set, best, increment, decrement; reset schedules in cron format; one record per owner; SDKs for Unity, Unreal, Godot 3 and 4, JavaScript, Defold and more, plus plain REST	Free self-hosted; you operate it
LootLocker	Managed backend aimed at indies	Leaderboards plus player accounts that sign in through Steam, Google Play, Apple, Epic, Xbox, PlayStation or Nintendo	30-day trial capped at 1,000 monthly active players; free non-commercial licence for jam and hobby games; paid per-MAU after ($0.015 per extra player)
PlayFab	Microsoft's managed game platform	Versioned leaderboards that reset by version, with ranking events	Usage-metered

Nakama deserves a specific mention for two audiences. If you want zero vendor lock-in, it is genuinely open source: the whole server is Apache-2.0, and leaderboard operators (set, best, increment, decrement) and cron-based resets are first-class, not afterthoughts. If you care about score integrity, its server runtime is where validation belongs: the score is checked by your server code before it ever touches the board. LootLocker deserves the opposite mention: it optimizes for the developer who wants accounts, leaderboards and entitlements working today, with console sign-ins already wired, and its non-commercial licence makes it effectively free until your game is real enough to charge for.

The no-code route#

If you build in GDevelop, the answer is already in the editor. GDevelop ships built-in leaderboards managed from the games dashboard: you create boards there, submit with actions like "Save connected player score" (or "Save player score" for anonymous players with nicknames), and display the board with a ready action. The docs recommend connected players, since those accounts carry future features such as achievements, and the service is built to scale from small games up. For a no-code developer this closes the whole question: no server, no REST plumbing, one action away.

The other no-code engines do not ship one, and the honest framing matters: Construct has no first-party leaderboard, but its JavaScript event sheets can call any REST API, so Route 2 applies directly. Godot users get Nakama's dedicated Godot 3 and 4 clients, or the same REST route. In every case the shape of the work is identical: submit a number, fetch a list, render it.

What rolling your own actually costs#

The happy path is seductive: one table, one endpoint, an insert and a select, forty lines on a free Postgres tier. Then the game ships and the actual product arrives:

• Authentication, so scores have owners and one player cannot fill your top 100.
• Atomic writes, so two players posting in the same second get distinct ranks.
• Rate limits, before someone discovers your unprotected endpoint accepts ten thousand posts a minute.
• Moderation, because nicknames on a public board will eventually contain words you did not choose.
• Resets and seasons, which need a design, not just a DELETE.
• Monitoring, backups, and the question of what happens to the scores when the free tier ends or the database region blinks.

None of this is hard in isolation; all of it is attention. A reasonable rule: roll your own when the server is part of the game you are making, and buy Route 1 or 2 when it is not. Saving a per-MAU bill you have not hit yet is not a reason to become an operations engineer.

Shipping one this week#

1. Decide the surface. Where do your players log in? Store builds take Route 1; web builds take Route 2 or the engine's built-ins. One game, many stores: Route 2.
2. Create the board deliberately. Name, sort order, upload rule, reset policy. On Google Play especially, resets after publishing stop being a console checkbox; on Nakama the operator (best versus increment) cannot be changed after creation. Some of these are one-way doors; read them twice.
3. Wire exactly two calls. Submit when the run ends, fetch the top list plus the player's rank when the menu opens. Resist syncing scores mid-run; it doubles the failure modes for no player-visible gain.
4. Test in draft with a dirty device. Submit from a fresh install, from a returning player, and once with a nonsense score. The third test is the one that tells you whether your integrity tier is real.
5. Measure whether it worked. A leaderboard is a retention feature: if day-1 and day-7 retention do not move, the board is decoration. The game analytics guide covers the exact numbers to watch, and the post-launch strategy guide covers the weekly loop of reading them.

Cheating: how much to care#

Every score that leaves a player's device can be forged; memory editors and replaying proxies have existed as long as high-score tables. The platforms know: Play Games tamper protection hides suspected forged scores automatically, Steam Trusted writes move the write path entirely server-side, and Nakama validates submissions in server-side handlers you control. The design question is which tier your game lives in:

• Tier 1, friends and jams. Client-submitted scores, no protection. The stakes are nostalgia.
• Tier 2, a public board you care about. Platform protections on, server-side writes where the store offers them, plus a sanity clamp: a maximum score the game's rules could plausibly produce. Catches the lazy cheats, which is most of them.
• Tier 3, prizes on the line. Server-authoritative results: the score is computed server-side from the run's inputs, or a replay is validated before it ranks. Real work; only worth it with something at stake.

Most indie games belong in Tier 2 and stay there forever. Chasing Tier 3 without a prize pool is building security theater for a leaderboard four people visit.

Common mistakes#

• Publishing before deciding the reset policy. Google Play makes resets a draft-only luxury; publishing first turns a checkbox into a Management API project.
• One global board for a game with progression. A single table where the top thousand are endgame players tells a newcomer they lost before they started. Per-level boards (cheap on Steam and Nakama) keep the table winnable.
• Sort order decided late. Changing whether a board sorts ascending or descending re-ranks every existing entry around a different meaning of "better"; decide before the first real score lands, because the data does not convert with it.
• Trusting the client while worrying about it constantly. Pick a tier from the section above and stop thinking about it. The middle state, anxious and unprotected, is the worst of both.
• Resetting without telling anyone. A season that starts with players discovering their scores vanished is a retention wound. Announce resets; better, make them a feature.
• Building the backend before the game has players. The board nobody competes on is the cheapest infrastructure you will ever regret. Ship the game first; the first mobile game guide and the community-building playbook are the levers that actually move player counts at this stage.
• Forgetting persistence next door. A leaderboard without a save system players trust asks them to compete in a game that forgets them. The two features ship together in players' expectations.

How Egmatic fits#

We will be direct about the stage: Egmatic is a no-code 2D editor and engine, built on AI, currently pre-alpha. The reason this article exists on our blog at all is that the request keeps landing in our community reads: leaderboards and persistence for web demos are among the most recurring asks, usually phrased as resignation about the backend work involved. That demand is on our roadmap as part of the ship layer, the publishing side of the editor, because services that live next to publishing are exactly what a no-code developer should never have to hand-roll. We are not announcing a date here; pre-alpha honesty means dates arrive when we can keep them.

The frame we build toward is the same one this article argues for: you direct the game, the tooling executes the plumbing, and you own what ships. If a 2D editor whose publishing layer includes things like leaderboards and cloud persistence is the workflow you are waiting for, watch it take shape on the waitlist at egmatic.com.

Sources#

1. Steamworks Documentation — Leaderboards: creation via App Admin or FindOrCreateLeaderboard, sort and display types, keep-best and force-update uploads, Trusted writes and the SetLeaderboardScore Web API, UGC attachment
2. Android Developers — Play Games Services leaderboards: Play Console setup, draft-only resets, Management API reset methods, tamper protection behavior (updated June 2026)
3. Apple Developer — GKLeaderboard: "A leaderboard for a game that Game Center stores"
4. Heroic Labs — Nakama leaderboards: operators (set, best, increment, decrement), cron reset schedules, one record per owner, client SDK list; GitHub, heroiclabs/nakama, Apache-2.0
5. LootLocker — Pricing: 30-day trial with 1,000 MAU cap, free non-commercial licence, $0.015 per additional MAU; documentation for Unity, Unreal and Godot SDKs and platform sign-ins
6. GDevelop Wiki — Leaderboards: built-in creation and management in the games dashboard, connected and anonymous player scores
7. Microsoft Learn — PlayFab leaderboards API: versioned leaderboard definitions and version increment operations