Icarus Dedicated Server Requirements and RAM by Player Count
RocketWerkz tells you how to install an Icarus dedicated server but not how much memory it needs, and the 16 GB on Steam is for the game, not the server. Here is what hosts’ figures show about RAM, CPU and slots, and why your world’s age matters more than your headcount.
RocketWerkz publishes the SteamCMD app ID, default UDP ports, config path and the hard session cap of 8 players. It does not publish an official dedicated server RAM or CPU requirement.
Hosts commonly place Missions and fresh Open Worlds around 8 GB, shared Open Worlds up to 8 players around 12 GB, then 16 GB or more once the world is old, busy and base-heavy.
Player count matters, but world age matters more. A quiet lobby uses very little memory; a long-running Open World with tames, farms and machinery keeps far more state resident in RAM.
Buy for the save you expect to have after a few weeks, not just day one. Prefer strong per-core CPU, SSD or NVMe storage, and an easy restart schedule over inflated slot numbers.
What RocketWerkz actually publishes
RocketWerkz gives you the basics needed to install and run the server, but not a full hardware spec sheet. The dedicated server is installed with SteamCMD using app ID 2089300, it can be installed with login anonymous so no Icarus licence is needed for the server install itself, and the Windows executable is IcarusServer.exe. If you want a visible log window, add -Log to the launch command.
force_install_dir C:\IcarusServer login anonymous app_update 2089300 validate
Default ports are game 17777 and query 27015, both over UDP. You can change them with -PORT= and -QueryPort=, and you can set the browser name with -SteamServerName=”…”. The wiki also states that SessionName in the ini currently does nothing, so the launch argument is the one that matters for naming.
IcarusServer.exe -SteamServerName="Friday Crew Server" -PORT=17777 -QueryPort=27015 -Log
The main config file is stored at Saved\Config\WindowsServer\ServerSettings.ini. By default the Saved folder sits in %localappdata%\Icarus\, though that can be changed with -UserDir=. MaxPlayers can be set from 1 to 8; that 8-player cap is hard enough that it should shape your buying decision from the start.
The important missing piece is the one most renters want first: RocketWerkz does not publish an official RAM or CPU figure for the dedicated server. That is why the Steam store’s 16 GB minimum and 32 GB recommended memory figures get misquoted so often. Those are the client requirements for playing Icarus on a PC, not an official dedicated server requirement. The store also lists 70 GB storage for the client, again not a formal server storage spec.
There are a few security and admin defaults worth fixing early. If AdminPassword is left empty, anyone can use /AdminLogin and gain admin rights. If JoinPassword is empty, the server is open. Neither setting changes performance, but both are basic housekeeping for a rented or self-hosted machine.
Why player count is only half the story
Icarus caps at 8 players, so unlike games where you scale from a handful of players to dozens, the bigger variable here is not “how many slots?” but “what state is the world in?”. A dedicated server runs one prospect at a time. When no prospect is loaded, players land in the lobby, and hosts report that this state uses very little memory compared with a live prospect.
Mode matters a lot. Missions are temporary prospects with a timer and a cleaner lifecycle, so they tend to stay lighter. Open World is persistent, which means every extra structure, inventory, tame, farm plot, machine and electricity network adds more state to hold in RAM and more simulation work for the CPU. Outposts are persistent too, so how heavy they get depends on how much you build there over time.
World age matters just as much as mode. A fresh Open World can fit into the same bracket as Missions, then quietly grow into a very different server after a few weeks. That is why two groups of the same size can need different plans: one crew may have a simple shelter and a few benches, while another has spread across several biomes with tame pens, crop runs and a lot of placed objects.
If you want the wider logic behind that, how game server hardware requirements work is the useful lens: RAM holds world state, CPU advances simulation, disk handles saves and updates, and bandwidth moves state changes to each connected player. In Icarus, the age and complexity of the prospect push RAM harder than the raw slot number does.
The diagram below is the practical way to think about it before you buy.
| Grows with… | RAM | CPU | Disk |
|---|---|---|---|
| More players (1 to 8) | Partly | Yes | No |
| Open World age and base size | Yes | Partly | Yes |
| Tames, farms, machines, power networks | Yes | Yes | Partly |
| Creatures and storms on screen | Partly | Yes | No |
| Weekly patches and backups | No | No | Yes |
| Sitting in the lobby, no prospect loaded | No | No | No |
RAM by player count and mode
Because there is no official server RAM figure, the best practical guide is the published sizing from several hosts and the published usage figures from one host’s own fleet. Read these as host guidance, not as rules from RocketWerkz. They are still useful because they show the breakpoints where worlds stop behaving like a fresh save and start behaving like a long-running server.
Use this as the short version first.
| Situation | Published guidance | Why usage lands there | When to step up |
|---|---|---|---|
| Lobby, no prospect loaded | One host says its demo server sat at under 1 GB waiting in the lobby. | Very little world state is resident because the server is not simulating an active prospect. | No upgrade decision should be based on lobby usage. It is the lightest state the server will ever be in. |
| General real-world baseline | A larger host measured 2.0 GB typical usage (median) and 5.2 GB busy usage (90th percentile) across 12 Icarus servers over 30 days, sampled every 20 minutes. | This shows that many ordinary sessions are not huge memory consumers, but busy periods spike well above the quiet baseline. | Treat this as context, not a buying target. It shows why a server can look fine at first and still need headroom later. |
| Missions or a fresh Open World, up to 4 players | One host’s sizing guide says 8 GB. Another host’s plan list gives 9 GB for 4 slots. | Fresh worlds keep less persistent state in memory and have fewer objects, machines and tames to track. | Move upward once the base spreads, the crew grows, or long sessions start finishing close to the memory limit. |
| Shared Open World, up to 8 players | The sizing guide says 12 GB. The plan list also gives 12 GB for 8 slots. | The full crew can make more areas active at once, while a persistent world accumulates more placed structures and inventories. | If memory sits near the limit during your usual busy sessions, the sizing guide advises moving to 16 GB. |
| Long Open World saves with big bases | The plan list adds 15 GB for 8 slots “for long Open World saves with big bases”. | The extra memory is not buying more players; it is buying room for an older, heavier save. | Step up when restarts only briefly help or when the world is clearly base-heavy rather than just temporarily busy. |
| Mature Open World with many tames and machines | The sizing guide says 16 GB. | Tames, inventories, production chains and long-lived structures all add persistent state that stays relevant every time the prospect loads. | Heavy farming and electricity networks may want 20 GB. |
| Large bases across several biomes | The sizing guide says 20 GB. | Spread-out, old worlds can keep a lot of data hot and create heavier save and load cycles. | At this point, more RAM is about world complexity, not the fixed 8-player cap. |
The useful pattern is simple: for Icarus, RAM scales more with world persistence than with headcount. A 2-player mature Open World can justify more memory than an 8-player Mission server, because the save itself is doing the heavy lifting on memory use.
Why slot counts on a plan mean very little
For Icarus, any plan advertising more than 8 slots is noise. RocketWerkz caps MaxPlayers at 8, so you are not paying for actual extra capacity if a panel offers higher slot numbers. Compare plans on memory and processor class instead.
This is also why host sizing can look odd at first glance. One host lists 9 GB for 4 slots and 12 GB for 8 slots, while another adds a heavier 15 GB option for long Open World saves with big bases. The extra cost is not about unlocking more players. It is about keeping enough headroom for a more complex prospect.
When you compare packages in our Icarus server hosting comparison, filter the marketing language out. Ask four things instead: how much RAM is included, what class of CPU is behind the plan, is the storage SSD or NVMe, and how easy is it to restart or update the server after the game’s frequent patches.
CPU: per-core speed matters more than extra cores
Hosts are broadly aligned on CPU advice for Icarus: strong per-core performance matters more than chasing a high core count. That usually points you towards newer, faster desktop-style CPU cores rather than a slower many-core box. One host even reserves its fastest 5.0 GHz+ processors for a full crew in big bases with lots of creatures and storms on screen.
The reason is how this kind of survival server tends to work: much of the world simulation has to advance step by step on a small number of busy threads, so the speed of one core sets the pace. Creatures, pathing, storms, structure interaction and players spread over different parts of the map all increase CPU work. Extra cores still help with background tasks, save handling and the operating system, but they do not replace fast single-thread performance.
How do you tell CPU is the problem rather than RAM? If the server feels fine after a restart and still has memory headroom, but performance falls apart when storms hit, when many creatures are active, or when the crew splits across distant areas, that points more towards CPU pressure. The player-facing symptom is usually hitching or rubber-banding during busy moments rather than a steady slide into late-session instability.
The trade-off is cost. Faster per-core plans are often dearer than generic plans with slower processors. In Icarus that premium usually buys something real, while extra nominal slots do not.
Disk, saves, updates and network
Disk requirements are less dramatic than RAM or CPU, but they still matter. The community Pterodactyl egg recommends 8–16 GB RAM and at least 14 GB storage depending on save size and save frequency, which is a decent floor for the server files themselves. Beyond that, leave room for prospect saves, backups and updates. Hosts commonly provide up to 100 GB of NVMe storage, which is useful headroom rather than something Icarus always consumes.
SSD or NVMe matters because the server writes saves, loads prospects and applies patches. Faster storage will not magically raise your player cap, but it does cut friction around save operations, restarts and weekly updates. Slower disk tends to show up as longer downtime and less responsive save handling rather than as a clean FPS-style bottleneck.
Updates matter more than raw storage size because RocketWerkz patches the game most weeks. If your server stays on an older build, players who have updated their clients cannot join. Build management is therefore part of the real hosting requirement: pick a host or self-hosting routine that lets you patch promptly.
On networking, the essentials are straightforward: open UDP 17777 for game traffic and UDP 27015 for query traffic unless you have moved them. Server location affects ping more than anything else you can tune in the panel. A nearby region reduces latency and makes movement and combat feel cleaner, while a distant machine turns every small delay into a more noticeable stutter.
Prospects are saved as .json files under Saved/PlayerData/DedicatedServer/Prospects/. Do not rename or hand-edit them unless you are willing to risk corruption. For server administration, a clean backup routine is safer than improvised file editing.
Self-hosting on your own PC: when it works
Self-hosting Icarus is viable, but only if you remember that the server and the client are competing for the same machine. The client’s own published requirement is 16 GB RAM minimum and 32 GB recommended, and those figures are before you add the dedicated server process on top. That is the main reason “I can run the game” does not automatically mean “I can host a long-lived Open World on the same PC comfortably”.
The easiest route is the Windows server build. On Linux, people commonly run the Windows build under Wine, and the Pterodactyl community egg reflects that approach. It also notes a recent x86-64 CPU and no 32-bit or ARM support, which matters if you were hoping to repurpose lightweight hardware.
When does same-PC hosting make sense? Mostly for small groups, shorter sessions and lighter worlds: a couple of players, Missions, or a fresh Open World, on a machine with spare RAM and a strong CPU. When does it stop making sense? Once the world is mature, the sessions are long, or the game and server together are pushing memory pressure high enough that the operating system starts trimming caches, paging aggressively or stalling under combined load.
If you do self-host, keep the machine’s background load low, place the server on fast storage, and be realistic about world growth. A setup that feels fine for a new save can become uncomfortable weeks later without any change in player count.
How to tell you have outgrown your RAM, and what to do first
Icarus gives you a few operational tools before you reach for a bigger plan. ResumeProspect is enabled by default, so the last prospect can reload automatically after a restart. ShutdownIfNotJoinedFor and ShutdownIfEmptyFor both default to 300 seconds. During that window the game is paused; when the timer expires the server shuts the prospect down and returns to the lobby. Set either value below zero and the prospect stays loaded indefinitely, which suits nobody unless your crew wants the world to keep running while they are away.
[/Script/Icarus.DedicatedServerSettings] MaxPlayers=8 ShutdownIfNotJoinedFor=300 ShutdownIfEmptyFor=300 ResumeProspect=True
Why this helps is simple: an unloaded prospect is lighter than a live one. Letting an empty server pause and unload means you are not leaving a heavy Open World resident in memory all day for no reason. The trade-off is that the next player to join may need to wait for the prospect to come back up. With ResumeProspect=True, that delay is usually worth it because the server returns to the last active world automatically instead of forcing manual admin steps.
A scheduled daily restart at a quiet hour is the next low-risk fix, especially for older Open Worlds. Player reports and host guidance both point in the same direction: long sessions can see memory climb over time. A restart clears stale allocation pressure, reloads the prospect cleanly and gives you a repeatable baseline. If that stabilises the server for most of the day, you have learned something useful: the issue is probably cumulative memory pressure rather than a permanently undersized machine.
The flow below shows the order of checks that saves money first.
| Symptom | Likely cause | First fix |
|---|---|---|
| Memory sits near the plan limit during normal sessions | The world has outgrown its starting RAM band; persistent state from bases, tames and machines is filling available memory. | Schedule a daily restart and let empty-server shutdown return the prospect to the lobby. If memory still rides the ceiling, move up one RAM tier. |
| Rubber-banding gets worse late in long Open World sessions | Often memory pressure building over time, though heavy CPU moments can look similar. | Restart at a quiet hour with ResumeProspect left on. If the problem returns only after long uptime, prioritise more RAM; if it happens mainly during storms or when players split up, prioritise CPU. |
| Crashes or instability after the server has been up for a long time | Long-session memory growth or a world that is too large for the current plan. | Keep the automatic unload timers at 300 seconds unless you have a reason to run indefinitely, then step up RAM if restarts stop being enough. |
| Server feels bad only when lots of creatures, weather and spread-out players are active | CPU bottleneck rather than pure RAM shortage. | Choose a plan with stronger per-core performance instead of chasing more slots or background features. |
| Server is fine in the lobby but struggles once the prospect loads | The issue is world complexity, not the basic server process. | Judge usage from the loaded prospect, not lobby figures. Upgrade based on your heaviest world state. |
In short: tune first, upgrade second. If a restart plus sensible unload behaviour makes the server stable again, keep the cheaper plan. If those measures only buy a short reprieve, the world has simply grown beyond the original RAM target.
Use published RAM and CPU detail to compare packages, and ignore any plan trying to sell Icarus on slot count alone.
Compare the best Icarus server hostsPre-purchase checklist
| Check | What to choose | Why it matters |
|---|---|---|
| Expected mode | Missions or fresh Open World: start around 8 GB; shared Open World up to 8 players: look at 12 GB; mature Open World: 16 GB or more as needed. | Mode and world age affect RAM more than the fixed player cap does. |
| Player cap | Ignore anything above 8 slots. | Icarus cannot use more than 8 players in one session. |
| CPU | Prefer stronger per-core performance. | Busy simulation moments are usually limited by thread speed, not by having many slow cores. |
| Storage | SSD or NVMe, with at least 14 GB available and headroom for backups and updates. | Fast storage helps saves, restarts and weekly patching. |
| Location | Pick the nearest sensible region for the group. | Lower ping improves responsiveness more reliably than most panel tweaks. |
| Restart controls | Make sure you can schedule restarts and leave ResumeProspect enabled. | That is the cheapest fix for long-session memory creep. |
| Updates | Choose a setup that makes weekly patching easy. | Players on a newer build cannot join an older server build. |
| Security | Set AdminPassword and decide on JoinPassword. | Blank admin settings can hand control to anyone who joins. |
| Map ownership | If you plan to run expansion maps such as Prometheus or Elysium, confirm the group owns the relevant expansion. | Server availability is no help if part of the crew cannot access the chosen map. |
Icarus server FAQ
How much RAM does an Icarus dedicated server need?
There is no official RocketWerkz RAM figure for the dedicated server. Practical host guidance puts Missions and fresh Open Worlds around 8 GB, shared Open Worlds up to 8 players around 12 GB, and mature base-heavy Open Worlds around 16 GB or more. Buy for the age and size of the world, not just the day-one player count.
How many players can join an Icarus dedicated server?
An Icarus dedicated server supports from 1 to 8 players, with 8 as the maximum. That hard cap means plans advertising more than 8 slots do not provide extra usable capacity for Icarus sessions. Compare RAM and CPU instead.
Is 8 GB enough for an Icarus server?
Yes, 8 GB is a sensible starting point for Missions or a fresh Open World, especially for smaller groups. It is less comfortable once the server becomes a long-running shared Open World with larger bases, more tames and more machinery. If the world is expected to persist and grow, plan for the likelihood of moving up later.
Does an Icarus server need a fast CPU?
Yes. Hosts consistently recommend strong per-core speed because Icarus server performance is shaped more by simulation thread speed than by high core counts alone. CPU pressure shows up most clearly in storms, creature-heavy moments and sessions where players are spread across different areas.
Can I run an Icarus dedicated server on the PC I play on?
You can, but only if the machine has enough spare RAM and a strong enough CPU after the game client has taken its share. The client alone has a published minimum of 16 GB RAM, so same-PC hosting is best kept to lighter worlds and smaller groups. Mature Open Worlds are far better candidates for a separate rented server or a separate host machine.
More Icarus server help
Compare hosts, or read how game server hardware is sized in general.
RocketWerkz does not publish a server RAM figure, so every memory number on this page is hosts’ published sizing or measurement from October 2026, not an official requirement. Patches arrive most weeks; if a future update changes the server’s footprint, the logic still holds: size for your world’s age, not your slot count.
