> ## 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.
# Builds
> Manage every build in a project — track progress, set the live build, and organize your version history.
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](/resources/quick-start-guide/uploading-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.
| Status | Meaning |
| --------------------------- | --------------------------------------------------------- |
| Queued | Waiting to start processing. |
| Downloading | Streampixel is pulling your `.zip`. |
| Extracting and Scanning | Unpacking and validating the package. |
| Saving to Repository | Storing in regional build storage. |
| Distributing to the Servers | Releasing to the GPU workers. |
| Current Live Build | Live and streamable. |
| Archived | Older or auto-release-disabled builds, kept for rollback. |
| Validation Failed | Something 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](mailto:support@streampixel.io) with the project ID and build name and we'll take a look.
See [Build lifecycle](/resources/concepts/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.
### Autorelease Latest Build
The **Autorelease Latest Build** toggle at the top of the Builds tab controls what happens when a new upload finishes processing.
| Toggle | Behavior |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **On** *(default)* | The newest successfully processed build is automatically set as the live build. |
| **Off** | New uploads land in Archived. You decide what's live by clicking **Set as Live** on the build you want — useful for staged rollouts and staging environments. |
For programmatic control, the [Upload File API](/resources/api-reference/upload-file-api) accepts an `autoRelease` flag per upload, and the [Distribute File API](/resources/api-reference/distribute-file-api) handles 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
First-time upload walkthrough.
Every state, webhook event, and rejection reason.
Programmatic uploads from CI/CD.
Auto-upload from GitHub Actions on every commit.