Eco Server Requirements and RAM Explained
How much RAM, CPU and storage an Eco server really needs, worked out from world size, player count and world age, with the settings you must get right before the first start.
A 100×100 world has about 1.9x the area of the default 72×72, a 160×160 world about 4.9x, and a 200×200 world about 7.7x. More area means more terrain, plants and animals to keep in memory and save to disk.
Player records are small. Buildings, stockpiles, laws, machines, garbage, pollution and modded content are what make a save heavier over time, which is why a world that was fine in week one can struggle in week six.
Eco leans hard on one main CPU core. More RAM helps if the server is short on memory, but it cannot rescue a busy main thread that is already spending too long simulating the world.
If the server improves after a restart and then degrades again, that points to build-up over uptime. Scheduled restarts, cleanup and sensible world settings help, but some worlds simply outgrow the original plan.
The official baseline for the default 72×72 world
The official minimum server spec is specifically for the default 72×72 world on Windows, and the same server is supported on Linux as well. The important part is not just the figures, but the context: this is the baseline for a fresh, default-sized world, not a mature public settlement with weeks of construction, storage and law data behind it.
| Item | Official baseline | What matters in practice |
|---|---|---|
| CPU | Intel Core i5 or AMD equivalent; higher frequency preferred | Eco mostly uses a single CPU core for its heavy work, so clock speed matters more than adding lots of extra cores. |
| Memory | 4 GB RAM | Enough for a fresh default world and a small group. It is not a comfortable target for a busy older save. |
| Storage | 1 GB space | Use an SSD if the world has a complex law setup or heavy database activity. Disk access affects saves, backups and database lookups. |
| Operating system | Windows or Linux | Either is supported. The bigger difference is the quality of the CPU core, available RAM and storage speed. |
| Local hosting | Must meet both client and server requirements | If you host on the same machine you play on, the client still needs its own memory as well as the server. |
That last point catches people out. The client minimum is 8 GB RAM and the recommended client memory is 16 GB RAM, so a self-hosted setup needs to satisfy both sides at once. If you want the broader hardware logic behind that, our guide to game server hardware requirements explains how CPU, RAM and storage each fail in different ways.
World size is the biggest lever, and you only get one chance to pick it
World size is the most important choice because it is fixed at generation. Eco stores and simulates a persistent planet, so a larger map is not just “more room”; it is more terrain data, more ecology to track, more plants and animals to hold in memory, and more world state to write to disk. Bigger also is not automatically better for gameplay or ecology: the official guidance is clear that very large worlds can make it harder for players to have any meaningful impact.
| World size | Area | Area vs 72×72 | Official use case |
|---|---|---|---|
| 72×72 | 0.52 km² | Default | Small; default; recommended for single-player and co-op |
| 100×100 | 1 km² | About 1.9x | Medium; often used for small public servers |
| 160×160 | 2.56 km² | About 4.9x | Large; the largest size Host a World can generate |
| 172×172 | 2.96 km² | Above 160×160 | Known to work on above-average server hardware, but not recommended |
| 200×200 | 4 km² | About 7.7x | Can work on above-average hardware, but not recommended |
| 224×224 to 400×400 | Larger custom sizes | Far beyond default | Can work on strong hardware but likely will not perform well |
Each chunk is 10 m across, so the default 72×72 world is 720 m by 720 m. Look at the area jump rather than the chunk numbers. A 160×160 map is not “a bit bigger” than default. At about 4.9x the area, the server has far more world to keep alive. That costs RAM first, but it also adds save size, database work and more simulation for the main CPU thread to process.
Build height matters too. The default MaxBuildHeight is 160, and values above that heavily increase hardware usage because the server now has more vertical world volume to account for as well as more possible placed objects and terrain data. It cannot be lowered after world creation, so treating height casually can lock you into a heavier world than you expected.
MapSizePreset Medium MaxBuildHeight 160
Those settings live in WorldGenerator.eco, and they only apply to a new world. Editing them after the first start will not resize the existing save. If you need a different world size later, that means a wipe and a new generated world, not a live conversion.
How much RAM an Eco server actually needs
RAM sizing makes more sense when you combine world size with the stage of the world. A new 72×72 save and a month-old 100×100 industrial town are not close in memory behaviour, even if the player count looks similar. Use the ranges below as starting points, then add headroom if you know the world will stay online for weeks, use mods, or attract heavy builders and law-heavy communities.
| World and stage | Suggested starting RAM | Why this is the starting point |
|---|---|---|
| Fresh 72×72 world, 4–10 players | 4 GB | Matches the official minimum for the default world. Best for a new save rather than an older built-up one. |
| 100×100 world, or an active town of 10–20 players | 6-8 GB | More area or more active building and storage means more memory held for world state and server caches. |
| 160×160 world, or a large civilisation of 20–40 players | 10-16 GB | At this point either world area, settlement complexity or both are substantial enough that a small RAM plan is usually false economy. |
| 200×200 world or a big public server with 40+ players | 16 GB+ | Very large world state or very busy long-running communities need both memory headroom and a fast main CPU core. |
These are not promises. They are planning bands drawn from the official default-world baseline, host sizing tables and the figures in our Eco server hosting comparison. Host tables put a 140×140 world at about 8–12 GB, between the second and third rows. The key rule is to size for month two, not day one: once people place more machines, hoard more items, write more laws and leave more world clutter behind, memory use rises and so does pressure on the database.
If you are choosing a rented plan, do not buy purely for the map you want to start with. Buy for the save you expect to have after several weeks of real use. That is especially true after Update 14, because nearly every crafting recipe now leaves garbage that has to be sorted or recycled, and unmanaged garbage adds pollution and more simulation work on top.
Players matter, but activity matters more
Raw player count is only part of the story. Eco does store data for each player, but player records themselves are not the main memory problem. The heavier growth comes from what those players leave behind: buildings, stockpiles, machine networks, roads, vehicles, laws, chat history, land claims, rubble, garbage and all the item state inside containers.
That is why a quiet server with a medium world can stay healthy longer than a smaller world with a very active industrial town. Every placed object and every stored stack expands the persistent world state. Those changes cost RAM because the server has more live data to hold, disk because the database and saves grow, and CPU because the main thread has more state changes to process while people are online together.
Update 14 sharpened this effect. Garbage and pollution are not cosmetic; they add simulation work. If your server was already near its memory limit before, the same world can now need more headroom simply because the simulation has more to track. More simultaneous players also means more requests hitting the same main thread at once, so an older save can feel fine off-peak and then buckle when everyone crafts, moves items and updates machines at the same time.
Why a world gets heavier over time, and what cleanup actually helps
A classic Eco pattern is a server that feels fine just after a restart, then gradually worsens as uptime grows. That usually points to build-up: caches refill, more world objects accumulate, database activity rises and the save simply gets older and busier. A restart does not erase the underlying world state, but it can clear transient build-up and confirm what sort of problem you have. If performance snaps back after every restart and then slowly drops again, treat that as a diagnostic clue.
- Clears build-up that collects over uptime, so a slow server often feels fresh again
- Does not shrink the world: buildings, items and laws are all saved
- Better after every restart, then slowly worse? That is build-up, so schedule restarts and run cleanup
Start with regular maintenance rather than random tweaks. Our guide on how to reduce lag on an Eco server goes deeper into /performance report, /profiler cpu and /profiler memory, but these are the cleanup commands most owners should know first.
| Command | What it clears | Why it helps |
|---|---|---|
/chat clearhistoryolderthan 3 | Older chat history | Reduces stored chat data and trims background clutter. The trade-off is less historical chat for players and staff to refer back to. |
/land resetworldcaches | World-related caches | The server rebuilds these caches from the live world, so resetting them is a safe part of routine cleanup when a long-running world has grown sluggish. |
/property unclaimabandoned 4 | Abandoned claims after the set period | Removes dead land usage and can open the way for broader cleanup. The trade-off is administrative: make sure your community rules are clear before using it. |
/land clearrubble 500 | Rubble in the world | Rubble is more persistent object data the server must track and save. Clearing it reduces world-object load, though players lose any rubble left for collection. |
/maintenance | Scheduled restart and maintenance window | Restarts clear build-up and are often the fastest way to restore responsiveness. If the improvement is dramatic but temporary, you likely need either more cleanup or more capacity. |
There is also one easy memory trade-off in Performance.eco:
MaxTooltipCacheSize 1000
Lowering MaxTooltipCacheSize can reduce RAM usage because the server keeps fewer cached tooltip results. The cost is slower tooltip responses for players, so do not change it just because the option exists. Use it when memory is tight and you can accept slightly less snappy UI behaviour.
If you suspect an actual leak or want deeper evidence, Memory.eco includes TrackUnremovedWorldObjects. That is more for investigation than everyday tuning, but it can help narrow down worlds where object cleanup is not behaving as expected.
CPU matters just as much as RAM
Eco rewards fast single-core performance more than high core counts. Most of the heavy server work runs on one main CPU core, so the best upgrade is often a faster core, not simply more cores. This changes how you should read server plans and spare-PC specs: a machine with plenty of RAM but weak per-core speed can still stutter badly once the simulation gets busy.
What does that look like in practice? If the server slows down when many players are active in one town, around large factories, or during complex world updates, that is often main-thread CPU pressure. Extra RAM will not fix it because the problem is not “not enough memory”, it is “the main thread cannot finish its work quickly enough”. The player-facing symptom is rubber-banding, slow interaction, delayed machine updates or a server that simply feels behind real time.
When choosing a plan or PC, prioritise the strongest single-core speed you can justify, then add enough RAM for the world size and lifespan you expect. If you are torn between a bigger RAM number and a meaningfully faster CPU core, Eco is one of the games where the CPU upgrade often matters more once you have passed the bare minimum.
Disk speed, save intervals and why long-running worlds fill storage
Eco writes often enough that storage quality matters. By default, the server saves every 60 seconds and creates backups every 0.5 hours. Those writes hit the database and world files in the Storage folder, so slow storage can cause stalls during save-heavy moments, especially on older worlds with large databases.
An SSD is worth treating as standard for any serious server, and it becomes more important if your community uses the law system heavily because that increases database access. Storage growth is not just the live world either. Long-running worlds plus backups can reach 10 GB+ of disk, and if you use memory profiling, dump files can be about as large as the RAM in use at the time.
Configs/ Storage/ Game.db Game.eco Backups/ Mods/ Logs/ Dump/
The config templates live beside their .template versions, and those templates are overwritten on update. Copy the template and remove .template rather than editing the template itself. Also remember that config file edits need a server restart, while changes made in /serverui apply live but still need File > Save if you want them kept.
Mods and self-hosting on the same PC
Mods raise the baseline because they add more content, more object state and sometimes more systems for the server to track. As a rough budget, allow about 1-2 GB extra for a moderate mod list. That is not a hard rule, just sensible headroom. After game updates, check again: a mod list that was harmless on one version can become the tipping point on the next, and mod collections can auto-update.
Players do not just see mods on the server side either; mods auto-download to them, so mismatches and update timing can show up as connection or start-up trouble after a patch. If a server begins stalling or failing to start after an update, strip the problem back to the base game first, then reintroduce mods one by one or in small groups. For worlds with very large food storage, note that a start-up stall was addressed in 14.2.1, so version matters before you blame the hardware.
For home hosting, the server is supported on Windows and Linux, but the real limit is shared hardware. If you run the client and server on one machine, you must meet both sets of requirements at once. Add the two minimums together and a fresh 72×72 world already wants 12 GB (8 GB for the client, 4 GB for the server) before the operating system takes its share. A 16 GB PC can therefore host and play a fresh 72×72 world, but it does not leave much headroom once the client, operating system, server, saves and caches are all active together. That sort of setup works best for a small co-op save, a light or empty mod list, and the expectation that you may move the server elsewhere once the world matures.
If you are planning that route, our guide to hosting a game server on your own PC is the right next read. If you also need remote access, remember the default ports are UDP 3000 for the game and TCP 3001 for the web UI.
Symptom, likely cause, first fix
Use symptoms to narrow the problem before buying more RAM. Eco can feel “laggy” for several different reasons, and the first fix depends on which resource is actually under pressure.
| Symptom | Likely cause | First fix |
|---|---|---|
| Slow from day one on a big world | World size is too ambitious, so the server starts with too much terrain and ecology to simulate | Reduce world size on the next wipe, keep build height sensible, and prioritise faster single-core CPU over extra RAM alone |
| Gradual slowdown over weeks that clears after restart | Memory build-up, cache build-up or world-state growth over uptime | Schedule daily restarts at minimum, clear obvious clutter, review chat history and world caches, then reassess RAM headroom |
| Freezes or long hitches on saves and backups | Disk I/O bottleneck or a large mature database | Use SSD storage, watch backup timing, and trim unnecessary growth in the Storage folder |
| Crash or stall on start after an update | Broken mod, version issue, or a known start-up problem on certain older builds | Update first, test without mods, and re-add mods carefully after confirming the base server starts cleanly |
| Everyone lags around big factories or busy town centres | Main-thread CPU pressure from dense active simulation | Spread out hotspots where possible, reduce local clutter and stockpiles, and profile CPU before assuming you only need more RAM |
| One player lags while the rest are fine | Usually client-side performance, mod download issues or that player’s connection | Check their client specs, local network and mod state before changing the whole server |
Tune it or upgrade: how to decide
The right move depends on what changed. If the world has merely aged, cleanup and restarts may buy you time. If the server was always overloaded for its world size, you are looking at a plan change or a new world design rather than a quick tweak.
| Sign | What it usually means | Do this |
|---|---|---|
| Memory pressure appears only after the world matures | You sized for launch day, not for a developed save | Upgrade RAM and keep maintenance routines in place |
| Performance is poor even on a fresh large world | The world size or build height is the mistake | Plan a smaller world on the next wipe; more RAM alone may not help enough |
| Restarts help a lot, but only for a while | Build-up over uptime is part of the issue | Increase restart frequency, run cleanup, then decide if more RAM is still needed |
| Busy towns hurt more than quiet parts of the map | Main-thread CPU is the constraint | Choose faster single-core hardware, not just a larger memory plan |
| Saves and backups cause the worst stalls | Storage is too slow or the world database is too heavy | Move to SSD storage and review backup handling |
| Problems appeared after adding mods | The mod list increased world-state and memory demand | Trim the list or add RAM headroom before the next busy phase |
Pre-launch checklist
- Pick the world size for the whole run, not the first few days. You cannot change it on the existing save later.
- Leave
MaxBuildHeightat 160 unless you have a clear reason and the hardware to support it. - Estimate not just total players, but how active they will be: industry, storage, laws and public builds all matter.
- Add headroom for mods from the start, especially if you expect the list to grow.
- Choose a plan with enough RAM for month two, plus strong single-core CPU performance.
- Set a restart schedule before launch, not after the first complaints.
- Watch backup growth and keep an eye on the Storage and Dump folders.
If your current setup looks fine on paper but wrong for the world you actually want to run, compare RAM, storage and CPU focus side by side before you commit. A mature Eco world punishes under-specced plans more than most survival games do.
Compare the best Eco server hostsEco server FAQ
How much RAM does an Eco server need?
For a fresh default 72×72 world, 4 GB is the official minimum and is fine as a starting point for a small group. In practice, many servers need more as the world ages, especially once you move to 100×100 or larger, add mods, or build an active town. Treat RAM as something that must match both world size and world age.
Can I change the world size of an existing Eco server?
No. World size is set when the world is generated, and changes to WorldGenerator.eco only apply to a new world. If you want a different size later, that means generating a new save rather than resizing the current one.
Is 4GB of RAM enough for an Eco server?
Yes for the official default-world minimum, but only in the narrow sense of a fresh 72×72 server. It is not a comfortable target for a larger world, a heavily modded save, or a community that keeps the same world alive for weeks. If you expect real growth, plan above the minimum.
Does an Eco server need a fast CPU?
Yes. Eco is unusually sensitive to single-core CPU speed because most heavy server work runs on one main thread. If the server lags in busy areas or under simultaneous activity, extra RAM will not solve that on its own.
Can I host an Eco server and play on the same PC?
Yes, but that machine must satisfy both client and server requirements at the same time. A 16 GB PC can cope with a fresh small world more realistically than a mature public one, because the client, server and operating system all compete for the same memory and storage. For anything beyond small co-op, a separate machine or rented server is usually the steadier option.
More Eco and server sizing guides
Our Eco host comparison, plus requirement guides for other survival games.
Written for Eco Update 14.2.1 (October 2026). Requirements, world sizes and config values come from the official Eco wiki, plus host sizing tables for larger worlds.
