# tgstation: the /tg/station fork of Space Station 13

> tgstation is the codebase for the /tg/station flavour of Space Station 13, a paranoia laden round based roleplaying game built on the BYOND engine and the DreamMaker language, with a server that runs on port 1337 and a Docker build that compiles the whole thing from a multi stage image. Its licence is layered rather than uniform, which matters if you plan to fork it, and its own badges are unusually blunt about the state of the code.

**tgstation/tgstation** — The /tg/station branch of SS13.

- Repository: https://github.com/tgstation/tgstation
- Website: https://tgstation13.org/
- Stars: 1,943 · Forks: 5,334
- Language: DM
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/tgstation-tgstation

## A game codebase, not a framework, and the forks around it

This repository is the codebase for the /tg/station flavoured fork of Space Station 13, which the README describes as a paranoia-laden round-based roleplaying game set against the backdrop of a nonsensical, metal death trap masquerading as a space station, with charming spritework. The stack underneath is the BYOND engine and the DreamMaker language, which is why the repository's primary language is listed as DM and why the topics include byond and dreammaker. What makes this project interesting to a developer is the scale and the fact that it is alive: the last push was on 2026-10-18, and the README links a separate repository for server configuration and another for the common core lore, so the game code, the operational configuration and the narrative content are maintained in three different places. There is also a separate Discord for general coding, a Discord for the game itself, a wiki, generated code documentation, a contribution guide, a development guide and a set of maintainer-approved design documents hosted on HackMD. It is a community project with a real engineering process wrapped around a very unusual language.

## Four licences covering four different parts of the tree

The licence section is the most careful thing in the README, and it is a good model for a project with this much history. All code after commit 333c566b88108de218d882840e61928a9b759d8f, on 31 December 2014, is licensed under the GNU AGPL version 3. All code before that commit is under the GNU GPL version 3, including the tools unless their own readme says otherwise, and the repository carries a `GPLv3.txt` alongside the `LICENSE`. Then the TGS DMAPI is licensed as a subproject under the MIT licence, with the pointers to the footer of `code/__DEFINES/tgs.dm` and to `code/modules/tgs/LICENSE`. And all assets, including icons and sound, are under a Creative Commons 3.0 BY-SA licence unless otherwise indicated. For anyone planning to run a fork, that split has a practical consequence: the code you can host and the assets you can redistribute and the subproject you can vendor have three different rules, and a deployment that mixes them has to keep them separate.

## Building it, and the two ways to get a server on port 1337

The compiling section is written for people who have never built a BYOND project, and it is worth reading as a description of how the project is developed. The quick way is to find `bin/server.cmd` in the repository and double click it, which automatically builds and hosts the server on port 1337. The long way is `bin/build.cmd`, which initiates the build in multiple steps and might take around one to five minutes to compile, and the README explains that if the window closes it has finished its job, after which you set the server up by opening `tgstation.dmb` in DreamDaemon. The README also warns that building tgstation in DreamMaker directly is deprecated and might produce errors, giving a specific example of the kind of message you will see, `'tgui.bundle.js': cannot find file`, which is a symptom of skipping the bundled build step. For anyone with tooling preferences, there is a document for compiling in VSCode and other build options under `tools/build/README.md`, and the repository ships a `Dockerfile` that does the whole thing in a container.

## The Docker build, and why it installs 32 bit libraries

The Dockerfile is a multi stage build and it explains a lot about the constraints the project lives under. The base stage starts from Ubuntu Xenial, adds the i386 architecture and installs ca-certificates, and the byond stage adds curl, unzip, make and the i386 standard C++ runtime, then runs `dependencies.sh` and downloads the BYOND Linux build directly from byond.com with a `User-Agent` of `tgstation/1.0 CI Script`, patching its Makefile so the man pages install to the right place and cleaning up the download tools afterwards. The build stage copies the tree in and runs `tools/build/build.sh` with `TG_BOOTSTRAP_NODE_LINUX=1`, then `tools/deploy.sh /deploy`. The rust stage installs rustup with a minimal profile and adds the `i686-unknown-linux-gnu` target, and the rust_g stage builds the native `rust_g` component with the i386 development packages and gcc-multilib. The i686 target and the 32 bit system libraries are not a stylistic choice, they are what the BYOND toolchain and the native components need.

## Reading the tree: DM code, a tgui front end and native helpers

