Build lifecycle & retention¶

What happens to a build artifact from the moment you start uploading it to the moment it goes away.

1. Pending upload¶

Every upload starts by asking AppGantry to initiate one. You get back a signed URL and a pending-upload identifier, and nothing exists yet as a build.

Property	Value
Signed URL and pending row lifetime	1 hour
Maximum artifact size	500 MiB
Maximum pending uploads per project	25

The bytes go directly to storage, never through the API. That is why a slow upload doesn't hold an API connection open and why other API calls keep working while it runs. Because the signed URL addresses Azure Blob Storage, the PUT must include x-ms-blob-type: BlockBlob and no AppGantry Authorization header — see Uploading a build for the canonical contract.

Pending uploads that are never completed expire, and both the row and any orphaned bytes are swept up. Nothing is metered for an upload that never completed.

2. Completion¶

You complete the upload, reporting the SHA-256 you computed while streaming the bytes. AppGantry:

checks the stored artifact's size against the cap,
records your checksum as the build's integrity fingerprint, and
promotes the pending row into a real build.

The checksum is recorded, not recomputed: AppGantry does not re-derive the digest from the stored bytes, so verifying it is a client-side job. See Security.

From this point the build has an identifier, appears in the project's build list, and its bytes count towards your storage meter.

3. Active¶

An active build can be:

downloaded by anyone with the right role or tester grant,
published into a channel as a release, and
edited as far as its release notes go (the artifact and its metadata are immutable).

Publishing an active build to a store through a store connection is a capability that has not shipped: store publishing is not operational. The request is accepted and a publish job is created, but every job ends failed and no artifact reaches Apple or Google.

The build detail page shows the identifier, platform, version name and build number, bundle identifier and minimum OS where AppGantry could read them out of the artifact, filename, SHA-256, upload time, and who uploaded it.

4. Revoked¶

Revoking a build stops testers downloading it while keeping the row, the metadata, and the audit trail. It is the right move for "this build is bad" and it is reversible in the sense that nothing was destroyed: the artifact is still there and still counts towards storage.

Build lists default to active builds only; you can ask for revoked ones or for both.

5. Deleted¶

Deleting a build removes the artifact. It is not reversible and it is audit-logged. A build can go away three ways:

Cause	Trigger
Manual delete	Someone with the right role deletes it
Retention expiry	The build passed its organization's retention window
Organization deletion	The whole organization was deleted

Releases that pointed at a deleted build stop being installable.

Retention¶

Retention is a per-organization window measured from upload. Once a build is older than the window, it becomes eligible for automatic removal.

Plan	Default build retention	Default audit retention
Team	30 days	90 days
Business	365 days	365 days
Enterprise	Not generally available	Not generally available

Two things follow from this:

Retention is a cost lever on hosted storage. Storage is metered as a rate over time, so halving retention roughly halves the storage line on your invoice. On BYOSA it changes your cloud bill instead of ours.
Retention is not a backup policy. If a build matters beyond the window, keep the artifact in your own artifact store too.

Audit retention is separate from build retention: your audit log keeps its own window, and you can export it as CSV before it ages out.

Storage location¶

Build artifacts live in one of two places:

Hosted storage, AppGantry's own account. The default on every plan, metered per MB across upload, storage, and download.
BYOSA, your own Azure Blob Storage account. Per-MB metering drops off your AppGantry invoice and your cloud provider bills you directly.

Icons (organization, project, developer avatar) are always hosted regardless of the organization's storage backend, are capped at 1 MiB, and must be PNG, JPEG, or WebP. They are not metered as downloads.

Downloads¶

A download is served through a time-limited signed URL minted per request, not a permanent public link. That's true for developers, for testers, and for anonymous downloads from a public channel.

Minting a download URL is billing-gated; reading metadata never is. See Errors → 402.