Server Authority: What Developers Need to Know
On this week's episode of Beyond The Blox, Anthony, Fedor and I took a deep dive into Server Authority — one of the most exciting beta features Roblox is working on right now. It has the potential to fundamentally change how multiplayer games handle physics, cheating, and client-server communication on the platform.
What Is Server Authority?
Right now, Roblox games distribute physics calculations across each player's device. That's efficient — your machine handles the physics for objects near you, and the server doesn't have to do all the heavy lifting. The downside? You're trusting the client, and as any security-conscious developer knows, that's a recipe for exploits. Speed hacks, flying, moving objects through walls — all possible because the client has the final say.
Server Authority flips that model. Simulations now run on both the server and the client simultaneously. Your client runs a prediction of what the server will calculate, giving you that instant response when you press a key. The server then periodically checks whether your client's state matches its own. If there's a discrepancy — say, because someone tried to teleport or walk through a wall — the server rolls back the client to the correct state.
The result: cheaters get shut down, and legitimate players barely notice a difference.
Setting It Up
Enabling Server Authority isn't a single toggle — at least not yet. There are several prerequisites that need to be switched on first:
- Streaming Enabled (default on new experiences)
- Signal Behavior set to Deferred
- PhysicsSteppingMethod set to Fixed
- UseFixedSimulation enabled
- PlayerScriptsUseInputActionSystem enabled (uses the new Input Action System)
- Next Generation Replication enabled
Once all of those are in place, you can change the authority mode from Automatic to Server. Out of the box, that stops fly hacks, walk speed hacks, and property manipulation. I'd expect this process to be simplified — or even become the default — as the feature matures.
What Changes for Developers?
The key new API is BindToSimulation, which lets you write shared code that runs on both client and server. I built a billiards demo to test this out, and the workflow is surprisingly clean: you write one module that describes the behavior, and Roblox handles the rollback behind the scenes. No explicit rollback APIs to call, no manual state syncing — you just define the simulation logic and let Roblox do the rest.
There are some restrictions to be aware of. You can't yield inside BindToSimulation — no task.wait(), no task.spawn(). Everything must resolve within a single frame. You also can't modify GUI instances from within the simulation step. If you need to update UI based on simulation state, that has to happen separately via a render step or signal.
The advanced techniques documentation covers a useful pattern for handling that initial sync moment. Instantaneous physics actions — like an explosion — can look jarring if the server hasn't quite caught up. Their suggested approach is to use a "fuse wire": build in a brief delay (like an animation) before the critical action, giving client and server time to synchronise. By the time the explosion actually happens, everyone's in sync and there are no visible rollbacks.
Migrating Existing Games
I tested this with our bowling game, The Lanes, which previously relied on SetNetworkOwner to give the active player control over pins and balls. The migration involved moving that shared physics logic into a common module and deleting the SetNetworkOwner calls — which simply error under Server Authority, since the server is always the owner now.
The physics worked well, though I did notice a brief jerk when the ball left the player's hand as client and server initially synchronised. That's something to design around, and it's worth noting this was in a local Studio test with zero network latency — real-world conditions would amplify it. The community guide to Server Authority is a great starting point if you're looking to migrate.
Why This Matters Beyond Anti-Cheat
Fedor made a really compelling point on the episode: for years, developers have had to design around the assumption that cheating will happen. Shared economies, competitive leaderboards, and interlinked progression systems have often been off the table because one exploiter could ruin the experience for everyone. Server Authority opens the door to game designs that simply weren't practical before.
There's also a broader vision here. Roblox has hinted at what they've internally called "AuroraScript" — likely to ship as BehaviorScript — which would eliminate the client-server script divide entirely. Instead of writing separate client and server code connected by remote events, you'd write a single behaviour definition and Roblox would handle the rest. We're not there yet, but Server Authority is clearly a stepping stone towards that future.
The Bottom Line
Server Authority is still a Studio beta — it can't be published to live experiences yet, and the API may change. But even in its current state, it's impressive. The anti-cheat benefits are immediate, the developer experience is simpler than the old SetNetworkOwner paradigm, and every improvement Roblox makes to prediction and rollback smoothness will benefit everyone using the system automatically.
If you're building anything competitive or physics-heavy, now is the time to start experimenting.
Sources: