tl;dr
- We are launching Server Authority with Latency Compensation Studio Beta today. Our new APIs are finalized and will not change significantly before its final release.
- To try this out, go to Studio and enroll in the Server Authority Core API via the Beta Features Menu, then enable five specific Workspace settings:
- first enable NextGenerationReplication, UseFixedSimulation, StreamingEnabled, PlayerScriptsUseInput,
- set SignalBehavior to Deferred,
- and last set AuthorityMode to Server
- Documentation and template projects to align with these latest changes are here
- Important known issues (more below)
Studio Only: As a Studio Beta, these changes will only be visible during local play sessions in Studio and should not be published to live experiences
- Please let us know about bugs and feedback here as comments to this post
Hi creators,
Today, weâre excited to launch Server Authority into Studio Beta, making it available for all creators to explore. This powerful networking model is designed to help you build the next generation of fair, responsive, and cheat-resistant competitive games on Roblox.
A Studio Beta means that you can feel confident that the structure of Server Authority is ready for you to build upon without major changes in the future. By opting into this Studio Beta, you can develop new games or add Server Authority support to existing ones, so they will be ready as soon as Server Authority becomes generally available
Stop Cheaters, Not Gameplay
Weâve heard from you that building competitive games like first-person shooters, sports, or racers is challenging when cheaters can exploit their client to fly, speed hack, or otherwise ruin the player experience. This forces you to spend valuable time creating complex anti-cheat solutions instead of focusing on what matters most: making great games. Additionally, the current model distributes the simulation across the server and the clients, which can cause certain interactions between different network owners (e.g. collisions between cars controlled by different players) to look less realistic.
Server Authority solves both problems by making the server the ultimate source of truth for your gameâs state. This fundamentally prevents entire classes of client-side exploits because the server validates player actions and rejects anything that breaks the rules, and it creates a single, consistent simulation on the server and thus avoids distribution-related artifacts.
You could already set your gameâs network authority to server before this release, but this naĂŻve implementation would make gameplay feel sluggish because of the additional latency between client and server. To fix this, we are introducing support for client-side prediction as well as rollback and resimulation for mispredictions.
How it Works
With Server Authority, the core game simulation runs entirely on the server; clients forward player inputs to the server and the server sends state updates back to the client. The server acts as a single source of truth: if the clientâs state differs from the serverâs, the serverâs updates overwrite it.
To mask the latency between the client and the server, the client additionally tries to predict the updates the server is going to send. To that end, the client runs the simulation a few frames ahead of the server, so that the inputs it sends will still reach the server in the correct frame, even though they experience some network delay.
Additionally, the client remembers the earlier states of predicted instances, at least for a few frames. Because of this, it can tell when the serverâs updates for a given frame are different from its own state in that frame. When that happens, a misprediction has occurred. To correct it, the client automatically rolls back its predicted instances to the last agreed upon state/frame, then applies the serverâs update, and finally resimulates the corresponding frames to make a new prediction. The result is the âbest of both worldsâ: the serverâs authority overrides any client-side cheats, but the game still feels as responsive as if the simulation were running locally.
Mispredictions cause extra work for the client and can sometimes cause small visual artifacts when the corrected prediction is significantly different. Because of this, it is important for the server and the clients to keep their state in sync as much as possible. Since the clientâs frame rate is variable, any scripts that depend on it can cause the clientâs state to diverge from the serverâs. Thus, a key element of the new API is a new callback that runs at a consistent rate on both the clients and the server.
Whatâs New Since Early Access
First, a huge thank you to all our Early Access users. Your feedback on Server Authority has been incredibly helpful as weâve worked to improve prediction accuracy, fix bugs, and refine the API.
Based on your feedback, weâve made several key improvements for this Studio Beta release:
- New Simulation API: We have introduced
RunService:BindToSimulationto replaceFixedHeartbeat, providing a more robust way to handle fixed-frequency simulation steps. Additionally,BindToSimulationautomatically restricts property writes to a subset that is safe to use with Server Authority. - Flexible Attributes: You can now add, remove, or change the type of an Attribute at runtime, giving you more flexibility in managing game state.
- Higher Frame Rate Support: Experiences running at frame rates above 60 FPS are now fully supported.
- Improved Physics: Weâve increased prediction accuracy for basic physics movement, reducing mispredictions and smoothing out gameplay.
How to Enable Server Authority
You can enable Server Authority in your experience by following these steps:
- Enable the Beta: Go to File > Beta Features in Studio and check the Server Authority Core API box.
- Configure Workspace: Select Workspace in the Explorer and set the following properties in the Properties window:
NextGenerationReplication: Enabled (Note: This significantly changes Roblox Networking/Synchronization behavior)UseFixedSimulation: EnabledStreamingEnabled: EnabledPlayerScriptsUseInputActionSystem: EnabledSignalBehavior: Deferred
- Activate Authority: Finally, set the Workspace property
AuthorityModeto Server, which sets default character movement to be server authoritative.
Getting Started
Check out our Server Authority documentation here for in depth details on how to get started, best practices, and advanced techniques.
At the highest level, the API we are releasing is meant as a first step: it supports Server Authority, but it does not yet have a lot of convenience features or knobs for customization. The best way to adopt it is to use the following pattern in your game logic:
- Use shared code: Put your core game logic in a ModuleScript in
ReplicatedStorage. Connect your update loop toRunService:BindToSimulationon both the client and the server to keep them in sync. - Handle input: Use
InputActionfor all player inputs (like movement or abilities) that affect the core game simulation. These are forwarded to the server, and they are the only client data that the server trusts. - Use attributes for game state: Game state, such as health or ammo, should be stored in Attributes on predicted Instances. This will ensure that this state is rolled back when there has been a misprediction. Luau variables by themselves are not rolled back, so make sure you use Attributes for synchronized game data
Example Places
In addition to the documentation, we are providing multiple example games to help you get started:
Known Issues and Limitations
This is a beta, and we are actively working on improvements. Please keep the following in mind :
(Click to expand)
- Animations: Animations currently do not re-play during correction and resimulation, and this may lead to further mispredictions.
- Avatar Prediction: The above issue causes avatars that are colliding with animated parts to mispredict during resimulation.
- Attribute Limits: Instances can only have up to 64 attributes, with limited size string support. Server authority requires efficient synchronization and minimizing instance payload sizes.
- Enum Attribute Prediction: You will see an error when trying to predict an enum attribute. This will be fixed in the next release.
- Instance Creation: New Instances must currently be created on the server. Wrap creation logic in an
if RunService:IsServer() then ... end block. - Nil Instance Prediction: There will be a crash if you call
RunService:SetPredictionModeon anilInstance. This will be fixed in a few days by a patched version. - Studio Only: As a Studio Beta, these changes will only be visible during local play sessions in Studio and should not be published to live experiences.
- Some Logic Not Yet Server Authoritative: There are still a few points where clients retain authority for instance, Seat/Vehicle Seat logic still uses client-authoritative remote events, and tool equipping is still handled using client-authoritative âWeldingâ. Proximity Prompts, Click Detectors, and Drag Detectors are also only client authoritative at the moment. These issues will be fixed during the Beta.
- Not Fully Optimized: The replication architecture powering the server-side of Server Authority has not been fully optimized yet. On the Client, the validation and resimulation logic has not undergone optimization yet.
- Incompatible with Team Create + Team Test: Team Create and Team Test are unavailable if you are using Server Authorityâs Studio Beta; however they will work if youâre using using Early Access. We are currently evaluating whether we can support them during Studio Beta.
- BasePart.Touched and InputAction.StateChanged Signals can be Inaccurate: When a clientâs simulation is rolled back to an authoritative server state, BasePartâs
TouchedandTouchEndedevents can be fired if a BasePart is rolled back to a touching or not touching state. These signals will inaccurately fire on the client when they might not have fired on that frame on the server. You should useGetTouchingParts()andInputAction:GetState()instead.
Why You Should Start Experimenting Now
Server Authority is a foundational change. By testing it in Studio Beta, you can get a head start on adapting your existing experiences or planning new ones. Branching your code now and learning the APIs means youâll be ready to ship as soon as Server Authority is live.
Whatâs Next
Our goal is to generally release Server Authority early in 2026 once weâve optimized performance and reduced misprediction rates further.
Please share your questions, feedback, and what youâre building in the comments below!
Thank you,
The Server Authority Team
FAQ
-
Where do I report bugs or feature requests?
- Please report feedback here as comments to this thread! Rest assured: we are looking at each post. If youâre in the Early Access program, you can also give us feedback there!
-
Will enabling this beta feature in Studio publish Server Authority to my live experience?
- No. This is a Studio-only beta. The changes will only be effective during your local play sessions in Studio and will not affect your players.
-
Do I have to rewrite my entire game to use Server Authority?
- Not necessarily. For experiences that use default avatars and simple physics, you can see benefits just by enabling
Workspace.AuthorityMode. Complex custom gameplay will require adapting scripts to useBindToSimulationandInputAction.
- Not necessarily. For experiences that use default avatars and simple physics, you can see benefits just by enabling
-
Is there a performance cost?
- Yes, both the server and the clients have to do more work when Server Authority is enabled: the server now has to perform all the simulation that the client was doing originally, and the client has to handle prediction and resimulation. We will continue optimizing performance on a range of devices before and after we formally ship Server Authority to General Availability. In other words: yes expect higher server costs but know what weâll constantly be working to optimize.
-
How is this different from the old âSetNetworkOwnerâ system?
- While both involve the server, Server Authority is a complete networking and simulation model, not just a way to assign physics control. It integrates client-side prediction, rollback, and resimulation to make gameplay feel responsive despite server control. It also provides first-class APIs like
BindToSimulationandInputActionto build your entire game loop within this model, which is far more robust than manually managing network ownership.
- While both involve the server, Server Authority is a complete networking and simulation model, not just a way to assign physics control. It integrates client-side prediction, rollback, and resimulation to make gameplay feel responsive despite server control. It also provides first-class APIs like
-
Why is Instance Streaming required?
- Server Authority depends on the client simulating only what it actually has locally, and Streaming is what provides that safe, onâdemand subset of the world. With Streaming, the client loads nearby/needed content first, so gameplay stays responsive while the server remains the source of truth. If the client ever âguessesâ wrong (for example, an object hasnât arrived yet), Server Authority simply rolls back and corrects the prediction when the authoritative data streams in, avoiding hard desyncs. Streaming also speeds up join time and reduces memory, which lets more players on more devices run larger, richer worlds. Without Streaming, weâd either have to replicate everything up front (slow, memoryâheavy) or accept inconsistency when missing data is referenced. In short: Streaming is one important way we keep Server Authority fast, scalable, and correct for players.
-
Whatâs happening to Early Access?
- The Studio Beta and the Early Access Program will continue in parallel. Members of the Early Access Program will be able to test server-authoritative experiences on clients and will have quicker access to the latest features, and they will be able to test their games with others in Early Access via Studioâs Team Test or live. If you would like to join the program, you can still submit a request here.
-
Can I be in the Studio Beta AND Early Access simultaneously?
- Yes, but youâll only see the Early Access version of Server Authority as it takes precedence over Studio Beta. If you want to see the Studio Beta version of Server Authority only, youâll need to turn off Early Access in your Roblox account settings.
-
What is a Studio Beta? How is it different from Early Access?
- Studio Beta provides the most stable version of Server Authority. Any changes made to the Studio Beta version will have met the standard bar of Roblox quality and will not compromise the user experience of Studio. In addition, updates introduced to the Studio Beta version are expected to carry forward to the General Availability release with minimal modification.
- Early Access gives Creators exposure to the latest set of changes Roblox makes to Server Authority. That said, these updates are subject to change before they appear in the Studio Beta version. In addition, although we do test our updates prior to releasing, validation of the Early Access versions are not as thorough as Studio Beta. Early Access also allows others ALSO enrolled in Early Access to play your published game or to join a Team Test session via Studio.
-
Where can I learn more about Server Authority?
