What is Artefact Storage?
Artefact storage is the service or system that keeps software build outputs so authorised people and tools can retrieve the required version after the build job has finished. Those outputs can include packages, binaries, container images, static site bundles and test reports. Useful artefact storage records what was produced, identifies it clearly, controls access and manages how long it remains available.
Its purpose is to preserve a usable result, not simply to hold source code or make a build faster. A source repository contains the materials and history used to create software. A cache accelerates repeat work. Artefact storage keeps a specific output that may need to be tested, distributed, deployed or recovered later.
Artefact is the UK spelling used here. Many software products, commands and documentation use artifact. The underlying concept is the same, but product names and technical identifiers retain their official spelling.
This subject belongs to the software delivery cluster in the Techie Broadband terminology guide. The key connections are the build that produces an output, the registry or store that keeps it and the consumer that retrieves it.
What counts as a software artefact?
A compiled executable, library or firmware image.
A versioned language package, such as a Python wheel or npm package.
A container image or another object distributed through an OCI registry.
A static website bundle or configuration archive.
Test reports, coverage results, debug symbols and diagnostic logs.
Associated provenance, signatures or component inventories where supported.
Some of these files are releasable products; others are evidence about a run. Keeping a failed test report can help explain a problem without making an unsuccessful application build eligible for release. Distinguish diagnostic retention from publishing approved software.
A Build Pipeline prepares inputs, creates an output and applies checks. Artefact storage provides the handoff after that work. The next job may run on a different machine, and the original runner's working directory may disappear. A filename in a job message does not transfer the file.
Artefact storage, source hosting and caches
System | Primary role | What it does not establish |
Source repository | Version source files and changes | That a particular binary has been retained |
Build workspace | Hold files while a job executes | Availability after the runner is replaced |
Dependency cache | Reuse expensive inputs or intermediate work | A permanent release record |
Workflow artefact store | Persist outputs associated with a run | A complete long term release service |
Package or container registry | Distribute identified packages or images | That every stored version is trustworthy |
Backup system | Recover protected data after loss | That live distribution access is available |
GitHub's workflow artefact documentation explicitly distinguishes retained run outputs and file handoffs from dependency caching. That is the practical boundary: a cache is an optimisation, while an artefact is a result you deliberately keep. GitHub also documents that deleting a workflow run removes its associated artefacts.
The boundaries can coexist inside one product. A repository manager may host your own releases and cache upstream dependencies. A CI platform may offer both job artefacts and a package registry. Similar dashboard labels do not mean those features have identical permissions, retention rules or recovery guarantees.
Choose the storage model that matches the output
Storage model | Good fit | Responsibility to check |
CI workflow artefacts | Reports and files passed between jobs | Run identity, access and expiry |
Language package feed | Packages installed by package managers | Package format, version rules and dependency resolution |
Container or OCI registry | Images and supported OCI content | Manifests, blobs, tags and digest references |
Object storage | Archives, bundles and arbitrary files | Naming, metadata, access and lifecycle policy |
Private managed store | Internal outputs with specific operational needs | Maintenance, recovery and client compatibility |
Microsoft's Azure Artifacts documentation describes package feeds supporting several language ecosystems and Universal Packages. Google Cloud Build documents storing non container outputs in Cloud Storage, while Artifact Registry manages supported packages and container images. These are examples of different interfaces and responsibilities, not a ranking of services.
Object storage can hold a ZIP archive successfully without understanding its package dependencies or release history. A registry adds format aware discovery and distribution behaviour. Conversely, a registry that serves container images may not support every arbitrary file workflow you need. Confirm supported formats rather than inferring them from the word artefact.
If your output is a container image, the Docker guide provides the wider image and runtime context. Storing an image does not start a container, expose an application or prove that it will run on every target architecture.
Follow an artefact from build to consumer
Produce the intended output from a recorded source revision and controlled build inputs.
Complete the required checks for a releasable output, while keeping diagnostic evidence separately where needed.
Upload the output using the store's supported interface and a narrowly scoped publishing identity.
Record the completed publication, output identifier, source revision, run identity and relevant integrity evidence.
Let an authorised consumer retrieve that specific output and verify the expected identity and checks.
Retain or remove the output according to a policy that accounts for release, rollback and recovery needs.
An upload starting is not proof that publication completed. Interrupted transfers, rejected metadata, missing files or insufficient permissions can leave the consumer without a usable output. Record the final result from the service and test retrieval through the consumer's intended access path.
Deployment then installs or runs the selected output in a target environment. Storage does not perform that change by itself. A successful upload is also not a post deployment health check.
The infographic below shows the output, its identity, retrieval and verification, then separates disposable caching from deliberate release retention.
Names, versions, tags and digests are different
Identifier | What it describes | Main limitation |
Filename | A convenient label for a file | The same name can be reused |
Package version | A version within a package ecosystem | Publication rules differ by service |
Build or run ID | The execution that produced an output | One run can produce multiple outputs |
Tag | A human readable reference to content | It can move unless policy prevents it |
Digest | A cryptographic content identifier | It does not identify a trusted author alone |
A release name such as v1.0 is useful to people, but it must resolve to a particular output. An immutable publication policy can prevent that name from being silently replaced. Do not assume immutability: check the store's actual overwrite, tag and deletion controls.
For container distribution, the OCI Distribution Specification version 1.1.1 defines manifests, digest addressed blobs and tags pointing to manifests. A client can request a manifest by tag or digest. Digest verification checks returned content against the expected reference; a moving tag is a different kind of reference.
The OCI Image Specification describes an image manifest's configuration and layer descriptors. An image index can select among manifests, for example for different platforms. Keeping only a displayed image label is not enough to preserve the referenced content that makes the image usable.
Shared layers can reduce repeated transfers and storage, but the actual benefit depends on what the registry and clients already hold. Do not add every image's displayed size and treat that as a guaranteed physical storage bill. Equally, do not assume that every change uploads only the small source edit.
What does a digest check prove?
A digest check compares the retrieved bytes with an expected content identifier. It is valuable for detecting an altered or incorrect copy. The expected value must come from a source you trust. If an attacker replaces both a file and its accompanying checksum, comparing the two does not establish authenticity.
Be precise about what was hashed. The digest of a downloaded archive, an extracted file, an OCI manifest and a compressed layer are different values. Repacking identical files into an archive with different timestamps can change the archive digest. Compare the value for the intended object, not an unrelated layer of packaging.
A signature or authenticated provenance statement can add evidence about the publisher or build process. SLSA's approved version 1.2 build provenance format describes production inputs, the builder and outputs. A verifier still needs expectations about the trusted identity and process. A valid signature does not prove the software is free from defects or malicious behaviour.
Techie Broadband test: retrieve the output, then verify it
We ran a local experiment on Linux with Python 3.12.14. A producer created a ZIP containing one 57 byte JSON configuration file for an illustrative router monitoring service. The archive was 177 bytes, including its ZIP structure, and used a fixed entry timestamp with no compression. A separate local storage directory held a copy.
Before retrieval, we recorded the archive's SHA256 digest and byte length in a separate expected reference. The consumer checked both values before reading the known config.json entry. It did not execute the package or accept arbitrary archive paths.
Create the configuration file and package it as router-monitor-1.0.zip.
Calculate SHA256 for the complete archive and record its byte length separately.
Copy the archive into the store, then retrieve it into a fresh consumer directory.
Confirm the expected digest, length and configuration content match.
Remove the producer directory and repeat retrieval from the retained store copy.
Alter one byte in another archive copy and repeat the same verification.
Test case | Observed verification | Consumer outcome |
Original stored archive | Digest and length matched | Configuration recovered correctly |
Producer directory removed | Digest and length still matched | Configuration recovered from storage |
One byte altered | Digest did not match | Copy rejected before extraction |
The original archive's SHA256 began a5d19486123dc133. Both intact retrievals passed; the changed copy failed and was not extracted. This illustrates two distinct properties: the stored output survived removal of the producer workspace, and the consumer detected a difference from its expected output.
All directories were on the same local filesystem. This was not a cloud durability, authentication, signature, malicious archive or broadband performance test. The separately retained expected digest was trusted for the experiment. Losing that expectation would weaken the check; losing the filesystem would affect both producer and store.
Retention is a release decision, not just a space setting
Start with what you must still be able to retrieve. A temporary test report, a nightly development package, a deployed release and a rollback candidate can need different lifetimes. Keeping everything forever makes capacity harder to manage; expiring everything after the same number of days can remove outputs that remain operationally important.
GitLab's job artefact documentation describes configurable expiry and exceptions for retained recent pipelines. As checked on 12 October 2026, its default behaviour preserves both the latest pipeline's artefacts and those of the most recent successful pipeline for a ref where different. Actual project and instance settings affect retention, so an expiry value alone is not the complete policy.
Google's Artifact Registry documentation describes separate keep and delete policies, with a matching keep policy taking precedence over deletion. Its configuration guidance also supports a dry run to inspect proposed cleanup. Those are product specific examples of why you should test policy outcomes against real release references before enabling removal.
Output category | Retention purpose | Question before removal |
Temporary development output | Short feedback or investigation window | Is a consumer still expecting this run? |
Failure evidence | Diagnose and compare recurring problems | Has the incident been investigated? |
Deployed release | Redeployment and traceability | Can every active environment still fetch it? |
Rollback candidate | Recover a compatible earlier version | Do data and configuration still support it? |
Provenance or signature | Verify retained output history | Will deleting this break verification? |
A label saying untagged does not necessarily mean useless. A deployment may refer directly to a digest. An image manifest may reference layers or other manifests. Signatures and related records can have their own associations and lifecycle rules. Cleanup must account for those references rather than rely on one dashboard column.
Do not equate removal from the listing with immediate reclaimed physical space. Providers can perform cleanup in background jobs, and shared content or retained object versions can affect what remains stored. Check the relevant service's accounting and lifecycle behaviour.
Original capacity model: how retention changes storage
This is an original theoretical inventory calculation, not a provider storage measurement. Assume 20 completed outputs each day, each a separately stored 150 MB archive. Use decimal units, no compression beyond that archive size, no shared content and a full retention window. Exclude metadata, reports, backups, replicas and protected release exceptions.
Logical archive volume equals outputs per day multiplied by archive size multiplied by retained days. For 30 days, 20 × 150 MB × 30 = 90,000 MB, or 90 GB. There are 600 archives in this simplified window.
Retained window | Archive count | Logical archive volume |
7 days | 140 | 21 GB |
30 days | 600 | 90 GB |
90 days | 1,800 | 270 GB |
Changing this model from 90 to 30 days reduces its logical archive volume by 180 GB, about 66.7%. That arithmetic does not justify deleting live releases. A real policy needs exceptions for active deployments and required rollback versions, and a real bill may use different units or account for shared storage.
Separate publication rate from consumption rate. Publishing one artefact once can be followed by many downloads. More consumers can increase distribution traffic without producing more build versions. Record retained bytes, download bytes and request activity independently when assessing cost.
Artefact storage is not automatically a backup
A live store is designed to serve outputs. That alone does not establish recovery after accidental deletion, compromised credentials, lost metadata or a service outage. Replication and high availability can improve access while still leaving you without the historic state needed for recovery.
Amazon S3 documentation distinguishes versioning from Object Lock. Versioning retains multiple object versions; Object Lock protects specified versions under its configured retention controls and requires versioning. Protecting one version does not prevent a new version of the same object name from being created. These controls are specific capabilities, not a universal property of artefact storage.
Preserve the output bytes needed for supported releases, including referenced image content.
Keep the metadata that maps source, run, version and digest to each retained output.
Preserve signatures, provenance and other verification records the consumer requires.
Record access and service configuration needed to restore distribution safely.
Keep recoverable copies outside the failure scenario they are intended to protect against.
Test restoration into a clean destination and retrieve an actual retained release.
A restore that lists filenames but cannot serve a complete image or authenticate its consumer is incomplete. Define the acceptable amount of recent data loss and recovery time for the workload, then check whether the chosen protection and restore process can meet those expectations.
Access control and trustworthy publication
Separate the identities that build, publish, download and remove outputs where practical. A deployment consumer often needs read access to selected releases, not permission to overwrite them or change retention. A build from an untrusted change should not automatically hold the credentials used to publish an approved release.
Treat storage permission and software trust as separate questions. Private access stops unauthorised readers; it does not prove an authorised publisher produced acceptable software. Review the publication path, required checks, source revision and credential scope as well as the store's visibility setting.
Artefacts can accidentally contain credentials, internal URLs, debug information or personal data in logs. Publish an explicit set of output paths rather than uploading an entire workspace indiscriminately. Check diagnostic reports as carefully as application packages. GitHub's cache security guidance also warns against placing secrets in cached paths.
Do not execute a downloaded archive merely because its filename looks familiar. Verify the intended source and identity, apply the workload's inspection policy and use safe handling for its format. For archives, consider path traversal, links and unexpected file entries before extraction.
UK broadband: locate the upload and the download
A home lab runner publishing to a cloud store sends the artefact over your upstream connection. A local consumer downloading it uses downstream capacity. When both builder and consumer are cloud hosted, the major transfer may never cross your home connection.
Upload Speed matters when your home or office is the source of the package. A high download headline cannot remove a lower upstream limit. The actual path can also be constrained by WiFi, router performance, storage, the remote service, packet loss or concurrent household traffic.
Path | Home connection direction | What to measure |
Home builder to cloud store | Upload | Archive bytes and achieved upstream rate |
Cloud store to home consumer | Download | Bytes fetched and achieved downstream rate |
Cloud builder to cloud consumer | Often neither for the artefact itself | Cloud path, registry and client performance |
Local store to local consumer | LAN traffic if it stays local | Disk and local network throughput |
Worked transfer calculation
Assume a 150 MB decimal archive, an otherwise idle connection and a sustained payload rate equal to the specified rate. Ignore protocol overhead, authentication requests, compression time, service waits and disk work. Ideal transfer seconds equal MB multiplied by 8, divided by Mbps.
Transfer | Assumed payload rate | Ideal time |
Publish 150 MB from home | 20 Mbps upstream | 60 seconds |
Publish the same archive | 100 Mbps upstream | 12 seconds |
Retrieve 150 MB at home | 100 Mbps downstream | 12 seconds |
Six complete 150 MB downloads | 100 Mbps total downstream | 72 seconds for 900 MB |
The faster upstream rate saves 48 seconds for this illustrative upload, an 80% transfer time reduction. The six download figure assumes the aggregate 100 Mbps capacity is shared or the downloads run sequentially; it is not six independent full speed links. Caching or already present container layers could reduce bytes, while contention and overhead increase elapsed time.
A UK storage region can be a useful placement option, but geography alone does not guarantee a fast network path. Compare actual client locations, routing, service availability, transfer charges and recovery needs. Confirm where retained copies and metadata reside rather than assuming the main repository's location answers every question.
Choose around retrieval and recovery
GitHub and GitLab workflow artefacts suit run associated outputs. Azure Artifacts and Google Artifact Registry provide package or image distribution features. Object stores and private registries support other controlled workflows. Assess the actual formats and lifecycle you need before choosing a product.
Can every intended consumer fetch the required format and version directly?
Can publication prevent accidental replacement of a release identity?
Can permissions distinguish publishing, reading and deletion?
Can retention protect active releases, rollback candidates and their metadata?
Can you export or restore enough content to leave the service or recover from loss?
Do storage, requests, transfers and operational work fit the workload's budget?
For a small home lab, convenience matters, but a folder called releases is not automatically a managed release service. For a business system, a feature rich registry still needs correct policy and tested consumers. Start with a small complete publish and retrieve path, then measure and extend it.
Troubleshoot by boundary
Symptom | Boundary to inspect | First useful check |
Upload succeeded but output missing | Publication result and selected paths | Confirm final status, repository and files |
Download returns not found | Identity and lifecycle | Check version, run ID and expiry |
Reader gets an access error | Authentication and permission | Use the intended consumer identity |
Digest mismatch | Expected object and transferred bytes | Confirm what was hashed and reject the mismatch |
Old software after a new release | Tag resolution or local cached output | Compare actual retrieved digest |
Container image cannot start | Complete content and target compatibility | Check manifest, layers and platform |
Storage remains high after cleanup | Retention, sharing and accounting | Inspect kept versions and background cleanup |
Transfers are slow | Actual network path and payload | Separate upload, download, service and disk waits |
Keep the precise service response and identifiers in the incident record. A not found response may reflect an expired output, a wrong scope or an intentionally concealed private resource. Do not replace the intended package with whichever similarly named download happens to be available.
For integrity failures, stop the handoff and compare with the expected record. Repeatedly downloading until a mismatch disappears can hide a corrupted source or a changing reference. For missing outputs, check the producer's upload path and success condition before changing retention or permissions.
Frequently asked questions
Is artefact storage the same as repository hosting?
No. Source repository hosting keeps source history. Artefact storage keeps produced outputs such as packages, images and reports. A platform can offer both as separate features.
Is an artefact the same as a cache?
No. An artefact is an output deliberately retained or handed onward. A cache accelerates repeat work and should not be the only release copy.
Does storing an artefact deploy it?
No. Deployment requires a configured action that changes a target environment. Storage makes the selected output available for that action.
Does a matching checksum prove the software is safe?
No. It compares bytes with an expected value. Trust in the publisher, provenance, checks and software behaviour needs separate assessment.
Can I store artefacts in my home lab?
Yes. You can operate a local store or registry, but must provide access control, compatible clients, capacity, retention and tested recovery.
How long should I keep build artefacts?
Keep them for the operational purpose they serve. Temporary outputs, deployed releases, rollback candidates and verification records can require different lifetimes.
Key takeaway
Artefact storage preserves the output that a build produced and makes the required version retrievable. Keep identity, integrity, access, retention and recovery distinct. Record the output that passed the checks, protect the releases consumers still need and measure the actual network path before attributing delays to broadband.
Sources and verification
Primary material checked on 12 October 2026 included GitHub Docs, GitLab Docs, Microsoft Learn, Google Cloud documentation, Amazon S3 documentation, Docker documentation, OCI Distribution and Image specifications version 1.1.1, and SLSA build provenance version 1.2. The local retrieval experiment and labelled capacity and transfer models are original Techie Broadband work. They are not provider durability or ISP speed measurements.
