Replace PlayFab without rewriting every call site on day one.
crux-playfab-compat accepts the common PlayFab request shapes your game already sends,
returns a PlayFab-style response envelope, and lets you move the backend underneath the client incrementally.
It is not a fake drop-in: unsupported calls fail loudly and the migration guide lists the gaps.
Free Dev BaaS tier: 10,000 MAU, every backend feature, unlimited projects, no credit card.
npm install crux-playfab-compat
const PlayFabClientAPI = new PlayFabClientCompat(
CruxClient.forPlayer(baseUrl, projectId, envId, apiKey),
);
// existing request shape stays
PlayFabClientAPI.GetUserData(
{ Keys: ["save"] },
(res, err) => { /* ... */ });Audit the migration path before touching production.
Crux does not claim PlayFab parity. Inspect the hosted API contract, the open client SDKs, the exact migration map, and the exit path before you decide whether the gaps are acceptable for your title.
Live API status
A live check of the hosted API right now. No made-up uptime percentage and no hidden demo environment.
Check current statusPublic API contract
The hosted HTTP surface is documented as OpenAPI. Inspect the wire format before choosing an SDK or writing an adapter.
Open the specMIT client SDKs
The JavaScript, Godot, Unity, and Roblox client SDK source is public. The hosted backend itself remains a managed proprietary service.
Inspect the SDK sourceDocumented exit path
Read what is exportable today and the written commitment for advance notice plus an export window if the hosted service winds down.
Read the exit guaranteeMethod-by-method map
The migration guide separates compatible session-path calls from behavior differences and capabilities with no direct Crux equivalent.
Read the migration mapKeep the common call shapes
Login, user data, title data, leaderboards, statistics, inventory, virtual currency and friends are the session-path surface the compatibility layer is built around.
Fail loudly on gaps
Unknown or unsupported methods fail explicitly: JavaScript and C# throw; GDScript returns a non-success error envelope. CloudScript is not pretended away; characters, receipt validation, shared groups, trading and other non-equivalent surfaces are called out explicitly.
Cut over incrementally
Start in staging, migrate the common API path, move custom server logic deliberately, then run a parallel-write period before making Crux the source of truth.
What you can migrate first
| PlayFab-shaped job | Migration path |
|---|---|
| Login* | Crux auth behind the compatibility client |
| GetUserData / UpdateUserData | One persistent Crux player document |
| GetTitleData | Live config |
| GetLeaderboard / UpdatePlayerStatistics | Crux leaderboards |
| GetUserInventory | Crux inventory |
| Add/SubtractUserVirtualCurrency | Crux currencies |
| Friends calls | Crux friend requests, with documented semantic differences |
Do not switch if the missing surface is central to your game.
Crux does not execute PlayFab CloudScript. It also does not claim a direct replacement for every PlayFab product. If your title depends on a missing capability, price the rewrite before you migrate.
- CloudScript/custom code moves to your own service
- Some social/group semantics differ
- Several PlayFab-specific services have no Crux equivalent
Compare before touching production.
The comparison pages separate three intents that are easy to mix up: PlayFab's current pricing/modes, alternative vendors, and the engineering migration itself.
Prove the compatibility path in staging.
Create a free Crux project, wire the compatibility client to a staging build, and start with one read/write path such as player data. You do not need to commit to a full cutover to test whether the migration shape works.