What is a build artifact?
What Counts as an Artifact
Artifacts are the tangible results of building your code. They can be executables, libraries, packages, container images, or even configuration files. The key is that they are produced by a build and are intended to be used later, often deployed to a server or published to a registry.
In CI/CD, artifacts are typically uploaded to an artifact repository like Artifactory, Nexus, or a cloud storage bucket. They are versioned so you can trace which commit produced them and redeploy the same artifact if needed.
- Compiled binaries (e.g., .exe, .bin)
- Package files (e.g., .jar, .war, .whl, .deb)
- Docker images
- Zip or tarball archives
- Test reports and coverage files
Why They Matter
Artifacts decouple building from deploying. You build once, then deploy the same artifact to staging, production, and other environments. This ensures consistency and reduces the risk of environment-specific build differences.
Storing artifacts also gives you a rollback path: if a deployment fails, you can redeploy the previous artifact. Many teams keep artifacts for a set retention period, such as 30 or 90 days, depending on storage costs and compliance needs.
Common mistakes
- Rebuilding the same code for each environment instead of promoting one artifact, which can introduce inconsistencies.
- Not versioning artifacts, making it hard to know which code is deployed.
- Storing artifacts forever without a retention policy, leading to bloated storage.
