Pixel Streaming & the Cloud

Think of it as a two-way pipe. Your packaged Unreal application runs on a cloud machine with a real GPU. Instead of drawing to a monitor, it hands each rendered frame to a hardware video encoder (NVIDIA's NVENC on the server's GPU), which compresses it to an H.264/H.265 stream. That video is sent to the viewer over WebRTC - the same low-latency, peer-to-peer technology that powers video calls - and plays inside an ordinary web page. No plugin, no app, no download; it is just a video element the viewer watches.

The cleverness is the return path. Every mouse move, click, key press or phone tap the viewer makes is captured in the browser and streamed back to the Unreal app on the server, which treats it as input - exactly as if the person were sitting at that machine. The loop is: input goes up, the server renders and encodes, pixels come down, the viewer sees it, moves again. Because it runs on real hardware and WebRTC is built for low latency, a good setup feels responsive - typically a fraction of a second of delay, akin to a live video call.

Unreal ships this as the Pixel Streaming plugin plus a small signalling server (a Node.js web server Epic provides) that brokers the initial connection between browser and the streaming app. You package your project with the plugin enabled, run it on the cloud instance in streaming mode, run the signalling server, and share the URL. The viewer opens the link and is inside your scene.

It helps to name the three pieces so the setup stops feeling like magic. First, the streamer - your packaged Unreal app, launched with a couple of command-line flags that tell it to encode and stream instead of drawing to a monitor. Second, the signalling server - the little Node web page the viewer actually loads; its job is only to introduce the browser and the streamer to each other and get out of the way. Third, WebRTC - once introduced, the browser and streamer hold a direct, low-latency connection carrying video down and input up. Understanding this split matters practically: when a stream fails, it is almost always the streamer not running, a firewall blocking the WebRTC ports, or the signalling server unreachable - and knowing which of the three broke turns an opaque black screen into a five-minute fix.

Streaming is not automatically better - it is better for specific situations, and a plain packaged download is better for others. Reach for Pixel Streaming when the client's device is the constraint. They are on a phone or tablet; they have a Mac and you built for Windows; their IT will not let them install executables; the build is enormous and a download is a barrier; or you want to send a marketing link that anyone can open instantly, on any device, with zero friction. It is also the natural fit for a public sales configurator on a developer's website - thousands of prospective buyers configuring a flat from their sofa, none of them installing anything.

Streaming also protects your work more strongly than a download: the assets never leave the server, so there is nothing on the client's device to extract. And you can update the experience centrally - fix a material, re-deploy on the server, and every future visitor sees the new version without re-downloading anything.

Prefer a plain packaged download when: the audience is a handful of known people with capable machines; you need it to work fully offline (a site office with poor internet, a client on a plane); latency must be zero (a fast-twitch VR review - VR over the network is impractical); or you simply do not want to run and pay for server infrastructure. Streaming trades your ongoing cost and complexity for the client's convenience. That trade is worth it exactly when reach and zero-friction access matter more than running cost.

Here is the part the demos skip: streaming costs money for as long as it runs, and usually one GPU per concurrent viewer. A single Unreal streaming instance renders for one session at a time; two people in the experience at once generally means two GPU-backed servers. Cloud GPU instances (AWS, Azure, Google Cloud, or specialist providers) are billed by the hour and are not cheap - a capable GPU instance can run anywhere from roughly a dollar to several dollars per hour, so a configurator that must serve many simultaneous users needs a fleet, autoscaling, and a real budget. A private, on-demand client review for one person for an hour is trivially cheap; a public always-on configurator for a sales campaign is an ongoing operating cost you must plan and price into the job.

The practical patterns: spin an instance up only when needed (schedule a review, start the server, tear it down after) to keep a private demo near-free; use autoscaling so a public experience adds servers under load and removes them when idle; and consider managed services - Epic and third parties offer hosted Pixel Streaming so you do not have to operate raw cloud GPUs yourself, trading a higher per-hour rate for far less DevOps. Latency depends on the viewer's distance from the server and their connection, so put the instance in a region near your audience.

The honest summary: Pixel Streaming removes every constraint from the client's side and moves the cost and complexity to yours. For the right job - reach, phones, no-install, central updates - that is a superb trade. For a small known audience with good PCs, a packaged download is simpler and free to distribute.

You do not need to be a cloud engineer to try this. The minimum viable path: enable the Pixel Streaming plugin in your project, package a Shipping build for Windows (Linux is also supported and often cheaper to host), and run it with the Pixel Streaming launch flags alongside Epic's signalling web server. Test it locally first - stream from your own machine to a browser tab on the same PC, then to your phone on the same Wi-Fi - to prove the pipeline before you pay for any cloud time.

Once it works locally, rent a single GPU cloud instance, copy your build and the signalling server up, open the right ports, and point a browser at the instance's address. That one server, started for a meeting and stopped after, is a genuinely usable client-review setup for pennies. Scaling to a public, always-available configurator - a load balancer, an instance pool, autoscaling, a proper domain and TLS - is a real infrastructure project, and the point where a managed Pixel Streaming provider usually earns its markup.

A quick UX note: design the streamed experience for mouse-and-touch on unknown screens. On-screen buttons beat keyboard shortcuts (a phone has no WASD), keep the UI large and legible, and show a short loading state while the WebRTC connection establishes so a first-time viewer does not think the blank page is broken. The experience is only as good as its worst-connected viewer, so keep the interactions simple and forgiving.

Quality settings deserve a deliberate decision too. Because the server has a fixed, known GPU, you can tune the encoder for the experience you want: a higher bitrate and resolution look sharper but demand more of the viewer's connection, while a lower bitrate stays smooth on weak mobile data. Many production setups adapt the bitrate to the measured connection, dropping quality briefly rather than stuttering. And because the render happens server-side, you are free to push visual fidelity - full Lumen, dense Nanite geometry - that would cripple a client's laptop, since their device never touches it. That inversion is the quiet luxury of streaming: you get to art-direct for a GPU you control, then let anyone, on anything, come and look. Just remember the flip side every session leaves running is a meter turning - close idle instances, and never let a forgotten demo server bill you through a weekend.