Linux vs Windows game servers: which games need Windows

Run a game server on Linux whenever the game ships a Linux build, which most popular ones now do. Linux uses less memory for the operating system, costs nothing to license, runs comfortably in containers, and is what nearly every game host and panel is built on. Use Windows - or Windows under a compatibility layer - only when the server binary exists only for Windows, which is still true for a noticeable list of Unreal and Unity survival games: ARK: Survival Ascended, Conan Exiles, V Rising, Enshrouded, Space Engineers, The Forest, Sons of the Forest and Abiotic Factor among them. The rest of this post is the list, the reasons, and the practical differences that catch people moving a server from one to the other.

Why the operating system matters less than it used to#

Fifteen years ago the choice decided which games you could host at all. Today the server binary is usually a small, headless program that the developer builds for one or both platforms, and the operating system around it does three jobs: start it, give it memory and CPU, and get packets to it. Linux does all three with less overhead.

The point where it still matters is the binary itself. A developer either produces a Linux server build or they do not, and if they do not, you have three options: rent or run Windows, run the Windows build under Wine or Proton on Linux, or do not host that game. There is no setting that turns a Windows server into a Linux one.

How you find out is simple. Look at what SteamCMD downloads. If app_update on Linux fails with Invalid Platform, or the install directory contains only .exe and .dll files, there is no Linux build. The SteamCMD app IDs and beta branches post covers looking up an app's depots, which list the operating systems each one serves.

Which servers run where#

This list moves. Developers add Linux builds after launch (DayZ did, years after release), and occasionally a sequel drops what its predecessor had, as ARK: Survival Ascended did. Check the current state before you buy hardware or a licence on the strength of an old forum answer.

Memory, CPU and cost#

The overhead of the operating system itself is the most concrete difference:

On a machine with 8 GB, giving 2 GB to the operating system is a quarter of your capacity, which is real money when you are sizing a survival game that wants 8 GB on its own. On a big dedicated box with 64 GB it hardly matters.

CPU is close to a draw for the same build. Game servers are usually limited by one main simulation thread, and that thread runs just as fast on either kernel. Where people report one platform being faster, it is usually the game's own Linux build being less optimised than its Windows build, or the reverse - a property of how the developer compiled and tested it, not of the operating system. If the developer treats Linux as a second-class port, the Linux server may lag behind in fixes for a few days after a patch.

Cost is mostly licensing. Hosts pass on Windows licences as a monthly surcharge, and for a single small server that surcharge can be a large fraction of the bill.

Practical differences that break migrations#

These are the things that turn a "just copy the folder across" move into an afternoon.

Case-sensitive file names

Windows treats Mods, mods and MODS as the same folder. Linux treats them as three. A config that says @CBA_A3 while the folder on disk is @cba_a3 works on Windows and fails on Linux with a missing-file error that does not mention case at all.

This bites hardest with Arma 3 and DayZ, where mod folders arrive from the Workshop with mixed-case names and launch lines reference them by hand. The usual fix is to rename every mod folder and its contents to lower case and write the launch line in lower case to match. Minecraft plugin configs, Source engine map names and Lua require paths in Garry's Mod can all fail the same way.

Paths and line endings

Windows paths use backslashes and drive letters; Linux uses forward slashes from /. Configs copied across with C:\Servers\... in them need editing. Most games accept forward slashes on Windows too, so writing them that way from the start makes a config portable.

Scripts are the other trap. A start.sh written in a Windows editor ends each line with a carriage return, and Linux refuses to run it with a message like /bin/bash^M: bad interpreter. Convert it:

$ sed -i 's/\r$//' start.sh

Mods that ship native code

Most mods are data or scripts and run anywhere the game runs. Some include compiled native code, and native code is built for one platform:

• Arma 3 extensions are .dll on Windows and .so on Linux. A server-side mod that only ships the DLL simply does not load on a Linux server.
• SourceMod and Metamod extensions ship .ext.so and .ext.dll builds. Most popular ones have both; abandoned ones often have only one.
• BepInEx (Valheim and other Unity games) has separate packs per platform, because the loader itself is native code.
• Rust's Oxide and Carbon have Linux and Windows builds that must match the server.

Before moving a modded server, list every mod with a native component and confirm a build exists for the destination platform.

Shutting down cleanly

A clean stop is what saves the world. On Linux, the process receives SIGINT or SIGTERM, and well-behaved servers save and exit. On Windows, the equivalent is a Ctrl+C in the console window, and closing the window or ending the task does not save.

Some Windows-only servers handle signals badly under Wine, or not at all, which means a stop from the panel can behave like a kill. With those games, issue the in-game save command before stopping, or schedule one. The restart schedules that help post explains why a clean stop and a kill are different events.

File locking

Windows will not let you replace a DLL or a jar that a running process has open. Linux will, and the running process keeps using the old file until it restarts. On Windows that means you must stop the server to update a plugin; on Linux it means you can copy a new file in while it runs and wonder why nothing changed until the next restart. Both are fine once you expect them.

