No. CI workflow artifacts are temporary build output. On GitHub Actions they expire after 90 days by default, and deleting a workflow run deletes its artifacts with no restore. Release binaries need a permanent store with its own access rules, retention and integrity records.
What CI artifacts are for
GitHub stores build logs and artifacts with each workflow run. Retention is configurable per repository, organization and enterprise, and per artifact at upload time. After expiry they are gone, and the documentation warns that a deleted artifact cannot be restored. When a run is deleted, all artifacts of that run are deleted too.
That makes them fine for handing a build to the next job and a poor system of record for what you shipped.
Where release binaries should live
| Need | Workflow artifact | Release store |
|---|---|---|
| Hand a build to the next job | Good | Not needed |
| Customers download it | No | Yes |
| Keep for years for audit | No | Yes, with retention rules |
| Immutable once published | No | Yes |
| Signed and checksummed | Optional | Required |
| Access control by role | Repository level | Dedicated |
A release store can be a release page, an artifact repository, a package registry or an object bucket with versioning. What matters is that it is separate from the pipeline's scratch space.
Steps
- Build once in CI and upload to workflow artifacts for the pipeline's own use.
- Run verification against that build: scans, tests, signature checks.
- On approval, publish the same files to the release store. Do not rebuild.
- Generate a checksum file and a signature at publish time. See how to sign release files with cosign.
- Make the release immutable. See what immutable releases lock.
- Record the digest, commit, workflow run and approver in the release record.
- Set retention in the release store to match your policy, not CI's default.
A quick test
Ask one question: if the CI project vanished tomorrow, could you still produce every binary you shipped this year, with its signature, checksum and the record of who approved it? If the answer is no, your release store is the CI system, and its retention rules are your retention rules. Fix that before an auditor or a customer asks for a build from last spring.
Teams often discover the gap during an incident, when they need to compare the shipped binary with a rebuilt one. Having the original file, not a reconstruction, makes that comparison quick and conclusive.
Mistakes to avoid
- Linking customers to CI artifact URLs. They need authentication and they expire.
- Keeping the only copy of a signed build in a run you may delete.
- Letting anyone who can rerun a workflow regenerate a release file.
- Forgetting that logs expire on the same clock as artifacts, so copy evidence you need.
For what auditors expect to see per release, read what to archive for each release.
Safeguard's compliance and evidence automation stores scan results and release evidence independently of the CI system that produced them.
Quick check
How long do GitHub Actions artifacts last by default?
90 days, configurable. You can also set a custom period for an individual artifact at upload.
Can I recover a deleted artifact?
No. GitHub documents that once an artifact is deleted it cannot be restored.
Sources
Last reviewed: 19 October 2026.