The top level of the repository shows the shape of a game project written in a language most developers have not used. `code/` holds the DreamMaker source, `tgui/` is the interface layer and it is the part with its own tooling, since the package manifest contains just two scripts, `tgui:lint` and `tgui:fix`, both running biome over the tgui directory, with biome and prettier as the only dev dependencies. Around that sit `interface/`, `html/`, `strings/`, `icons/`, `sound/`, `config/`, `SQL/` and `_maps/`, the map files that define the station and the away missions, plus `lua/` and two native binaries, `dreamluau.dll` and `rust_g.dll`, which are the compiled helpers for the Lua and Rust components of the codebase. The build configuration sits in `SpacemanDMM.toml` for the DreamMaker compiler and `.tgs.yml` for the TGS build, and the dependency manifests are a `bun.lock` and a `package-lock.json`, which tells you the project uses more than one JavaScript package manager. A `Dockerfile`, a `BUILD.cmd`, a `RUN_SERVER.cmd` and a `dependencies.sh` complete the top level.

## The badges are honest about the technical debt

The badge row at the top of the README is a small lesson in how to signal a project's real condition. There are the usual ones, a CI Suite workflow badge and an isitmaintained pair showing the percentage of issues still open and the average time to resolve an issue. Then there is a coverage badge that reads 4 percent and is coloured red, which is a deliberate piece of candour about a codebase where automated coverage is close to nothing. And then there are three joke badges, one saying the project is built with resentment, one saying it contains technical debt, and a made in BYOND graphic with a link to a Reddit thread about what the main problem with BYOND as an engine is. Read together with the actual state of the tree, which includes a `code/modules/tgs/` subproject with its own licence, they set an expectation. This is a project that has run for years, that people genuinely contribute to, and that is candid that most of its code is untested.

## How a change actually gets through

The process around the code is more formal than a typical game project. The README's link table points to a contribution guide, a development guide hosted on HackMD, and a set of maintainer-approved design documents, which is the pattern of a project that has learned to argue about design in writing before writing code. It also states that GitHub inquiries such as moderation actions may be handled through the /tg/station Discord in the coding-general channel, with the Maintainer role pinged, following the guide to asking questions in the channel description, which tells you that discussion happens in chat and the issue tracker is for the work itself. The common core lore lives in its own repository, so a change to the game's writing is reviewed separately from a change to its code. The repository's own history reinforces the point. The single published release, `runtime-condenser-1.13`, dates from 2020-12-16, while the branch receives pushes almost daily, which tells you that releases are not how this project ships and that the branch is the product.

## Conclusion

Adopt tgstation as a learning environment if you want to read a large, real, community driven game codebase written in an unfamiliar language, or as the base for your own server fork if you already run a BYOND game. Do not adopt it expecting a maintained library with a stable API, since it is a game, the surface changes with the community, and the repository publishes a single release tag from 2020. Before you fork it, read the licence section carefully, because the code is AGPL after a specific 2014 commit, GPL before it, the DMAPI subproject is MIT and the assets are CC BY-SA 3.0, and those four terms cover different parts of the tree. The licence is AGPL-3.0 for the current code, the last push was on 2026-10-18, and the project runs its server on port 1337.

## FAQ

### What is tgstation?

It is the codebase for the /tg/station flavoured fork of Space Station 13, a paranoia-laden round-based roleplaying game built on the BYOND engine and the DreamMaker language. The repository also links separate repositories for server configuration and for the common core lore.

### How do I build and run a tgstation server?

The quick way is to run `bin/server.cmd`, which builds and hosts the server on port 1337. The longer way is `bin/build.cmd`, which takes about one to five minutes, after which you open `tgstation.dmb` in DreamDaemon. Building in DreamMaker directly is deprecated and can fail with an error about `tgui.bundle.js` not being found.

### What licence applies to the tgstation code and assets?

All code after the commit of 31 December 2014 is under the GNU AGPL version 3, all code before it is under the GNU GPL version 3, the TGS DMAPI subproject is MIT, and all assets including icons and sound are under Creative Commons 3.0 BY-SA unless otherwise indicated.

### How is the tgstation Docker image built?

In stages: an Ubuntu Xenial base with the i386 architecture added, a stage that downloads and installs the BYOND Linux build, a build stage that runs `tools/build/build.sh` with `TG_BOOTSTRAP_NODE_LINUX=1` and deploys to `/deploy`, and a Rust stage that installs rustup with the `i686-unknown-linux-gnu` target to build the native `rust_g` component.

## Sources

- [License: AGPL-3.0](https://github.com/tgstation/tgstation/blob/master/LICENSE)
- [Project website](https://tgstation13.org/)
- [README](https://github.com/tgstation/tgstation/blob/master/README.md)
- [Releases](https://github.com/tgstation/tgstation/releases)
- [tgstation/tgstation on GitHub](https://github.com/tgstation/tgstation)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tgstation-tgstation