fix(server): clean up legacy artifacts and shorten retention

Metadata

Source

tuist/tuist #11576

Updated

Jul 5, 2026

Domains

Storage

Details

Resolves none.

What changed

Set build archive and run artifact retention to 30 days for every account plan.
Added a hosted daily worker that scans the managed storage bucket for legacy builds/ objects that current build metadata cleanup cannot see.
Deletes expired legacy build artifacts by object storage last_modified, including orphaned account prefixes with the Air build archive window.
Leaves current build.zip objects to the existing build archive worker.
Updated retention documentation and focused tests.
Refreshed the plug_cowboy lock entry after Mix resolved it during verification.

Why

Build and run artifacts are not useful enough beyond 30 days to justify the storage cost for every plan. The storage investigation also showed that legacy build objects could remain in the bucket even after the normal build retention worker had run.

Root cause

The existing build archive worker is metadata-driven. It finds build rows, derives the current {account}/{project}/builds/{build_id}/build.zip object key, and deletes that exact object. Legacy build objects use older builds/{legacy_identifier}/... paths and can exist without corresponding build metadata, so the database-backed worker never accounts for them.

Approach

The new cleanup path scans the managed storage bucket page by page, filters only legacy build artifact shapes, resolves known account handles to their current plan, and applies the build archive retention cutoff. If the account prefix no longer resolves to a live account, it applies the Air retention window. The worker re-enqueues itself with the next continuation token until the scan is complete.

Impact

Hosted deployments will now remove more expired build artifacts during the daily storage cleanup window. Customers keep build and run metadata for dashboards and analytics, but downloadable build and run binaries expire after 30 days across plans.

How to test locally

mix test test/tuist/storage/legacy_build_artifact_retention_test.exs test/tuist/storage/workers/delete_expired_cache_artifact_workers_test.exs test/tuist/storage/retention_policy_test.exs test/tuist/storage/workers/delete_expired_artifact_workers_test.exs test/tuist/oban/runtime_config_test.exs
git diff --check

Flights

Investigate, reproduce, or fix this item in an isolated repository. Each Flight preserves its outcome and agent session.

New Flights are paused Configure model inference, GitHub, and a sandbox provider to start another Flight. Existing results remain available below.

No Flights yet

Start a Flight and preserve its objective, outcome, and session here.

Comments

P

pepicrft Jun 30, 2026

Added this as a customer-facing Server docs page at /en/docs/guides/server/data-retention and kept server/data-export.md as the internal export inventory. I put it under Server because the retention windows cut across cache, build insights, previews, test results, runner logs, and exports rather than belonging to one feature page.

P

pepicrft Jun 30, 2026

Good catch. I corrected this so artifact-file retention is capped at 30 days. Cache files stay at 14 days for Air and Open Source and 30 days for paid plans, previews, build archives, run artifacts, and test attachments are 30 days for every plan, and shard bundles keep their shorter 7, 14, and 30 day windows. The docs now reflect that policy.