> ## Documentation Index > Fetch the complete documentation index at: https://docs.pylonsync.com/llms.txt > Use this file to discover all available pages before exploring further. # Pylon vs. Playroom Kit > Playroom Kit is the easiest way to ship a web multiplayer game today. Pylon is for when 'easiest' isn't enough. [Playroom Kit](https://playroomkit.com) is a managed multiplayer SDK aimed at web games and collaborative apps (HTML5, Unity WebGL, browser puzzles). It optimizes hard for "ship a working multiplayer game in an afternoon" — at the cost of being managed-only infrastructure. ## TL;DR * **Choose Playroom** if you're shipping a casual web game this week, you don't want to operate any backend, and you accept managed-only deployment. * **Choose Pylon** if you want self-hosting, full server authority, persistent domain data, or a dedicated server runtime. ## Big picture | | Pylon | Playroom | | ------------------------------- | -------------------------- | --------------------------------------------------------------------- | | License | MIT / Apache 2.0 | Proprietary | | Self-host | ✅ | ❌ managed only | | Server authority | ✅ tick-based | ⚠️ host-authoritative client model | | Persistent player data | ✅ entities + auth | ⚠️ room/player state; bring your app database for durable domain data | | Built-in auth | ✅ | ⚠️ guest-by-default | | File storage | ✅ | ❌ | | Search | ✅ | ❌ | | Game shards / rooms | ✅ | ✅ | | Setup complexity | Medium | Very low | | Max concurrent players per room | Dedicated server dependent | Host/model dependent; benchmark | ## Architecture Playroom uses a **host-authoritative** room-state model: when players join a room, one participant is elected host and is responsible for authoritative state changes. Other participants send changes through that model. For unreliable state updates, Playroom can use WebRTC; reliable updates go through its WebSocket server. This is brilliant for "trivia game with 4 friends" — no custom server code, simple integration. It struggles when: * The host has a slow phone and tanks the room * The host disconnects mid-game and state has to be re-synced from peers * You need server-side validation (anti-cheat, scoring authority) * Concurrent players exceed what the elected host and room model can comfortably simulate Pylon (and Colyseus, and Nakama) use a **server-authoritative** model: the server runs the tick loop, all state lives on the server, clients send inputs and receive state. More expensive operationally; more robust. One thing to know up front, since Playroom's audience is web/JS developers: Pylon's authoritative tick loop is written in **Rust** (the `Shard` crate), with a `useShard` React hook to connect from the client. There's no TypeScript API for the server simulation today. Your app data, auth, and functions stay in TypeScript — but the shard authority itself means writing Rust. ## Where Playroom is better * **Time-to-first-multiplayer** — minutes, not hours. The SDK includes a discovery UI, joins via room codes, and "just works" with a few lines of code. * **Web/mobile cross-play** — handles different platforms invisibly. * **Fast prototypes** — the hosted model is excellent for hobby projects and throwaway experiments. * **No backend to deploy** — at all. Add the SDK, ship. * **Phone-as-controller** — Playroom has a slick "stream from your laptop, control from your phone" pattern. ## Where Pylon is better * **You own your backend** — no vendor outage takes down your game. * **Server authority** — players can't hack the host. Critical for competitive games or anything with persistent rewards. * **Persistent player data** — every player has a real account with stable identity, not a per-room guest. Inventory, progress, friends, leaderboards, cosmetics — all first-class. * **Higher authority ceiling** — server tick loops scale beyond what one elected client can safely simulate. * **Backend logic** — server-side validation, anti-cheat, complex matchmaking, fraud detection. * **Self-host** — no per-player pricing as you grow. * **Open source** — fork it, ship it, never depend on a vendor. ## Use case fit | Game type | Recommended | | ----------------------------------------- | ------------------------------------------------------- | | 2–8 player party game | Playroom | | Trivia / quiz / drawing | Playroom | | Phone-as-controller experience | Playroom | | Casual co-op web game | Either | | Competitive multiplayer (rankings matter) | Pylon (or Colyseus, Nakama) | | Persistent-world game | Pylon | | Large authoritative rooms | Pylon | | Game with progression, inventory, profile | Pylon | | Internal corp game (no signup, just join) | Playroom | | Mobile game with cross-play | Playroom for prototyping; Pylon for production at scale | ## Pricing Check Playroom's current pricing and limits before launch. It is designed to make prototypes and lightweight multiplayer cheap to start. Pylon self-hosting is just infrastructure cost. Pylon Cloud uses plan quotas plus machine compute. That is more operational responsibility than Playroom, but it gives you a dedicated server runtime, durable data, and a path to move off the hosted platform. ## Migrating from Playroom If you started with Playroom and outgrew it: 1. **Move authority to the server** — port your "host" logic into a `SimState::tick` impl on the Pylon side (this is Rust — Pylon's shard authority isn't a TypeScript API today, so budget for that rewrite) 2. **Convert room state from key-value to entities** — Playroom's `getState`/`setState` pattern maps to Pylon's entity CRUD 3. **Add real auth** — replace guest sessions with magic-code sign-in (or keep guest sessions for "just play" via `/api/auth/guest`) 4. **Persist player data** — move from Playroom's volatile state to Pylon entities The hardest part is the mental shift from peer-state to server-authoritative. The code itself is straightforward. ## Honest weakness Playroom's developer experience for the "ship a party game this weekend" use case is genuinely better than any server-authoritative option, including Pylon. The SDK is more polished for web games specifically; the room-code join UX is excellent; the phone-as-controller story has no Pylon equivalent. If you're building a hackathon project or an MVP to validate a multiplayer game idea, **start with Playroom**. Migrate to Pylon (or Colyseus, or Nakama) when you outgrow the host-authoritative client model. ## Both / and You can use Playroom for the lightweight lobby UX and Pylon for persistent player data + leaderboards + matchmaking, with the clients pulling from both. This is unusual but valid — Playroom's strength is the realtime party-game shape; Pylon's strength is everything else around it.