Skip to content

Installation Linux

boyism80 edited this page Jul 4, 2026 · 3 revisions

Linux Installation

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.

Overview

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)

Choose a workflow

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

Quick comparison

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.


Shared requirements

Docker

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):

  1. server/fb/data/Dockerfile → game JSON from Excel tables
  2. server/fb/Dockerfile → C++ toolchain base (fb/build)
  3. C++ services: gateway, login, game, bot
  4. .NET services: internal, write-back, log, marketplace, admin-tool

Clone the repository

git clone --recurse-submodules https://github.com/boyism80/fb.git
cd fb

If already cloned without submodules:

git submodule update --init --recursive

Infrastructure services

Every 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-0fb-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.

Client-facing address

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

Related pages

Clone this wiki locally