Sunkenland Server Setup and RAM Sizing: Slots, Island Count and Save Safety

Sunkenland is an ocean-survival builder: players scavenge flooded cities, build floating bases, and defend them from raiders, all on a procedurally generated archipelago that the server keeps simulating. It supports a small co-op group by default, but the persistent world, ocean simulation, and structure tracking make RAM sizing the single decision that separates a smooth server from one that hitches whenever someone returns to a large base. This guide covers a clean setup and realistic RAM numbers.

Baseline setup checklist

Sunkenland ships a dedicated server launcher. Get these fundamentals right before touching RAM:

• Install on an NVMe volume — the world writes constantly as structures are placed and sea state updates.
• Open and forward the game’s UDP port, and confirm it with an external port check; a half-open port shows as “server not responding” rather than a clean error.
• Set a server password even for a private group; public Sunkenland servers attract join spam that wastes slots.
• Choose the world seed once and back it up immediately — regenerating a world later does not preserve anyone’s base.

RAM sizing by slots and world state

Sunkenland’s memory use scales with both player count and how built-up the world has become. Budget using the second, larger figure once your group has real bases:

Setup	Players	RAM (fresh world)	RAM (built-up)
Small co-op	1-4	6 GB	8 GB
Standard group	5-8	8 GB	12 GB
Large group	9-16	12 GB	16-20 GB

Always leave 2-4 GB beyond these figures for the operating system. Running a Sunkenland server with no system headroom makes the whole node unstable the moment a large base loads. A common mistake is sizing to the fresh-world figure and then watching memory climb for weeks as players build; if you provision once, provision for the built-up column.

CPU and network expectations

Sunkenland is less CPU-hungry than a large Minecraft network, but it still leans on a single simulation thread. Two to four fast cores will carry a small group comfortably; at 9-16 players with several active bases, four to six cores at 3.8 GHz or higher keep the tick stable. Network use is modest — inbound and outbound traffic is dominated by position updates and structure deltas — so a 100 Mbps uplink is ample for a casual group. What matters more than raw bandwidth is consistent low latency to your players’ region; hosting in a datacentre far from your group adds ping that no tuning can remove.

Why save integrity is the real risk

Ocean-survival builders share a failure mode with other voxel games: a save write interrupted by a crash or a full disk leaves a partially written world file that will not load. Three habits prevent it:

• Never fill the disk. Keep at least 20 percent free so the server has room for temp files during a save.
• Rotate backups. Keep hourly, daily, and weekly copies, and test restoring one monthly — an untested backup is not a backup.
• Store a copy off the node. A second site or object store survives the exact failures that take your primary down.

Tuning for smoother sailing

If players report hitches when approaching a large base, the cause is usually the server loading and saving structures as players come into range. Options that help:

• Reduce the maximum number of placeable objects per base where the config allows it.
• Split a sprawling community across two islands so no single base becomes a hot spot.
• Move saves to NVMe and enable frequent small autosaves rather than rare large ones.
• Pin the server process to fast cores so save IO threads do not compete with the main simulation tick.

A realistic tuning workflow

Rather than guess at settings, tune against observation. Start the server with a modest spawn multiplier and watch memory and tick time for a full session. As your group builds, re-check every week. When tick time creeps up, cut the heaviest setting first — usually creature spawns — before adding hardware. If RAM climbs but the CPU is idle, you have a memory leak or an oversized world and should prune, not upgrade. If the CPU is pinned while RAM is comfortable, raise clocks or move to a faster core. Following that order keeps you from buying hardware to solve a configuration problem.

The bottom line

Sunkenland is forgiving to set up but unforgiving to under-provision. Size RAM off the built-up world rather than the fresh one, keep at least 20 percent of the disk free, and rotate tested offsite backups on a schedule. Do those three things and you will never lose a community’s island fortress to a corrupted save. When you need a node with real NVMe and dependable RAM, it helps to compare hosting providers on verified hardware specs — and to pick a bare-metal plan sized for persistent survival worlds.