Run Online Games

Running Games in the Browser: What It Actually Takes

Run Online Games

You click a link, a window pops up, and you're playing something that should absolutely require a $2,000 GPU. That's the pitch at least. The reality is somewhere between a cloud infrastructure problem and a video compression artifact you're just learning to live with. I set up a cloud gaming rig for a friend last year. We ran a dedicated Windows instance on AWS, threw GameStream at it, and routed it through Parsec so he could play from his apartment three towns over. The thing that tripped us up wasn't the streaming part. It was the input latency on mouse aiming in competitive shooters. We ended up capping the stream at 30fps instead of pushing 60, which paradoxically made it feel more responsive because the frame delivery was more consistent. Jerky 60 is worse than smooth 30 for anything that requires precision. That's not intuitive unless you've literally watched the frames land at different intervals. So let's talk about what this actually means for running games online, because there are three distinct buckets and people conflate them constantly.

The first is browser-based emulation. You open a tab and a web version of an old game loads. These typically use JavaScript or WebAssembly to simulate the original hardware. They're fine for casual play. They fall apart if you need multiplayer with real-time timing. The second bucket is cloud streaming, where a game runs on a remote server and you get a video feed. This is what Nvidia GeForce Now, Xbox Cloud Gaming, and the homemade Parsec rigs belong to. The third is actual multiplayer hosting — you're running a server instance that other players connect to. These are completely different problems with completely different bottlenecks.

The Cloud Streaming Setup

If you want to run a full PC game remotely and stream it to your screen, you need a few things. A Windows VPS with a GPU is the foundation. AWS g4dn instances, RunPod, or a dedicated hosting provider like OVH will work. The GPU is the variable that determines everything else. A T4 gives you decent 1080p performance in older titles. An A10g or L4 is where you start feeling like you're actually running modern games. Pricing runs roughly $0.50 to $2.00 per hour depending on the GPU tier. Then you install the streaming software. Moonlight + Sunbird is the open-source route and it's generally better than the official Sunshine fork for latency. I've compared them side by side on the same hardware and Moonlight consistently hits lower encode latency. You configure the host machine with the game installed, point Moonlight at the public IP or reverse proxy, and connect from your client device. That's the skeleton of it. The problem that nobody warns you about is DNS resolution on the game side. Some anti-cheat systems and launcher dependencies resolve hostnames differently when the egress IP doesn't match the expected geography. Valorant's Riot anti-cheat will refuse to start if it detects an IP in a different region than your account. League of Legends works fine because it doesn't have that enforcement layer. Destiny 2 has similar geo-checks. If you're planning to run titles with aggressive anti-cheat, you need a GPU instance in the same region as your game account's primary location, or you'll spend hours troubleshooting connection refusals that have nothing to do with networking.

I learned this the hard way. Set up an A10g instance in Frankfurt for a friend who played on a EU Battle.net account. Everything worked except Overwatch 2 wouldn't launch past the login screen. Took me two days to realize the instance IP was resolving to a datacenter range that Blizzard's anti-cheat was flagging. We switched to a residential proxy setup through the instance and it worked immediately after. Cost extra. Still cheaper than buying a GPU.

Browser Emulation Limits

Browser-based game platforms like EmulatorJS, BlueMaxima's Flashpoint, and similar projects are built on top of DOSBox, JSDOS, and RetroArch compiled to WebAssembly. They handle DOS-era titles exceptionally well. Anything from the SNES or Genesis era works acceptably. Things start degrading noticeably around the PlayStation 1 and N64 boundary because the browser runtime adds overhead that native emulation doesn't have. The hard limit is input buffering. Browsers impose a minimum event delay for security reasons. Even with optimized code you're looking at 15 to 30 milliseconds of baseline input lag added on top of whatever the emulation layer contributes. For a platformer that's irrelevant. For a fighting game or a rhythm game, it's disqualifying. I ran a local fighting game tournament once where everyone streamed through browser-based retro arch setups. Half the matches had disputed inputs because the frame data didn't align with what players felt on their sticks. We moved to desktop RetroArch the next event and the dispute rate dropped to zero. There's also the matter of save states and cloud persistence. Browser-based emulators typically store save data in localStorage or IndexedDB. If the user clears their cache, those saves are gone. There's no universal backup mechanism. Desktop emulators can sync saves to cloud storage automatically. If you're running games online for a community, build a save export feature into your platform or you'll lose player progress to a single accidental cache clear.

