-
Notifications
You must be signed in to change notification settings - Fork 1
Installation Linux
This guide covers running and deploying the fb server stack on Linux.
Linux uses Docker for all server binaries. There is no native host build path and no Linux port of Runner. C++ and .NET services are built inside Docker (server/*/Dockerfile) and run as containers.
For architecture overview, see Architecture and Technology Stack.
| Layer | Components |
|---|---|
| Infrastructure | MySQL 8.0+, Redis, RabbitMQ |
| C++ services | Gateway, Login, Game, Bot |
| .NET services | Internal, Write-back, Log, Marketplace, Admin Tool |
| Runtime assets | Maps, Lua scripts, generated JSON (bundled in images) |
| Goal | Guide |
|---|---|
| Single host — local dev, staging, small deployments | Linux — Docker Compose |
| Cluster — production, multi-world, NodePort exposure | Linux — Kubernetes |
| Cluster + IaC — optional programmatic deploy on top of Kubernetes | Linux — Pulumi |
| Docker Compose | Kubernetes | Kubernetes + Pulumi (optional) | |
|---|---|---|---|
| Orchestrator | Docker Compose | Kubernetes (kubectl) |
Kubernetes via Pulumi |
| Docker required | Yes (build + run) | Yes (build; cluster pulls images) | Yes |
| Best for | One machine, fast iteration | Production clusters | Repeatable CI/CD, multi-world as code |
| Multi-world | Profiles / multiple compose files | Manual manifests or Pulumi | Built-in via develop.json
|
| Config |
.env + generated compose configs |
Manifests / Helm / Pulumi |
develop.json + Pulumi host secret |
| Status in repo | Supported (infra/compose/) |
Supported (infra/k8s/) |
Supported (infra/pulumi/) |
For interactive development on Windows (Runner or native build), see Windows Installation.
All Linux workflows require Docker with buildx for multi-stage image builds (server/fb/Dockerfile, server/*/Dockerfile).
| Tool | Purpose |
|---|---|
| Docker + buildx | Build service images locally or in CI |
| Git | Clone with submodules (tools/data-converter, tools/flatbuffer-ex) |
| Registry (K8s) | Push images so the cluster can pull them (e.g. GHCR) |
Image build order (same as CI and tools/build.sh):
-
server/fb/data/Dockerfile→ game JSON from Excel tables -
server/fb/Dockerfile→ C++ toolchain base (fb/build) - C++ services: gateway, login, game, bot
- .NET services: internal, write-back, log, marketplace, admin-tool
git clone --recurse-submodules https://github.com/boyism80/fb.git
cd fbIf already cloned without submodules:
git submodule update --init --recursiveEvery stack needs MySQL, Redis, and RabbitMQ reachable by application containers.
Example database layout (see server/internal/appsettings.Development.json):
- Unified MySQL:
fb-unified - World 1:
fb-1-global,fb-1-data-0…fb-1-data-2 - Log shards: created by migrations under
infra/db/migrations/
With database.autoMigration enabled, Internal applies SQL migrations on first start when the MySQL user can create databases and tables.
Gateway, Login, and Game must advertise an IP or hostname that game clients can reach — not in-cluster DNS names.
| Workflow | How it is set |
|---|---|
| Docker Compose |
FB_HOST in .env via tools/compose-config.sh
|
| Kubernetes | Service externalIPs, LoadBalancer, or NodePort on node IP |
| Pulumi | Pulumi secret host
|
- Linux — Docker Compose
- Linux — Kubernetes
- Linux — Pulumi (optional, on Kubernetes)
- Windows Installation
- Architecture
- Technology Stack