Proxy Sharding
A single server can only hold so many islands before it strains. IgniteSky can spread islands across several backend servers behind a Velocity or BungeeCord proxy, and still let players visit any island as if it were local.
network:
enabled: false
server-name: ""How it works
When network.enabled is on, every island created on a backend is tagged with that backend's name (server-name). When a player runs /is visit or /is home for an island that lives on a different backend, IgniteSky sends them to the right server through the proxy's Connect channel, then drops them at the island when they arrive. From the player's side it is one teleport.
Sharding needs a shared database (storage.type of mysql or mongodb) so every backend sees every island, and server-name must match this server's name as the proxy knows it. With a local sqlite store, backends cannot see each other's islands.
The arrival handshake
The clever part is that the cross server arrival reuses the shared database the sharding already requires. When you are sent to another backend, your destination island is recorded as a pending arrival; the moment you join that backend, it reads the pending arrival and teleports you in. No Redis, no extra message bus, no new infrastructure to run.
Hosting per mode
Each mode can also use the server_shared hosting strategy, which keeps per island worlds locally but shards them by this backend's tag. See World Hosting Strategies for how that compares to grid and world-per-island.
Left disabled, IgniteSky runs as an ordinary single server with none of this overhead. Turn it on only when you actually run a network.