This web tool is designed to help players of the video game Satisfactory™ to plan a comprehensive production chain.
The tool highlights bottlenecks in the production chain, and visually tells the player that they have a problem within their designs.
The player can scale up end product factories as they see fit, and check if their production chain can handle the increased load.
Since this is an open source project, all PR requests will be welcomed, as long as proper intent and communication with the project maintainers is maintained.
This project has the following requirements. We highly recommend you use nvm to manage your node and p(npm) versions.
- Node.js version >=24
nvm install 24 && nvm use 24- You may want to make 24 the default version with
nvm alias default 24
- You may want to make 24 the default version with
- pnpm version >9.14.4
npm install -g pnpm - Docker (for the backend) Docker install docs
The web, backend, and parsing packages are managed as a pnpm workspace. A single pnpm install from the repository root installs the dependencies for all three, so you no longer need to cd into each package to set it up.
pnpm install # installs web + backend + parsing
pnpm dev # starts Mongo (Docker), then the backend + frontend togetherpnpm dev runs the frontend on http://localhost:3000 and the backend on http://localhost:3001 in parallel (their logs are interleaved in the one terminal). The backend requires Docker to be running and a backend/.env file to exist.
The port allocation is 3000 for the web app and 3001 for the API, everywhere — local dev, the container, the host, and behind the tunnel. Treat those two as fixed; anything else that wants a port should move rather than pushing the API off 3001.
One known overlap:
web/testing/global-setup.tsserves the testgameData.jsonon 3001 too, and it silently skips startup if the port is taken — so runningpnpm testinweb/while the backend is up makes the suite fetch game data from the API, get a 404, and fail confusingly. It is rare enough to live with: stop the backend first, or start it elsewhere withPORT=3011 pnpm dev:backend(the frontend's dev API URL is hardcoded to 3001, so only do that when you're not exercising save/load). If it does start to bite, move the test fixture to a port of its own — say 3005 — rather than moving the API.
Available root scripts:
| Command | Description |
|---|---|
pnpm dev |
Bring up the Mongo container, then run the backend + frontend dev servers in parallel |
pnpm dev:web |
Run only the frontend dev server |
pnpm dev:backend |
Bring up Mongo, then run only the backend dev server |
pnpm dev:parsing |
Run the parser |
pnpm db:up / pnpm db:down |
Start / stop the Mongo container on its own |
pnpm build |
Build every package |
pnpm lint / pnpm lint-check |
Lint (fix) / lint (check only) every package |
pnpm test |
Run every package's test suite |
You can still work inside a single package if you prefer — the per-package instructions below continue to work. Each package keeps its own pnpm-lock.yaml (the workspace uses sharedWorkspaceLockfile: false), so dependency versions are pinned independently and CI is unaffected.
cd web
pnpm install
pnpm devVisit http://localhost:3000 to view the project. You may need to load it twice.
There are tests for the frontend project, run them with pnpm test. Tests must pass for PRs to be accepted. Note as of writing the coverage isn't 100%.
The parser is responsible for processing the Docs.json from the game and reconstructing a more readable version for our use, since the game's docs file is overwhelmingly large and not very human-readable. The file is located under X\steamapps\common\Satisfactory\CommunityResources\Docs on Windows. Replace X with where you have installed your steam library (usually C:\Program Files (x86)\Steam)
To run the parser:
cd parsing
pnpm install
pnpm devWhen the parser is run, it outputs to file /parser/gameData.json. This file needs copying to /web/public/gameData_v1.x-xx.json. The version must directly correlate with the minor version of the game (unless a patch messes with a recipe, unlikely). e.g. v1.0-11.json would increment to v1.0-12.json. The old version needs deleting when you commit.
Once the new file has been placed, you must also edit /web/src/config/config.ts and update the version there too.
This instructs web clients to re-download the game data file with the new version upon refresh and replace their locally stored version.
Required for the login and syncing of data features, not required for local development.
- Start Docker service on your local machine.
cd backend
pnpm install
./start.shAPI will be available on http://localhost:3001.
There are no tests currently available for the backend project.
New versions are trunked to main branch. Once main has been pushed, GitHub Actions will create a release then deploy the frontend to Vercel, and build a docker image of the backend which is published to Docker Hub and pulled onto my personal server automatically.
See docs/deployment.md for the backend chain end to end — including how to tell whether a deploy actually landed, since a green Actions run does not prove it.
This project is licensed under the GNU License - see the LICENSE file for details.
Please kindly consider opening PRs to improve the project, and make it better for everyone rather than making a clone.
- Many thanks to Greeny (creator of Satisfactory Tools) for collating all the game assets required to display the various icons for items and buildings.
- Thanks to the author of Satisfactory Logistics, who gave me the inspiration to extend what they did but even further.