Skip to main content

Documentation Index

Fetch the complete documentation index at: https://buildpixel.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

If you’re shipping your Unreal Engine app via pixel streaming, BuildPixel and StreamPixel are built to work together end-to-end. You commit code → BuildPixel compiles, cooks, packages → the resulting build is pushed directly into your StreamPixel runtime → your players get the new version.

​
What this looks like

The full loop runs hands-free. No download, no manual upload, no “now go SSH into the runtime and update it” step.

​
Setting it up

In your build setting, enable autoDeploy and point uploadBuildUrl at your StreamPixel runtime: 
{
  "platform": "Win64",
  "buildType": "Development",
  "branch": "main",
  "ueVersion": "5.4",
  "trigger": "push",
  "autoDeploy": true,
  "uploadBuildUrl": "https://api.streampixel.io/v2/runtimes/<runtimeId>/builds/upload",
  "uploadBuildAuthHeader": "Bearer sp_token_..."
}
Two pieces of info you need from StreamPixel:
  • runtimeId — identifies which streaming runtime gets this build. Get it from the StreamPixel dashboard.
  • An auth token — generated in StreamPixel, used to authenticate the upload.
That’s it. Once configured, every successful build of this build setting deploys to that runtime automatically. For pixel-streaming runtimes, you typically want fast cycle time: 
{
  "platform": "Win64",
  "buildType": "Development",
  "branch": "main",
  "trigger": "push",
  "autoDeploy": true,
  "uploadBuildUrl": "https://api.streampixel.io/v2/runtimes/dev-pool/builds/upload"
}
Why these choices:
  • Development not Shipping — Shipping strips symbols, which makes runtime crashes harder to debug.
  • Trigger on push — every commit lands in your dev streaming pool automatically.
For release / public-demo streaming pools, use a separate build setting on a release/* branch with Shipping.

​
Dev pool + prod pool

A common pattern: two runtime pools, two build settings, same project. 
{
  "branch": "main",
  "trigger": "push",
  "autoDeploy": true,
  "uploadBuildUrl": "https://api.streampixel.io/v2/runtimes/dev-pool/builds/upload"
}
Push to main → dev pool gets the new build automatically. Push to release/1.0 → prod pool gets the release build.

​
Without StreamPixel

The uploadBuildUrl mechanism is open. If you have your own pixel-streaming runtime — or any system that wants new builds — point uploadBuildUrl at it. See Custom deploy. The StreamPixel integration is the smoothest path because both products are built by the same team and the receiving side knows BuildPixel’s payload format. But BuildPixel works equally well as the build half of any other pipeline.

​
What if the deploy fails

If your StreamPixel runtime doesn’t accept the upload (rare, but happens during maintenance windows), the build itself still succeeds and the artifact is still available to download. The auto-deploy is retried, then surfaces in the build’s status if it ultimately can’t be delivered.

​
Where to go next

Custom deploy

Use the same auto-deploy mechanism with your own endpoint.

Download instead

Skip the deploy step and grab the artifact directly.