In May 2026, developer Ivan Bogomolov published a short post on his personal blog noting something striking: a full 3D Godot 4 game engine, complete with GL Compatibility renderer, Jolt physics, GDScript runtime, and a narrative interpreter, exported to WebAssembly at just 35MB.

For comparison:

• The default Node.js Docker image weighs 421MB.

• Facebook's homepage loads 44MB of resources.

• The game engine came in under both.

His post posed a natural follow-up question: if a full game engine compiles to a fraction of a bare-bones Docker image, can WebAssembly be used as a container for game servers too?

The short answer is: not yet. Here is why.

What Is WebAssembly?

WebAssembly (WASM) is a binary instruction format designed to run in browsers at near-native speed. It was built as a compilation target: you write code in another language (Rust, C, or C++), compile it to WASM, and the result runs across any environment that supports a WASM runtime. No install required, no OS-specific build, consistent behavior everywhere.

That portability is the appeal. A single binary that runs in Chrome, Firefox, on a server, or on an edge node sounds like exactly what a containerized deployment workflow needs. In practice, the gap between "runs anywhere" and "runs a game server" turns out to be significant.

The Size Case: 35MB for a Full Game Engine

The numbers are worth sitting with. A full 3D game engine at 35MB, versus 144MB for a slim Python base image before you add a single dependency, versus 421MB for Node.js latest. For comparison, Facebook's homepage loads 44MB of resources. The game engine is smaller than all of it.

The size difference matters for real operational reasons. Smaller binaries mean faster game server cold starts (how long it takes for the image to download to a server host and spin up a game instance). For studios running their own orchestration, egress costs on image delivery are also a minor consideration, though on managed platforms that cost is absorbed by the provider rather than billed to the studio.

For studios who have built their own internal orchestration, such as those using Agones, cold-start time and registry capacity are constraints that require deliberate engineering investment to address. On managed platforms, these are solved by design: for example Edgegap’s platform boots game servers from cold start in an average of 3 seconds and includes a 10GB container registry. Studios curious about how egress factors into their specific infrastructure costs can explore how it affects their setup via Edgegap's pricing using our game server hosting calculator.

That efficiency argument is what makes WASM worth taking seriously as a server technology. The problem is that binary size is only one dimension of what a game server needs.

The Server Problem Starts with WASI

To run outside a browser, WebAssembly needs an interface to the underlying operating system.

That interface is WASI: the WebAssembly System Interface. WASI is what lets a WASM binary access files, environment variables, and standard I/O when running on a server runtime instead of a browser sandbox.

The catch is what WASI currently restricts. TCP and UDP sockets are either unavailable or severely limited depending on the runtime and language combination. The filesystem access model is capability-based and tightly sandboxed. For a web API or a serverless function, those constraints are manageable. For a game server, they are blockers.

Multiplayer game servers live on sockets. They need raw UDP for fast, low-overhead packet delivery. They also need filesystem access for configuration, logging, and state persistence.

WASI, as it stands in 2026, does not provide reliable access to either at the level game servers require. As Bogomolov noted plainly in his post: "wasip1 is still preview, no sockets in the standard runtime."

The language support picture compounds this: only Rust and C/C++ are practical WASM compilation targets today. Go's wasip1 support is still in preview. Zig is not there yet. That constraint alone limits which studios can even attempt a WASM server build.

Threading Without Threads

Game servers are not single-threaded programs. Physics simulation, network I/O, game state replication, and player input processing typically run concurrently. Engines are designed around this assumption.

WebAssembly's threading support is limited. The mechanisms that exist require workarounds at the application layer, using interrupts and cooperative scheduling to approximate concurrent execution. The result is not equivalent to real OS threads. It introduces coordination overhead, increases code complexity, and makes debugging harder under load.

A studio that solves WASI's socket restrictions still must address threading before their game server can function correctly at scale. These are not minor integration tasks. They are fundamental architectural gaps in the current WASM specification.

Even If You Solve All That: The WebSocket Wall

Suppose a team invests the engineering effort to work around WASI's socket limitations and builds a threading model that holds up under pressure.

There is still one more wall: WebSockets.