Running Windows-only servers on Linux#

Wine is a compatibility layer that lets Windows programs run on Linux by translating Windows API calls. For headless game servers it works surprisingly often, because a server needs far less of Windows than a game client does - no graphics, no sound, often no window at all. Proton is Valve's distribution of Wine with extra patches, and some servers run better under one than the other.

Most Windows-only servers in the list above have been run successfully under Wine by someone, and community Pterodactyl eggs for several of them use Wine images. Pterodactyl's Wings daemon itself only runs on Linux, so a Windows-only game on a typical panel host is a Windows binary running under Wine in a Linux container rather than a Windows machine. The costs are a little extra memory, a slower first start while Wine sets up its prefix, occasional breakage when the game updates, and a support story that ends at "not supported by the developer". The full set-up, the packages and the failures are in Wine and Proton for Windows-only servers.

Space Engineers is the hard case: its server leans on the .NET Framework, and getting it stable under Wine has historically taken community-maintained containers and patience. For games like that, a real Windows machine is the boring and reliable answer if you are self-hosting.

Admin experience on each#

Linux administration happens over SSH, with logs in files, a service manager such as systemd starting the server, and everything scriptable. It has a learning curve if you have never used a shell, and Linux commands for server admins is the shortest path through it.

Windows administration happens over RDP, which is easier to start with because it looks like a desktop, and harder to automate well. Running a server as a service needs a wrapper such as NSSM or a scheduled task, logs often end up in a console window that disappears when it closes, and Windows Update will restart the machine on its own schedule unless you configure it not to. An exposed RDP port is also one of the most attacked services on the internet, so it belongs behind a firewall rule that only admits your own address - see firewall rules that matter.

With a game panel, most of this disappears in both directions. You get a console, a file manager, SFTP and schedules in a browser regardless of what runs underneath. On RE:NODE every server is its own container on Pterodactyl and Wings, with the live console, the file manager and per-server SFTP on every plan, so the operating-system question only affects you when a mod needs a native build or a path is written for the wrong platform. The Pterodactyl panel explained post goes through what that container model gives you and what it rules out.

Moving a server from Windows to Linux#

The most common migration is a server that started on someone's Windows PC moving to a Linux host. A checklist that covers most games:

1. Stop the Windows server cleanly and confirm in its log that the world saved.
2. Copy the save folder and configs, not the server binaries. Install the Linux server fresh with SteamCMD or the panel; Windows executables are no use on the other side.
3. Find where the Linux build keeps saves. It is often a different path - under the home directory rather than AppData - so the world goes into a new location. Game server save files explained lists them.
4. Fix paths in configs. Replace drive letters and backslashes; prefer relative paths.
5. Normalise mod folder names and make the launch line match their case exactly.
6. Check native mods for Linux builds, and replace or drop the ones without.
7. Convert scripts to Linux line endings and make them executable with chmod +x.
8. Start and read the log from the top, looking for missing files, failed mod loads and a line confirming the right world was loaded.

Expect the first start to take longer, because the Linux server may regenerate caches or convert data. Do not let players in until you have walked around the world and confirmed it is the one you moved.

Deciding, game by game#

1. Does the game ship a Linux server? If yes, use Linux. There is rarely a reason not to.
2. If not, does it run under Wine reliably? Look for a maintained community egg or container image updated in the last few months. If there is one, Linux with Wine is usually fine for a small group.
3. If it is fragile under Wine, or you need to run Windows-only admin tools beside it, use Windows. Budget for the licence and for 2 GB of memory going to the OS.
4. If the server is heavily modded, check every native-code mod against the platform before deciding. The operating system you pick is the one your mods have to support.

For most people renting rather than building, the decision is already made by the host: you pick the game, and the host runs it on whatever works. What remains your problem is the list in the previous section - case, paths, line endings and native mods - because those come with the files you upload.

FAQ#

Is a Linux game server faster than a Windows one?

For the same game build on the same hardware, the difference is small, and usually comes from how well the developer optimised each build rather than from the kernel. Linux does leave more memory for the game, because the operating system itself uses less.

Can I move my world from a Windows server to a Linux one?

Usually yes. Save files are generally the same format on both platforms. What needs attention is configs with Windows paths, mod folder names whose case does not match the config, and any mod that ships a Windows-only DLL.

Why does my Linux server say a mod is missing when the folder is right there?

Almost always letter case. Linux treats @MyMod and @mymod as different folders. Make the name on disk and the name in the launch line match exactly, ideally both in lower case.

Do Windows-only servers work on Pterodactyl panels?

Many do, by running the Windows build under Wine inside a Linux container. Support depends on the game: some run cleanly, a few are unstable, and the developer will not help with either. Check that a maintained egg or image exists.

Do I need Windows Server, or will Windows 10 or 11 do?

For a home server for friends, desktop Windows runs dedicated servers perfectly well. Windows Server matters when you want it in a data centre with remote-desktop licensing and no forced feature updates, and that is when the licence cost becomes the main argument for Linux.