-
-
Notifications
You must be signed in to change notification settings - Fork 0
Instance Fleet Mode
Status: Future / Not Yet Implemented. No release number or date is assigned.
Elah's main goal is to make one logical Minecraft world run safely across several workers. Instance Fleet Mode is a separate future idea: place whole independent Minecraft servers across a pool of machines.
Examples could include:
Lobby-007
BedWars-002
SkyWars-041
Dungeon-839
Survival-003
Each item would be its own server process and world. They would not be pieces of one distributed simulation.
The Distributed World Engine works with cells inside one world. It needs authoritative ownership, ownership epochs, safe player and entity handoffs, boundary behavior, migration, and world consistency.
An Instance Fleet Engine would work with complete servers. It would need instance identity, start and stop, CPU and memory reservations, ports, templates, proxy registration, health, drain, restart, placement, and demand-based scaling.
Distributed World Engine Instance Fleet Engine
------------------------ ---------------------
cell whole server instance
one logical world independent worlds
ownership epoch instance lifecycle
cross-cell handoff proxy registration
boundary simulation ports and templates
world consistency demand and health
Treating an instance as a large cell would be misleading. Independent servers do not share a cell map, ghost boundaries, or distributed-world authority.
The two engines could eventually share a small, proven substrate:
- machine identity and discovery;
- capacity evidence and resource reservations;
- admission and placement primitives;
- process or container lifecycle;
- health and crash observation;
- networking primitives;
- observability.
Elah will add a shared abstraction only when it improves the current distributed-world system on its own merits. There is no common workload hierarchy, template API, minigame manager, port allocator, or instance autoscaler today.
The machines and capacity exposed through Runtime Providers.
Many isolated Elah clusters use one infrastructure fleet. Each cluster keeps separate authority, credentials, storage, networks, metrics, and limits.
One future workload engine schedules whole independent Minecraft server instances.
These terms are not interchangeable.
Elah's differentiated problem is one logical world across many workers. That must work safely in production before the project takes on a second workload engine.
Future research requires:
- production-proven distributed ownership and handoff;
- qualified fencing, recovery, drain, storage, and boundaries;
- stable Runtime Providers and resource envelopes in real deployments;
- concrete operator demand that existing systems do not already solve well enough;
- a separate security and failure model for instances, ports, templates, secrets, proxy registration, and storage.
Until those conditions hold, no version is assigned.
Kubernetes and Nomad already schedule generic workloads. Agones already models warm game-server fleets, allocation, templates, placement, health, and autoscaling. Pterodactyl and Pelican already manage isolated game-server containers.
Elah should integrate with those systems where appropriate. It should not become a generic orchestrator or hosting panel. Elah-specific work begins where Minecraft topology, simulation, ownership, handoff, and world consistency matter.
Elah 0.0.3 | Repository | Releases | Security