Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.streampixel.io/llms.txt

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

The Builds tab is your project’s build history. Use it to:
  • track an upload as it moves through processing,
  • choose which build viewers see (now, or rolled back), and
  • organize your version history as the project grows.
For your first upload, start with Upload your build. This page covers everything you do after the upload.

Track a build’s progress

Every upload moves through a fixed sequence of states. The Builds list shows the current state for each one, alongside the build name, UE version, and upload date.
StatusMeaning
QueuedWaiting to start processing.
DownloadingStreampixel is pulling your .zip.
Extracting and ScanningUnpacking and validating the package.
Saving to RepositoryStoring in regional build storage.
Distributing to the ServersReleasing to the GPU workers.
Current Live BuildLive and streamable.
ArchivedOlder or auto-release-disabled builds, kept for rollback.
Validation FailedSomething went wrong — see the remarks column.
When a build reaches Current Live Build, you’ll get an email and the share link goes live.
Queued means the build processing service is busy handling uploads from other users and yours has been added to the queue. There’s nothing wrong with your build — it’ll start processing automatically as soon as a slot opens up. No action needed.
Most cases are normal — large builds, busy regions, or archive retrieval. Anything past 2 hours is unusual. Contact support@streampixel.io with the project ID and build name and we’ll take a look.
See Build lifecycle — covers every state, every webhook event, and what to do when a build is rejected.

Choose what’s live

The live build is the one viewers see when they open your share link. You decide what’s live two ways: automatically at upload time, or manually whenever you want.

Auto-release at upload time

SettingBehavior
Enabled (default)The build goes live automatically once it passes processing.
DisabledThe build stays Archived until you manually release it — useful for staged rollouts and staging environments.
Set this when you upload. For programmatic control, use the Upload File API and the Distribute File API for manual release.

Roll back to an older build

To make a previous build live again, find it in the Builds list and click Set as Live. The selected build moves into the live slot and the previous one becomes Archived. The share link stays the same — viewers don’t need a new URL.
Rolling back to an older build can take a few extra minutes the first time. Builds that haven’t been live for a while are moved to archive storage to save costs, and we have to retrieve them before they can stream. Retrieval takes up to 30 minutes — you’ll see the build sit in Downloading during that time.

Organize your build library

Once you’ve shipped a few builds, these actions keep things tidy.

Tag a build

Tags label builds with meaningful names — release versions (v1.2.0), branch names (staging, qa), or environment markers (internal-only). Click the Tag action on any build to add or edit its tag. Tags appear next to the build name in the list and are searchable from the filter bar. Useful when a project has dozens of uploads and you need to find “the build we showed at the demo last month” quickly.

Copy a build to another project

Click the Copy action on a build to duplicate it into a different project. The destination project receives the build with the same UE version and a fresh set of asset URLs; the original stays put. Most teams use this to promote builds across environments without re-uploading the same .zip. A typical flow when you run separate Streampixel projects for each environment:
  1. QA approves a build in your dev project.
  2. Copy that build to your UAT project for stakeholder review.
  3. Once UAT signs off, copy the same build to prod.
You’re promoting the exact bytes that were tested — no risk of a re-upload introducing a different artifact.

Delete a build

Click the Delete action to remove a build permanently.
  • You cannot delete the currently live build — set a different build live first.
  • Deletion is permanent. The .zip, extracted files, and asset URLs are all removed and cannot be recovered.
  • Pending or processing builds can be deleted; this cancels the upload.
Deletion is permanent and cannot be undone. If you might want a build later, leave it Archived instead of deleting it.

Next

Upload your build

First-time upload walkthrough.

Build lifecycle

Every state, webhook event, and rejection reason.

Upload File API

Programmatic uploads from CI/CD.

CI/CD pipeline

Auto-upload from GitHub Actions on every commit.