CI/CD Artifact Storage

CI artifacts have a habit of vanishing exactly when you need them. GitHub Actions caps artifact retention at 90 days (often configured lower), GitLab expires job artifacts on a schedule, and a self-hosted Jenkins eventually prunes old builds to reclaim disk — so the release binary, the coverage report, or the exact build that a bug report references is gone the moment someone asks for it months later. files.link gives those artifacts a permanent home with a curl-friendly REST API, so the relevant build outputs outlive the pipeline that produced them.

Wiring it into a pipeline is a single post-build step. After the job produces its output, run three calls: POST /v1/files/{folderId} to get a presigned URL and id, PUT the artifact bytes, then POST /v1/files/confirm-upload with {ids:[...]}, all authenticated with your raw API key. In a GitHub Actions step that's just curl against those endpoints with the key from a repository secret; the same shape works verbatim in a GitLab CI script: block or a Jenkins stage, because every CI runner can run HTTP.

A useful convention is one folder per project (or per pipeline) and filenames that embed the commit SHA or tag — app-1.4.2-abc1234.tar.gz — so each build maps to a stable, permanent URL you can paste into release notes, a changelog, or a deploy ticket. Capture that URL as a job output or echo it to the build log so it's discoverable later. The contrast with native artifact storage is durability and reach: GitHub/GitLab artifacts are designed to be transient pipeline scratch, downloadable mainly through their UI/API with auth, whereas a files.link URL is a direct CDN download anyone you authorize can pull from the nearest edge — handy for distributing nightly builds to QA or shipping a release binary to users.

Against rolling your own bucket plus distribution, you skip the IAM and CDN wiring and just curl. Cost-wise, most artifacts are write-once, read-rarely, which is precisely the cold storage tier's sweet spot: keep recent builds on standard storage for quick access and sweep older ones to the cold tier for cheap long-term retention (it has a minimum-retention period, so it suits genuine archive, not artifacts you'll churn daily).

Build outputs that shouldn't be public — proprietary binaries, signed packages — stay as private files served via expiring signed URLs. Billing is prepaid credits against real storage and downloads. If you're really fighting large binaries inside the repo itself, the Git LFS alternative linked below addresses that adjacent problem.