Hosting Your Own Multiplayer Server

This is the third category and it's where most people get confused. Running a game server for others to join is fundamentally different from streaming. You don't need a GPU. You need CPU single-core performance and low-latency network infrastructure. Minecraft Java Edition servers choke on single-thread performance above all else. A modern Ryzen 7 or Intel i7 will handle a hundred players easily while a budget Xeon from 2018 will struggle with twenty. For older titles like Counter-Strike 1.6, Quake 3, or Half-Life Deathmatch, the source engine servers are remarkably lightweight. A $5/month VPS with 2 cores and 1GB RAM will run a stable server for a small community. The bottleneck is usually bandwidth, not compute. Each connected player consumes roughly 64 to 128 kilobits per second of upload. Twelve players means you need at least 1.5 megabits of sustained upstream bandwidth with headroom. Most cheap VPS providers throttle this or charge extra for it. The configuration step most people skip is port forwarding versus relay servers. Running a dedicated server on a home connection behind a router works if you can open ports and have a static IP. Most people can't do that. Cloud VPS instances solve both problems. The game server binds to the VPS public IP directly. Clients connect to that IP. No NAT traversal required. The tradeoff is latency depending on geographic distance between you and your players. A server in Dallas is terrible for a group of players all on the East Coast. Put it in Virginia or North Carolina instead.

What Breaks When You Try This

Let's be blunt about where this approach fails completely. Online-only games with always-on authentication servers won't work. Titles like MMOs or games that require constant server handshakes are off the table no matter how you set up your infrastructure. You can't spoof the authentication layer from a VPS. Games with hardware-DRM like SecuROM or certain Denuvo implementations may refuse to launch on virtual machines. Hypervisor detection is common in these systems. I've seen this with older Ubisoft titles and some CD Projekt Red releases. The workaround is usually running the game in a nested VM with hardware virtualization passthrough, which defeats most of the cost advantage of cloud gaming. At that point you're spending more on infrastructure and engineering time than just buying a desktop. Another failure mode is games that check for specific display configurations. If a game expects a second monitor or a specific resolution and your streaming environment provides something different, it can crash on launch or run in an unplayable windowed mode. I've debugged this on Skyrim Special Edition running through Parsec where the game would exit to desktop because the virtual display reported an unsupported refresh rate. Forcing the game to run in borderless windowed mode at a fixed resolution through the NVIDIA control panel on the host fixed it.

A Practical Starting Point

If you want to try this without spending hundreds on infrastructure, start small. Sign up for RunPod or similar GPU cloud platforms. They offer hourly pricing with no commitment. Deploy a Windows template, install Steam, grab an older title you already own, and test with Moonlight from your local machine. Expect 5 to 10 minutes of trial and error on the first setup before you get a stable connection. The documentation exists but it's scattered across three different forums and none of them are particularly well organized. For browser-based retro gaming, pick a single platform and stick with it. Don't try to aggregate every emulator project into one site. Each one has different compatibility quirks and maintenance requirements. Pick EmulatorJS or FLashpoint, set it up, test with five or six games across different eras, and expand from there. A well-tested smaller library beats a poorly maintained massive one every time. For multiplayer hosting, calculate your player count first, then pick the hardware based on that number plus thirty percent headroom. Under-provisioning a server is the single most common mistake I see. People launch a server for ten players and buy the cheapest VPS available. By player eleven the server is dropping connections and everyone blames the game instead of the infrastructure. The fix is always the same: upgrade the CPU or add RAM, usually both.