Artifacts expire after the time you set with expire_in, or after the instance default if you set none. GitLab also keeps the latest artifacts from each ref by default, and expire_in does not apply to them. Use artifacts:access to limit who can download, and do not treat artifacts as a release store.
Expiry rules
GitLab says that when expire_in is not defined, the default artifact expiration instance setting is used. A user can select Keep on a job page to stop one from expiring. Separately, GitLab keeps artifacts from the latest pipeline on each ref, and from the most recent successful pipeline, and notes that expire_in does not apply to these. That can use a lot of storage, and the behavior can be turned off in project CI/CD settings.
For scan outputs and test reports, that means old reports may live longer than you expect. If a report contains a secret or internal paths, deletion is your control. Deleting logs and artifacts is permanent and needs the job owner or a Maintainer or Owner.
Who can download
The artifacts:access keyword limits who can download a job's artifacts; the page example uses access: maintainer. Check the keyword reference for the full list of values. The page also mentions publicly accessible download URLs, so confirm project visibility. Our post on who can read logs and artifacts goes deeper.
Passing artifacts between jobs
By default, later jobs download artifacts from earlier stages. The dependencies keyword limits which jobs supply them, and dependencies: [] stops a job downloading any. To fetch from jobs in the same pipeline, GitLab says use needs:artifacts.
| Keyword | Effect |
|---|---|
expire_in | Sets when the artifact is removed |
artifacts:access | Limits who can download |
dependencies: [] | A job downloads none |
needs:artifacts | Fetch from named jobs in the same pipeline |
untracked | Includes untracked files, so check what you sweep up |
Steps to tidy up
- Set
expire_inon every job that produces artifacts. - Exclude files that may hold secrets, using
artifacts:exclude. - Set
dependencies: []on jobs that do not need earlier output, so a poisoned artifact has fewer readers. - Restrict download with
artifacts:accesswhere reports are sensitive. - Move releases to the package or container registry. GitLab says not to use job artifacts as a release store.
- Remember each artifact file has a default size cap of 100 MB.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how results are tracked over time instead of living in a one-off file.
Safeguard's compliance and evidence automation keeps results in the platform, so they are not tied to an artifact expiry date. A free scan is at https://gold.safeguard.sh/scan. For a CI recipe, see the GitLab job artifacts recipe.
Quick check
Why is an old report still downloadable?
GitLab keeps the latest artifacts for each ref by default, regardless of expire_in.
Should I keep release binaries as artifacts?
No. GitLab advises against using artifacts as a release store.
Sources
- GitLab Docs: Job artifacts, fetched 19 October 2026.
Last reviewed: 19 October 2026.
