Skip to main content

HARDWARE

Infrastructure built for persistent worlds.

Two machines in a rack we own, in a room we can walk into. Everything below is what is in it and how it is arranged.

The HowToSoftware server rack standing in the room, doors closed
THE RACK
PLATFORM HowToSoftware NODES 02 REGION US Central

01 PHYSICAL INFRASTRUCTURE

Physical infrastructure

The specifications below are read from the running hosts rather than copied from a datasheet. Where a figure has not been confirmed it is left out rather than estimated.

SPEC SHEET

CPU
Intel Core i9-10980XE
MEMORY
256 GB
STORAGE
5 TB NVMe
NETWORK
1 GbE uplink

THE RACK

The server rack photographed straight on, doors closed
FRONT

03 NODE TOPOLOGY

Node topology

How a request reaches a world: the panel decides, a node runs it, and the two are deliberately not the same machine.

HTS PLATFORM
  • NODE / 01 HEALTHY
    CPU
    Intel Core i9-10980XE
    MEMORY
    256 GB
    STORAGE
    5 TB NVMe
    NETWORK
    1 GbE uplink
    ALLOCATION --

    AWAITING COMMISSIONING

  • NODE / 02 HEALTHY
    CPU
    Intel Core i9-10980XE
    MEMORY
    256 GB
    STORAGE
    5 TB NVMe
    NETWORK
    1 GbE uplink
    ALLOCATION --

    AWAITING COMMISSIONING

ZOMBOID SERVERS

04 COMPUTE

Compute

Game workloads run on dedicated compute nodes rather than beside the website. Our customised Pterodactyl platform decides which node a server lands on and manages it there, so a workload can be deployed, moved or restarted on its own.

05 MEMORY

Memory

Each server gets its own memory allocation from its plan, isolated from the servers beside it. We watch capacity across the nodes so that a busy neighbour never eats into what another customer was given.

  • ALLOCATED
  • HEADROOM
  • RESERVED

06 STORAGE

Storage

World data sits on storage attached to the machine the server runs on, so saves are read and written locally rather than across a network. Infrastructure backups are kept apart from the servers they came from.

  1. WORLD VOLUME
  2. SNAPSHOT CHAIN
  3. ARCHIVE

07 NETWORK

Network

The public website, the game nodes and the services behind them are separated. Those components talk to each other over private paths, and customers reach only the services that are meant to be reachable.

  1. EDGE
  2. UPLINK
  3. NODE
  4. WORLD

08 DATABASE

Database

The panel keeps its state in a central MariaDB service, separate from both the web application and the game nodes. The panel connects to it when it deploys and while it runs, and schema migrations are applied as part of that deployment rather than by hand.

  • PANEL STATE
  • MARIADB SERVICE
  • MIGRATIONS ON DEPLOY

09 DEPLOYMENT

Deployment

The panel ships as a container. A new version is built into a new image, the container is recreated from that image, and migrations run as it starts. The same steps every time, and nobody editing a running application to make a change.

  1. NEW IMAGE
  2. CONTAINER RECREATED
  3. MIGRATIONS RUN
  4. PANEL SERVING

10 SERVER ALLOCATION

Server allocation

When a server is created, the panel picks a game node with room and provisions what the plan calls for. The panel is the management layer; the game itself runs on the compute node, not on the web tier.

NODE CAPACITY

  • INSTANCE
  • UNALLOCATED

AWAITING COMMISSIONING

11 RELIABILITY / OPERATIONS

Reliability and operations

Website, database and game workloads are separate infrastructure roles. Maintenance or an update on one is far less able to take the others with it, and a fault has a smaller place to hide.

  1. MONITORING
  2. BACKUPS
  3. RESPONSE
  4. MAINTENANCE

HARDWARE

Bring a community, and it lands on this hardware.

Specifications are read from the running hosts rather than copied from a datasheet. Where a figure has not been confirmed it is left out rather than estimated.

Something went wrong on our side. Reload 🗙