Script vs LocalScript vs ModuleScript: Which One and Where?

Last updated: October 20, 2026

Quick answer: Use a Script for game logic the server must own (damage, coins, saving), a LocalScript for what one player sees and controls (input, camera, UI), and a ModuleScript to share code between them via require() — and remember that a LocalScript in Workspace or ReplicatedStorage silently never runs.

Use a Script for game logic that must be trusted, a LocalScript for anything a single player sees or controls, and a ModuleScript whenever code needs to be shared. Scripts run on the server and affect everyone, LocalScripts run on one player's device and affect only that player, and ModuleScripts run nowhere on their own — they execute only when another script calls require() on them. Picking the wrong one usually produces no error at all: the code simply never runs.

What is the difference between Script, LocalScript, and ModuleScript?

The three script types differ on exactly three axes: where they run, when they start, and whose game they affect.

A Script is the only type whose changes are authoritative: if the server sets a player's coins, that value replicates to every client and is what gets saved. A LocalScript is perfect for reading keyboard input, moving the camera, or animating a menu — but anything it changes stays on that one machine. A ModuleScript is not a "third runtime" at all; it is a packaged chunk of code with a return value, like a function library.

Why does a LocalScript in Workspace or ReplicatedStorage silently do nothing?

Because a LocalScript only starts inside containers the client actually owns. With the default RunContext, those are:

• StarterPlayer.StarterPlayerScripts and StarterPlayer.StarterCharacterScripts (copied to the player on join/spawn)
• PlayerScripts, PlayerGui, Backpack, and the player's character model (after the copies land there)
• StarterGui and StarterPack, which are really just sources for the copies above

Workspace, ReplicatedStorage, ServerScriptService, and ServerStorage are NOT in that list. A LocalScript sitting in Workspace produces no error, no warning, and no output — its Running property just stays false forever. This is the single most common beginner trap in Roblox, and it looks identical to "my code is broken" even when the code is perfect.

Two side effects catch people out as well. First, a LocalScript cloned into PlayerGui at runtime does start, but a LocalScript cloned into Workspace at runtime still does not. Second, what you see in Studio's Explorer while testing is the server's view mixed with your client's view — a LocalScript that "exists" in Workspace is real, it is just permanently asleep.

Why should damage, coins, and saving live in a server Script?

Because the client is not trustworthy. Any player can run arbitrary client-side code, edit values in their own copy of the game, and fire remote events with whatever arguments they like. If a LocalScript decides "this hit dealt 500 damage" or "this player has 1 million coins", an exploiter simply says the same thing louder.

The robust split looks like this:

• The client observes and requests: "I pressed the attack button", "I clicked this shop item".
• The server validates and decides: was the target in range, is the ability off cooldown, does the player actually have the coins.

Clients talk to that authoritative server through RemoteEvents, and the server clamps and checks every incoming argument before it changes real state. The same rule covers persistence: coin totals that matter must be written by the server, since a client-reported balance is trivially forged. If you are brand new to scripting altogether, start with Roblox scripting for beginners and come back to the type table once your first Script runs.

How does a ModuleScript work with require()?

Calling require() on a ModuleScript executes its body exactly once per environment and returns the single value the module returns — usually a table of functions.

-- ReplicatedStorage/InventoryUtil (ModuleScript)
local InventoryUtil = {}

function InventoryUtil.totalWeight(items)
	local total = 0
	for _, item in items do
		total += item.weight
	end
	return total
end

return InventoryUtil

-- a Script or LocalScript that wants to use it
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local InventoryUtil = require(ReplicatedStorage:WaitForChild("InventoryUtil"))

print(InventoryUtil.totalWeight({ { weight = 3 }, { weight = 7 } })) -- 10

Three rules make modules predictable:

1. One return value. Return a table (or a function); everything else in the file is local to the module. A module with no return statement gives you nil.
2. Run once, then cached. The first require() runs the body; later require() calls return the same table instantly. That means module-level variables behave like singletons — a counter at the top of a module is shared by everything on that side that requires it.
3. Caching is per side. The server has one cached copy and each client has its own. Server and client requiring the same module get two independent tables, never one shared state.

That third rule is what answers "can a Script and a LocalScript share a module?" — they can share the code, and they should for constants and validation helpers, but they cannot share mutable state through it. If the server increments a module counter and a LocalScript reads its own copy, the LocalScript sees its own number and nothing else. For the deeper patterns (frozen config tables, class-style modules with setmetatable), see the ModuleScripts guide.

What does RunContext change?

Every Script and LocalScript has a RunContext property that overrides the legacy placement rules:

• Legacy (the default) — placement decides everything: Scripts run on the server wherever they are, LocalScripts only in the client containers listed above.
• Server — always runs on the server, even sitting inside Workspace or ReplicatedStorage.
• Client — runs on the client wherever it is, including Workspace and ReplicatedStorage.

RunContext is why old advice and new behaviour sometimes clash. A Script with RunContext set to Client in Workspace is the modern replacement for "a LocalScript that should run no matter where it is cloned", and it is the right tool for effects that are cloned into the world at runtime. The classic guidance still holds for almost every project: put server code in ServerScriptService, put player code under StarterPlayer, and only touch RunContext when placement genuinely cannot express what you need.

Which script type should I use?

Walk this decision tree in order:

• Does it change the game for everyone — damage, currency, spawning, saving? A Script on the server.
• Does it read one player's input, camera, or UI, or draw client-only effects? A LocalScript under StarterPlayer or the relevant GUI.
• Is the logic needed in more than one place (two scripts, or server and client)? A ModuleScript in ReplicatedStorage, required from both sides.
• Is it a server-only helper (DataStore wrappers, admin checks)? A ModuleScript in ServerScriptService, required only by server Scripts.
• Is it pure data — item prices, level tables, balance config? A ModuleScript that returns a frozen table, placed in ReplicatedStorage if clients need it too.

When in doubt, default to the server. You can always move pure-presentation code to a LocalScript later; migrating trusted logic away from the client later means rewriting the security model.

Common mistakes

• A LocalScript in Workspace, ReplicatedStorage, or ServerScriptService. It never runs and never complains. Move it to StarterPlayerScripts, PlayerGui, or the character.
• A Script in PlayerScripts expecting per-player behaviour. It runs once, on the server — it is not "a LocalScript with extra steps".
• Expecting one shared module table across the server and clients. require() caches per side; use RemoteEvents when both sides must agree on a value.
• A ModuleScript that "does nothing". Nothing requires it, so its body never executes. Modules are libraries, not entry points.
• Circular requires (module A requires B while B requires A) — one of them gets a half-initialized table or errors. Break the cycle with a lazy require inside a function.
• Legacy timing calls in long-running scripts. The old wait(), spawn(), and delay() globals are deprecated and imprecise; use task.wait(), task.spawn(), and task.delay(), which run on the modern scheduler.

Learn Luau by doing

Choosing the right script type becomes instinct only after you have misplaced one and watched it do nothing. On Luablox you can practise Luau interactively through /theory, drill the tricky bits on /problems, and follow structured Luablox lessons that build from your first Script to full server-authoritative gameplay systems.

Learn how to share code and architect clean, modular Roblox systems using ModuleScripts and require().