The server side of Bestia is not Godot — Godot only exists on the client (bestia-client). The backend is two independent Kotlin / Spring Boot JVM services with no shared database, talking to the client and to each other over two very different protocols:

• login-server — a stateless REST service. Its only job is turning proof of identity (a wallet signature, or a dev static token) into a signed JWT. It never touches game state.
• zone-server — the actual game: a Netty TCP socket, a hand-rolled ECS running a fixed-tick simulation loop, world generation/streaming, AI, combat, inventory, party and chat.

graph LR
  subgraph Client [bestia-client - Godot]
    C[GDScript + C#]
  end

  subgraph Backend [bestia-behemoth monorepo]
    LOGIN["login-server<br/>Spring Boot REST, issues JWT"]
    ZONE["zone-server<br/>Netty TCP, protobuf Envelope, ECS tick loop"]
  end

  C -- "HTTPS POST /api/v1/auth/..." --> LOGIN
  C <-- "TCP, length-prefixed Envelope frames" --> ZONE

Trust between the two servers is carried entirely in a signed JWT — there is no RPC call, shared database, or service discovery between login-server and zone-server. See Authentication for the full handoff.

Tech stack link

This corrects an older version of these docs, which described an Akka actor-cluster with a Cassandra/MariaDB backend. That design was abandoned; nothing in the current codebase uses Akka, Cassandra, or a graph database.

Repository layout link

The server code lives in the bestia-behemoth monorepo (Gradle multi-module, settings.gradle), alongside the client:

Subsystems link

A few smaller systems exist and work but don’t have their own page yet: party and chat (zone-server/.../party/, .../chat/) follow the same CMSG/handler pattern as everything else, and items/inventory/equipment/loot (.../item/) back the battle and economy pages without a dedicated write-up.

Known gaps link

Worth knowing before you go looking for something that isn’t there:

• Quests, NPCs and the economy don’t exist in code. The design docs are kept because the design work is good, but there is no quest, no shop, no currency and no town inhabitant in zone-server today — settlements are generated in full and stand empty.
• AuthenticationSuccess.permissions is defined in the protobuf schema but never populated — there’s an explicit TODO for it in ClientMessageHandler.
• Account ban status (AccountStatus, bannedUntil on login-server) is modeled but never checked during login.
• A destroyed building never comes back: no building kind has a regrowth time, so its divergence row is terminal and the loss survives every future boot. Tracked in Townsfolk.
• Both servers’ JWT secrets (and login-server’s Ethereum RPC/contract config) are still the development placeholder values in application.yml — not a concern for local dev, but not something to carry into a real deployment unexamined.