Terraforming Mars is an open source implementation of the board game

The legal positioning comes first

The README opens with a disclaimer that matters more than usual here. It is an open source online implementation of the great board game Terraforming Mars, and it is not affiliated with FryxGames, Asmodee Digital or Steam in any way. Then there is the note about Rebalanced Mars, whose authors have refused to open source their code, and the project states that it believes this is both a violation of the GPL3 license and of the spirit of collaboration the project tries to foster, adding that any new features seen on that server were made available without their permission. The recommendation to buy the board game follows, and it is not a disclaimer, it is the argument. The digital implementation exists because the physical game is good, and the licence complaint exists because the code was open and the derivative was not.

The hosted instance and its retention rules

For people who just want to play, the README points at an instance on Heroku, describes it as generally reliable, and then explains the part that matters. The site is restarted daily. A multiplayer game will remain available for 15 days, after which it is flushed from the database. Unfinished solo games are flushed after one day. The project says it continues to make stability and scalability improvements in step with growth and popularity, but in order to make sure your game remains it strongly recommends hosting your own web server. There is a Discord for the community, a playlist of tutorials made specifically for this application, and a wiki with the rulebooks for people who want to learn the game rather than just the app.

Four ways to run your own copy

The deployment options are laid out as a set of sections, each with a wiki page, and the framing tells you how well each is supported. A local setup page is described as really simple. The Heroku page is the recommended way to deploy, because the instructions are the clearest, and the README notes that as of 28 November 2022 Heroku no longer has a free tier. A Docker page carries the warning that it is not aggressively supported, though some people are on the Discord. And a YunoHost server page points at a separate repository holding the package code, with a warning that it is not specifically supported. Bug reports and feature requests go to the issues tab, and the contribution guide and a local development setup page are linked for developers.

Vue 3, webpack and Node 22

The package manifest describes the stack and it is a conventional one. The runtime is Node 22.x, the client is Vue 3.4, and the build is webpack 5 with webpack-cli. The other runtime dependencies are the working parts of the server and the client, with chart.js for the charts, markdown-it for rendering text, mnemonist for the data structures, prom-client for the metrics, uuid for identifiers, dotenv for configuration, console-stamp for logging, html-escaper for output safety, and dialog-polyfill. The development dependencies are the interesting part, because they show two test systems running at once. There is mocha with chai and chai-as-promised, and there is vitest with a separate vitest.config.mts, plus jsdom, @vue/test-utils, and the type packages for better-sqlite3 and pg, which tells you the project can run on either database. Styling is Less with stylelint and the stylelint recommended Less config, linting is ESLint 10 with the Vue plugin and the typescript-eslint plugin, and the TypeScript side has a tsconfig, a separate tsconfig.vue-tsc.json for the Vue templates, fork-ts-checker-webpack-plugin for type checking during the webpack build, and vue-tsc for the templates.

A Docker image that does not run as root

The Dockerfile is a four stage build and the details are the interesting part. The node version is defined once as an argument and defaults to 22 on Alpine 3.21. The install stage adds the toolchain a native module needs, including git, python3, py3-setuptools, make and a C++ compiler, and symlinks python3 so the node-gyp path resolves. It then copies the package manifest and lockfile first and runs npm ci, so the dependency layer is cached independently of the source. A builder stage copies the sources and runs the build, and a separate installprod stage installs only production dependencies with the offline preference, so the runtime image does not carry the development toolchain. The final stage adds a dedicated user named tfm, creates the db directory, chowns the tree to it and switches to that user with a USER instruction, and then copies in the built app and the assets. The image exposes port 8080 and starts with the start script.

Compose file, ports and a data volume

The compose file is short and tells you how the project expects to be run. There is a single service named terraforming-mars, built from the local directory, with a restart policy of unless-stopped, and the port mapping from 8080 on the host to 8080 in the container. The one hardening line is a security option, no-new-privileges set to true, which stops a process in the container from gaining privileges through a setuid binary. The data lives in a named volume mounted at the db directory inside the container, so the games survive a container replacement. That volume is the whole persistence story, and pairing it with the non-root user in the image is what makes the arrangement work, since the directory has to be writable by the account the container runs as.

One environment file holds the behaviour

The sample environment file is where the operational policy of a server lives, and the comments are unusually explicit. The file is renamed to .env to take effect and is ignored in source control. The port and the hostname are set there, with the note that an unspecified hostname makes the server listen on all network interfaces. The TLS certificate and key paths point at the fullchain.pem and privkey.pem files that certbot produces. Then the retention rules, where MAX_GAME_DAYS controls how long games stay in the database, with the note that when it is unspecified Postgres deletes games after 10 days while SQLite does not delete games at all. COMPRESS_COMPLETED_GAMES_DAYS controls how long a game is kept in its complete state before it is compressed, and WAITING_FOR_TIMEOUT sets how many milliseconds to wait before checking a multiplayer game for updates. The last piece is the abuse control, with GAME_QUOTA taking either a single limit object or a JSON array of tiers, where a request has to satisfy every tier, the per value accepting h, m and s suffixes such as 10m or 24h, and no default limit being enforced when it is unspecified.

Contributors, licence and the current state

The contributor list is long and credited by area, which is a good sign for a project with this many fan expansions. Brian Folts is credited with all the things, Vincent Moreau with Venus, Prelude, Hellas and Elysium, Colonies and Turmoil, alrusdi with the front end and internationalization, and Simeon Simeonov with the user experience, the cards and the Colonies design. The rest cover the community and Political Agendas fan expansions, and Robert Konigsberg is credited with the Ares, The Moon, Pathfinders and Underworld fan expansions, Prelude 2, infrastructure cleanup, code reviews and two opinions too many. The licence is GPLv3, the default branch is main, and the repository publishes no GitHub releases, with the last push on 2026-10-19. The tree also shows the working habits of a modern project, with a CLAUDE.md and a GEMINI.md for coding agents, a STYLE.md, a webpack configuration, a Vitest configuration, a vscode.sample directory and a scripts directory.

Editorial conclusion

This project fits a group of players who want to play the board game online with the full set of fan expansions, and it fits a developer who wants to run a small game server on their own hardware with a container. It does not fit anyone looking for the commercial digital edition, since the project is explicitly not affiliated with the publisher or the store, and it does not fit a host expecting the hosted instance to keep games, because it is restarted daily and unfinished solo games are flushed after a day. Before you deploy, copy the .env.sample file, set the game retention and quota values, and remember the licence situation, since the GPLv3 terms are the basis of the project objection to a closed derivative.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. terraforming-mars/terraforming-mars on GitHub