Roblox games live in the cloud by default. Studio saves your places, assets, and scripts to Roblox, and Version History tracks changes to each place. Many teams also want their game in a version control system like Git so they can review changes before they land, keep a full history, and automate builds and deploys.
Every version control workflow for Roblox answers one question: where does the source of truth live for each part of your game? The three common answers are:
- Studio-native: The place on Roblox is the source of truth for everything. Script Sync copies scripts into Git so you can review and track them.
- Partially managed: Git is the source of truth for code. The place on Roblox is the source of truth for everything else, like models, terrain, and UI.
- Fully managed: Git is the source of truth for the entire game. Places on Roblox are build output that CI publishes from the repository.
This page compares these workflows, describes the tools each one uses, and covers the environments that teams set up around them. To set up a workflow, see Set up a workflow.
Third-party tools on this page are not maintained by Roblox and can change or stop working at any time. For full reference, see each tool's own documentation.
Roadmap for file-based workflows
Roblox is working toward first-party, file-based workflows so that teams can use version control without assembling third-party tools. Until those workflows ship, the setups on this page reflect what works for teams today.
Workflow comparison
Studio-native
Partially managed
Fully managed
| Studio-native | Partially managed | Fully managed | |
|---|---|---|---|
| Good fit for | Teams of fewer than five creators working on a single-place game | Teams with several programmers, and multi-place games | Teams that require review and history for every instance and asset |
| In version control | Scripts | Scripts, project configuration, and tooling | Everything, including models and images |
| Content editing | Team Create | Team Create and packages | Files in Git, built by CI |
| Tools to maintain | None beyond Studio and an editor | Rojo plus linting and CI tools | Rojo, merge and asset tools, and a full CI pipeline |
Choose a workflow
Start with the simplest workflow that meets your needs. You can move to a more managed workflow later, because none of these tools lock you in. Most teams don't need fully managed Rojo, and it adds significant complexity.
Tools
Most setups combine a few tools from Roblox with a few from the community.
Roblox tools
| Tool | What it does | Used in |
|---|---|---|
| Team Create | Real-time collaborative editing in Studio, best suited to building, level design, and art. | All workflows |
| Script Sync | Syncs scripts in Studio with files on your local disk, in both directions. | Studio-native |
| Packages | Reusable, versioned groups of instances that you can update across places and games. | Studio-native, partially managed |
| Version History | Saved versions of each place that you can view, compare, and restore. | All workflows |
| Place publishing API | Open Cloud API that publishes a place file to Roblox. Use it to deploy from CI. | Partially managed, fully managed |
| Luau execution API | Open Cloud API that runs Luau in a place on Roblox servers. Use it to run tests from CI. | Partially managed, fully managed |
| Assets API | Open Cloud API that uploads and updates assets like images, audio, and models. | Fully managed |
Community tools
| Tool | What it does | Used in |
|---|---|---|
| Rojo | Syncs files on disk into Studio through a local server and Studio plugin, and builds place and model files from a project file. The rojo syncback command, in Rojo 7.7 and later, converts an existing place into project files. | Partially managed, fully managed |
| Rokit | Toolchain manager. Pins tool versions so everyone on the team uses the same ones. | Partially managed, fully managed |
| Wally | Package manager for community Luau libraries. | Partially managed, fully managed |
| Lune | Standalone Luau runtime, commonly used for build, deploy, and automation scripts. | Partially managed, fully managed |
| selene | Luau linter. | All workflows |
| StyLua | Luau code formatter. | All workflows |
| Luau Language Server | Autocompletion and type checking in external editors. | All workflows |
| Tarmac | Uploads images from disk to Roblox and generates a module that maps file paths to asset IDs. | Fully managed |
| rbx-merge | Git diff and merge driver for .rbxl, .rbxlx, .rbxm, and .rbxmx files. Shows readable diffs and merges non-conflicting changes at the property level. | Fully managed |
To install and run Rojo, see Rojo. For Rokit, Wally, linters, and other tools, see Third-party tools.
Environments
Teams that use version control usually also separate their work into environments, so that unfinished changes never reach players. Instead of one place that everyone edits, each environment is its own place.
We recommend creating each environment as a separate game under the same group, rather than as separate places within one game. Data stores, secrets, and other cloud services are scoped to the game, so separate games keep test data out of production.
A typical setup has these environments:
| Environment | Purpose | Who updates it |
|---|---|---|
| Personal dev | Each creator's own copy of the dev place for day-to-day work. | That creator |
| Shared dev | The combined, unstable set of features that the team is working on. | Programmers sync reviewed code, and artists copy in approved content. |
| Assets | The canonical versions of packages, like characters, building kits, and set dressing. | Artists |
| Stable | A snapshot of shared dev at a regular interval, such as for weekly playtests. | CI only |
| Production | The live, public game. | Copied from stable after release approval |
Create a personal dev place
- Open the shared dev place in Studio.
- Select File ⟩ Publish As.
- Select the group that owns your dev games.
- Publish the place as a new game with a name that identifies you and the project, like USER / YourName - ProjectName.
- Close the shared dev place and open your new personal copy.
Use consistent names for every environment, such as DEV - ProjectName, ASSET / ProjectName, and STABLE / ProjectName, so that the team can tell them apart on the Creator Dashboard.
Set up a workflow
| Workflow | Setup guide |
|---|---|
| Studio-native | Use Script Sync with a team |
| Partially managed | Partially managed Rojo |
| Fully managed | Fully managed Rojo |
Troubleshoot common problems
| Problem | Fix |
|---|---|
| Testing in a dev place changes production data. | Dev and production are places in the same game, so they share data stores. Move each environment into its own game. |
| Teammates overwrite each other's script changes. | Two people are syncing the same scripts into one Team Create session. Sync code into personal dev places and merge through Git. |
| A fix to one copy of a script doesn't apply to the others. | Copying a script creates an independent copy. Put shared behavior in a ModuleScript and attach it to instances with CollectionService tags. |
| Server-only code is visible to clients. | Modules in containers that replicate to clients, like ReplicatedStorage, are sent to clients. Keep server-only modules in ServerScriptService or ServerStorage. |