---
title: "Compare file-based workflows"
url: /docs/en-us/projects/file-based-workflows
last_updated: 2026-11-11T22:23:24Z
description: "Compare real-world setups for using Git with Roblox games, from Script Sync to fully managed Rojo, and set up the one that fits your team."
---

# Compare file-based workflows

Roblox games live in the cloud by default. Studio saves your places, assets, and scripts to Roblox, and [Version History](/docs/en-us/projects/version-history.md) tracks changes to each place. Many teams also want their game in a **version control** system like [Git](https://git-scm.com/) 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](#set-up-a-workflow).

> **Info:** 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

```mermaid
flowchart TB
    A["<b>Git repository</b><br/>Copy of scripts"]
    B["<b>Place on Roblox</b><br/>Scripts, models, terrain, and UI<br/><i>Source of truth</i>"]
    A <-->|Script Sync| B
    classDef sot fill:#E8EEFF,stroke:#335FFF,stroke-width:2px,color:#1F2328
    classDef plain fill:#F2F4F5,stroke:#C9CDD2,color:#1F2328
    class B sot
    class A plain
```

#### Partially managed

```mermaid
flowchart TB
    A["<b>Git repository</b><br/>Scripts, config, and tooling<br/><i>Source of truth for code</i>"]
    B["<b>Place on Roblox</b><br/>Models, terrain, and UI<br/><i>Source of truth for content</i>"]
    A -->|Rojo| B
    classDef sot fill:#E8EEFF,stroke:#335FFF,stroke-width:2px,color:#1F2328
    classDef plain fill:#F2F4F5,stroke:#C9CDD2,color:#1F2328
    class A,B sot
```

#### Fully managed

```mermaid
flowchart TB
    A["<b>Git repository</b><br/>Scripts, models, images, and config<br/><i>Source of truth</i>"]
    B["<b>Place on Roblox</b><br/>Built and published from Git"]
    A -->|CI publishes| B
    classDef sot fill:#E8EEFF,stroke:#335FFF,stroke-width:2px,color:#1F2328
    classDef plain fill:#F2F4F5,stroke:#C9CDD2,color:#1F2328
    class A sot
    class B plain
```

|  | 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.

```mermaid
flowchart TD
    Q1{"Do you need review and history<br/>for models and other content,<br/>not just code?"}
    Q2{"Does your game have<br/>multiple places, or five<br/>or more creators?"}
    A1["Fully managed Rojo"]
    A2["Partially managed Rojo"]
    A3["Studio-native workflow"]

    Q1 -->|Yes| A1
    Q1 -->|No| Q2
    Q2 -->|Yes| A2
    Q2 -->|No| A3

    classDef answer fill:#E6F4EA,stroke:#1E7F3E,stroke-width:2px,color:#1F2328
    classDef question fill:#F2F4F5,stroke:#C9CDD2,color:#1F2328
    class A1,A2,A3 answer
    class Q1,Q2 question
```

## 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](/docs/en-us/projects/collaboration.md) | Real-time collaborative editing in Studio, best suited to building, level design, and art. | All workflows |
| [Script Sync](/docs/en-us/scripting/sync.md) | Syncs scripts in Studio with files on your local disk, in both directions. | Studio-native |
| [Packages](/docs/en-us/projects/assets/packages.md) | Reusable, versioned groups of instances that you can update across places and games. | Studio-native, partially managed |
| [Version History](/docs/en-us/projects/version-history.md) | Saved versions of each place that you can view, compare, and restore. | All workflows |
| [Place publishing API](/docs/en-us/cloud/guides/usage-place-publishing.md) | Open Cloud API that publishes a place file to Roblox. Use it to deploy from CI. | Partially managed, fully managed |
| [Luau execution API](/docs/en-us/cloud/reference/LuauExecutionSessionTask.md) | 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](/docs/en-us/cloud/guides/usage-assets.md) | Open Cloud API that uploads and updates assets like images, audio, and models. | Fully managed |

### Community tools

| Tool | What it does | Used in |
| --- | --- | --- |
| [Rojo](https://rojo.space/) | 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](https://github.com/rojo-rbx/rokit) | Toolchain manager. Pins tool versions so everyone on the team uses the same ones. | Partially managed, fully managed |
| [Wally](https://wally.run/) | Package manager for community Luau libraries. | Partially managed, fully managed |
| [Lune](https://github.com/lune-org/lune) | Standalone Luau runtime, commonly used for build, deploy, and automation scripts. | Partially managed, fully managed |
| [selene](https://github.com/Kampfkarren/selene) | Luau linter. | All workflows |
| [StyLua](https://github.com/JohnnyMorganz/StyLua) | Luau code formatter. | All workflows |
| [Luau Language Server](https://github.com/JohnnyMorganz/luau-lsp) | Autocompletion and type checking in external editors. | All workflows |
| [Tarmac](https://github.com/Roblox/tarmac) | Uploads images from disk to Roblox and generates a module that maps file paths to asset IDs. | Fully managed |
| [rbx-merge](https://github.com/kennethloeffler/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](/docs/en-us/projects/rojo.md). For Rokit, Wally, linters, and other tools, see [Third-party tools](/docs/en-us/projects/external-tools.md).

## 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](/docs/en-us/projects/groups.md), 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 |

```mermaid
flowchart LR
    PA["<b>Personal dev</b><br/>Creator A"]
    PB["<b>Personal dev</b><br/>Creator B"]
    AS["<b>Assets</b><br/>Packages"]
    SD["<b>Shared dev</b><br/>Work in progress"]
    ST["<b>Stable</b><br/>Playtests"]
    PR["<b>Production</b><br/>Live game"]

    PA -->|Reviewed code| SD
    PB -->|Reviewed code| SD
    AS -->|Package updates| SD
    SD -->|CI snapshot| ST
    ST -->|Release approval| PR

    classDef env fill:#F2F4F5,stroke:#C9CDD2,color:#1F2328
    classDef shared fill:#E8EEFF,stroke:#335FFF,stroke-width:2px,color:#1F2328
    classDef live fill:#E6F4EA,stroke:#1E7F3E,stroke-width:2px,color:#1F2328
    class PA,PB,AS,ST env
    class SD shared
    class PR live
```

### Create a personal dev place

1. Open the shared dev place in Studio.
2. Select **File** ⟩ **Publish As**.
3. Select the group that owns your dev games.
4. Publish the place as a new game with a name that identifies you and the project, like `USER / YourName - ProjectName`.
5. 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](/docs/en-us/scripting/sync.md#use-script-sync-with-a-team) |
| Partially managed | [Partially managed Rojo](/docs/en-us/projects/rojo/partially-managed.md) |
| Fully managed | [Fully managed Rojo](/docs/en-us/projects/rojo/fully-managed.md) |

## 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 `Class.ModuleScript` and attach it to instances with `Class.CollectionService` tags. |
| Server-only code is visible to clients. | Modules in containers that replicate to clients, like `Class.ReplicatedStorage`, are sent to clients. Keep server-only modules in `Class.ServerScriptService` or `Class.ServerStorage`. |