--- title: "Script types and locations" url: /docs/en-us/scripting/locations last_updated: 2026-06-17T23:57:56Z description: "How scripts run in Roblox, and how location impacts that behavior." --- # Script types and locations For many developers, the fundamental challenge of adapting to Roblox scripting is the importance of file location and the `Class.Script.RunContext` property. Depending on script type, location in the **Explorer**, and run context, scripts can behave very differently. Certain method calls might fail, objects in your game might be inaccessible, or scripts might not run at all. The reason for this complexity is that Roblox games are multiplayer by default. Scripts need the ability to only run on the server, only run on the client, or be shared across both. The evolution of the Roblox platform over time has further complicated the situation. ## Script types Roblox has three types of scripts: - `Class.Script` - Code that runs on either the server or the client, depending on its location and `Class.Script.RunContext` property. - `Class.LocalScript` - Code that runs only on the client. Does not have a run context. - `Class.ModuleScript` - Code that you can reuse in other scripts. Does not have a run context. When you create a `Class.Script`, its default run context is `Legacy`, meaning that it a) is a server-side script and b) only runs if it is in a server container, such as `Class.Workspace` or `Class.ServerScriptService`. - If you change the script's run context to `Server`, it can now also run in `Class.ReplicatedStorage`, but that's not recommended. The contents of that location are replicated to clients, so it's a poor location for server-side scripts. - If you change the script's run context to `Client`, it can run in `ReplicatedStorage`. It can also run in `Class.StarterCharacterScripts` and `Class.StarterPlayerScripts`. Starter containers are copied to clients, though, so the original script **and** the copy run, which isn't desirable. To change a script run context, select it in the [Explorer](/docs/en-us/studio/explorer.md) and change the value in the [Properties](/docs/en-us/studio/properties.md) window. ![RunContext property indicated for a Script.](../assets/studio/properties/Script-RunContext.png) ### Recommendations - Put client scripts into `Class.ReplicatedStorage` with a `RunContext` of `Client` alongside client-only `Class.ModuleScript|ModuleScripts`. When debugging in Studio, you can click lines in the **Output** window and go to `ReplicatedStorage.YourScript` (the stable location of the script) rather than `Players.YourName.PlayerScripts.YourScript` (the ephemeral location that the script was copied to at runtime). - Put server scripts into `Class.ServerScriptService` with a `RunContext` of `Server` alongside server-only `Class.ModuleScript|ModuleScripts`. - To share code between server and client scripts, use `Class.ModuleScript|ModuleScripts` in `ReplicatedStorage`. > **Success:** To stay organized, many creators write the vast majority of their code in `Class.ModuleScript|ModuleScripts` and `Global.LuaGlobals.require()` all of them in exactly one server script and one client script. - If you place scripts within [models](/docs/en-us/parts/models.md) and [packages](/docs/en-us/projects/assets/packages.md), specify a `RunContext` for each script to remove ambiguity from how it runs. Explicitly setting this property makes models and packages more likely to work properly from a variety of locations. - Put the minimal number of client scripts (such as a loading script) into `Class.ReplicatedFirst` with a `RunContext` of `Client`. To learn more, see [Replication order](/docs/en-us/scripting/attributes.md#replication-order). - Use `Class.LocalScript|LocalScripts` in `StarterCharacterScripts`, `StarterPlayerScripts`, `StarterGui`, and `StarterPack`. ## Script locations | Location | Description | | --- | --- | | `Class.Workspace` | Represents the experience's 3D world. This location works well for server scripts that attach directly to objects and control their behavior. | | `Class.ReplicatedFirst` | Contains objects that replicate to the client before anything else. This location is ideal for the absolute minimum set of objects and client scripts necessary to display a loading screen. | | `Class.ReplicatedStorage` | Contains objects that are replicated to both the client and the server. This location is ideal for `Class.ModuleScript\|ModuleScripts` that you want to use on both the server and the client. `Class.LocalScript\|LocalScripts` do not run from this location, but `Class.Script\|Scripts` with a `Class.BaseScript.RunContext\|RunContext` of `Enum.RunContext\|Client` do. | | `Class.ServerScriptService` | Contains server scripts. This location is ideal for scripts that need to access server-side functionality or objects, such as game logic and cloud storage. | | `Class.ServerStorage` | Contains server-side objects. This location is ideal for large objects that don't need to be immediately replicated to clients when they join an experience. Scripts do not run from this location, but you can store server-side `Class.ModuleScript\|ModuleScripts` here. | | `Class.StarterPlayer` ⟩ `Class.StarterCharacterScripts` | Contains `Class.LocalScript\|LocalScripts` that run when the character spawns. | | `Class.StarterPlayer` ⟩ `Class.StarterPlayerScripts` | Contains general-purpose `Class.LocalScript\|LocalScripts` that run when the player joins the experience. | | `Class.StarterGui` | Contains GUI elements that the client displays when it loads the experience. `Class.LocalScript\|LocalScripts` can run from this location. This location is ideal for scripts that modify the experience's user interface, such as adding buttons, menus, and pop-ups. | | `Class.StarterPack` | Generally only contains `Class.Tool\|Tools`, but can also include `Class.LocalScript\|LocalScripts` for setting up player backpacks. | This image shows which **Explorer** window locations can contain client scripts. Remember, `ReplicatedFirst` and `ReplicatedStorage` can contain `Class.Script|Scripts` with a `Class.BaseScript.RunContext|RunContext` of `Enum.RunContext|Client`, whereas the `Starter[]` containers should use `Class.LocalScript|LocalScripts`. ![Diagram showing which script locations run on clients.](../assets/scripting/client-server/Client-Script-Containers.png) ## Example project structure The [Plant](/docs/en-us/resources/plant-reference-project.md) reference project shows how you might organize your code in a large, complex game. Of particular note is how it stores the vast majority of its code as reusable `Class.ModuleScript|ModuleScripts` in `ReplicatedStorage` and `ServerStorage`.