WASM server runtimes communicate over WebSockets by default. WebSockets run over TCP, adding a persistent connection layer with its own handshake overhead, framing, and security negotiation on top of every message. For browsers, this is acceptable. For game traffic, it is expensive.

Games use UDP over TCP for a reason. UDP is lightweight and fast, with no handshake, no guaranteed delivery overhead, and no head-of-line blocking. A packet that arrives late is dropped, which is far preferable to a stalled connection waiting for retransmission. The entire discipline of game netcode, from lag compensation to rollback, is built around the properties of UDP.

Routing game traffic through WebSockets instead erases much of the performance advantage WASM's small binary size was supposed to deliver. The server ends up spending CPU cycles on WebSocket overhead, or running into DNS resolution issues at scale, or generating egress costs that make the deployment economically difficult to justify.

Plugin Compatibility: The (Hidden) Porting Tax

Beyond the infrastructure constraints, there is a practical development cost that studios rarely account for upfront. Most asset store packages, engine plugins, and third-party SDKs do not compile to WebAssembly automatically. They target native platforms: Windows, Linux, macOS.

Porting them requires manual work. The community support for WASM game development is thin compared to Docker-based deployments. Documentation is sparse, tutorials are rare, and edge cases tend to stay undiscovered until a team is already deep into a project.

For studios with significant plugin dependencies or teams without deep systems programming backgrounds, the porting burden alone can make a WASM server approach impractical regardless of the theoretical efficiency gains.

Where WASM Actually Fits Today: Singleplayer WebGL Games

There is one context where WASM sidesteps every limitation above: client-side, singleplayer web games.

A singleplayer game running in a browser does not need raw UDP sockets. It does not need OS-level threading. It does not need to interact with a plugin ecosystem built for native targets. The browser provides a controlled environment where WASM's constraints are simply not relevant to the use case.

Godot makes this concrete. The engine exports to WebAssembly by default for its web target. A singleplayer Godot game ships as a 35MB binary that runs in any modern browser with zero installation. For Linux server deployment, Godot exports a native binary instead. The distinction is not incidental: it reflects exactly where WASM's current capability ceiling sits.

The Rust and WebAssembly ecosystem tells a similar story. One of the most widely referenced WASM learning resources is the official Rust and WebAssembly book, which walks through building Conway's Game of Life as a browser-based WASM project. It is a canonical example of the technology working well. It is also a singleplayer, browser-bound application with no server-side networking requirements.

WASM is a genuine fit for singleplayer web games. Multiplayer backends are a different problem entirely.

An Informed Opinion: The Adoption Curve

The infrastructure for running WASM as a server-side technology already exists, at least in experimental form. Cloudflare Workers runs WASM modules at the edge. containerd/runwasi brings WASI workload support to containerd. KWasm adds WebAssembly support to Kubernetes nodes, though its own maintainers currently recommend against using it in production. The tooling is being built, carefully.

This trajectory resembles how ARM nodes entered the cloud infrastructure conversation. ARM offered real advantages in cost and density for years before it became a default choice for cloud workloads. The technical case was clear early. Adoption lagged for reasons of ecosystem maturity, toolchain support, and organizational inertia. Then it did not.

Whether WASM follows the same arc for game servers is, to be clear, an opinion rather than an established pattern. The current limitations are concrete and documented. What changes them, and on what timeline, depends on decisions across browser vendors, runtime maintainers, and standards bodies. Bogomolov ends his post with the same open question: "Why has WASM adoption stalled? The transfer-size case is already there."

It is a fair question. The answer, for game servers specifically, is that binary size was never the only problem.

What You Can Do Today

WASM is not a viable game server container in 2026. Docker remains the practical choice for studios deploying dedicated multiplayer servers, and the operational tooling around it is mature, well-documented, and widely supported.

That said, the efficiency question his observations raise is a real one. Server binary size does matter for cold-start performance and egress costs, and there are practical steps studios can take with existing tooling. For Unreal Engine, Edgegap has published a guide on analyzing and optimizing game server builds through server profiling. For Unity, server build optimization guidance is covered directly in Edgegap's documentation.

The gains WASM might one day offer on the size front are achievable with existing tooling today, without waiting for the ecosystem to mature.

—

This article is sourcing an original post by Ivan Bogomolov, published on his personal blog. All rights in the original content are owned by their respective owners.