garrysmod: the public half of Garry's Mod is a Lua repository, not the engine

Only the script and content layer is public

The scope of this repository is stated in its first line of substance: it consists of all Lua, text and config extensions for Garry's Mod. Everything else is missing on purpose. The README says binary sources are not public, and that they are derived from the Source SDK 2013 repository.

That single fact determines what this repository can and cannot do for you. You cannot build the game from it, you cannot read the engine code, and you cannot change the renderer, the physics or the networking stack. What you can do is read and change the layer that sits on top: the Lua scripts, the text resources and the configuration that make Garry's Mod a sandbox rather than a plain Source game.

The description calls it a sandbox mod for the Source Engine, and the split of the tree matches that. The top level holds .editorconfig, .gitignore, CONTRIBUTING.md, README.md and two content directories, bin/ and garrysmod/. The split suggests two distinct trees, one for shipped binaries and one for the game content itself, though the README does not spell out the boundary between them and the directory listing is the only evidence on that point.

For an engineer, the useful way to frame this is that Garry's Mod is a Valve engine plus a first party script layer, and this repository is only the second half. Everything you can read here is the part that a player or server owner actually modifies.

Changes are tested on the Dev Branch before a release

The workflow the README describes is unusually explicit for a game repository, and it removes the usual question of when your change actually reaches players.

There is a Dev Branch, distributed through Steam, where changes for the next update can be tested before they ship. The companion page is the Update Preview Changelog, which lists what is queued. Current game discussion and update progress live on Discord rather than on the issue tracker, so the conversation about what is being worked on happens in a chat server, and the durable record of what is going in lives in the preview changelog.

The practical sequence for a contributor is therefore: propose the change, watch the Update Preview Changelog to see whether it has landed in the next release queue, and pull the Dev Branch to try the behaviour in a real client. Nothing in the documentation promises that a merged pull request ships in a particular release, and the release tagging pattern suggests the opposite. The tagged updates are dated drops such as the September 2026 Update on 2026-09-16, the April 2026 Update on 2026-04-29 and the November 2025 Update on 2025-11-12.

Those three dates are months apart and are not evenly spaced, so a good rule is to treat a merge as a change in the default branch rather than as a shipped feature. If your modification matters only to a server you control, a separate addon is a better distribution channel than waiting for a game update.

Bugs and feature requests are routed away from this repository

The repository's issue tracker is not where players report problems. The README sends bug reports to a dedicated Garry's Mod Issue tracker at Facepunch/garrysmod-issues, and feature requests to a separate request tracker at Facepunch/garrysmod-requests. Two separate repositories, split by intent, keeps the discussion of a defect separate from the queue of proposals.

Pull requests are the third channel, and the project asks for two things before opening one. The first is correct line endings, with a link to the standard advice on the topic. The second is condensing multiple commits into one, either by resetting the head or by rebasing the branch, with links to the standard explanations of both techniques. Neither request is unusual for a repository that has accumulated many contributors, but stating them up front tells you that a reviewer will look at the shape of the history and not only at the diff.

The separation has a cost for outside engineers who like a single tracker, since reproducing a bug report now means understanding which of the three channels a given kind of question belongs to. The payoff is that a pull request is not competing with a queue of bug reports, and a bug report is not closed because someone judged it out of scope for the next update.

CONTRIBUTING.md sits at the root of the repository, and the README refers contributors to it, so the full rules for a patch live in that file rather than in the overview. The line ending rule and the commit condensing rule are the two requirements stated in the README itself.

Translation is a separate, crowdsourced workflow

Localization does not happen in this repository. The README points contributors to a Crowdin project for the game's translations, and that is where translation work is done. The distinction is a normal one, and it has a concrete effect on how a localisation change travels: a Crowdin contribution enters the game's text and configuration through the translation pipeline, not through a pull request to the Lua tree.

That matters for a project whose user base is not English first. Garry's Mod is a sandbox where scripts, addons and server content are shared between people who do not share a language, so the text layer that ships with the game is load bearing in a way that a typical engine repository's is not. The .text and .config parts of the extension tree are exactly where the strings that Crowdin translates end up.

The workflow also explains something about the repository's shape. Because translation is handled on an external platform, the tree you see here is not the whole set of string changes; some of them arrive from a system that is not visible in the git history in an obvious way. Anyone auditing how a particular string reached the game needs to look at both places.

The repository is not archived and the last push was on 2026-10-14, so the Lua and text layer is being worked on as of that date. How much of that work is gameplay scripting, as opposed to text and configuration, cannot be determined from the top level listing, and the README does not break it down.

No LICENSE file means no stated terms for reuse

The repository metadata reports no recognisable licence for this project, and the top level listing contains no LICENSE file, only .editorconfig, .gitignore, CONTRIBUTING.md, README.md and the two content directories. The contrast with the open source projects around it is stark, and it is the most consequential thing on this page for an engineer who wants to reuse code.

Public visibility and permission are different things. The code is on GitHub, pull requests are accepted, and the project welcomes contributions, but none of that states a licence under which you may copy, modify or redistribute the Lua in this tree. A repository without a licence is legally in a different position from one with a permissive licence, and that is a question for whoever owns the rights, not something to infer from the fact that the source is visible.

The same question applies to the game as a whole. The binary sources are not public and are derived from Source SDK 2013, and Source engine games carry their own licensing and distribution terms, so the Lua layer here is one piece of a larger and differently licensed stack.

If your use is contributing a change back to the project, none of this blocks you, because that is exactly what the pull request process is for. If your use is lifting a utility function from the tree into a commercial addon or a shipped game, the absence of a licence file is a blocker rather than a detail, and the practical step is to ask the maintainers directly rather than to guess at terms that were never written down.

Where this repository sits against the Source SDK and workshop addons

Two alternatives exist for a developer who wants to extend a Source engine game, and they differ in a way that matters for what you can ship.

The first is Source SDK 2013, the public base the binary sources here are derived from; that is where the engine side of the stack comes from. This repository is the opposite of that: it is the script and content layer of a product that is already shipped, with the engine side closed. A team that needs to own a build, set a render configuration or change core behaviour is in Source SDK territory. A team that wants to change how the shipped sandbox behaves, permanently, for every player, is in this repository.

The second alternative is the workshop addon route, and this is the more common competitor for most developers. A workshop addon is distributed through the same Steam platform, can be installed and removed by players, and can be updated on its own schedule without waiting for a game release. It does not require a pull request, a review or a Dev Branch test, and it does not need anyone at Facepunch to agree to the change.

What only this repository offers is first party status. A change merged here is part of the base game, arrives for every user at the next update, and does not need a download step. What a workshop addon offers is speed and independence. A developer who wants to iterate with users this week is better served by an addon, and a developer whose change must be in the base game for technical reasons is better served here.

Editorial conclusion

Use this repository if you are writing Lua for Garry's Mod itself, or shipping a change that has to ship with the game rather than as a workshop addon, and you are ready to work inside a Valve engine build you cannot compile. Do not use it as a starting point for building your own Source engine game, because the binary sources are not public, and do not assume a permissive licence, because the repository lists no LICENSE file at all. Before you contribute, read CONTRIBUTING.md, keep line endings correct and condense your commits, check the Update Preview Changelog for what is already queued for the next update, and confirm on the Dev Branch that your change behaves as intended before the next dated release.

Frequently asked questions

Official sources

1. Facepunch/garrysmod on GitHub
2. Issues
3. Project website
4. README
5. Releases