What Is a Build Artifact?
A build artifact is the packaged output of a build, the file or bundle that gets stored, tested, and deployed.
When a build finishes, it produces something tangible: a binary, an image, a zipped bundle. That output is the build artifact. Treating it as a first-class, versioned object is central to reliable delivery.
What it is
A build artifact is the concrete result of compiling and packaging your source code, the thing you actually deploy. It might be a container image, a JAR or WAR file, a compiled binary, or a zip of static assets. The artifact is distinct from the source code; it is what the source produces.
How artifacts are produced and stored
The build stage of a pipeline generates the artifact and usually labels it with a version or commit identifier. The artifact is then stored, in an artifact repository or registry, so later pipeline stages and other systems can retrieve the exact same build rather than rebuilding it.
Examples
- A Docker container image for a service.
- A JAR file for a Java application.
- A compiled binary for a Go or Rust program.
- A zip of built static files for a website.
Build once, deploy everywhere
A core delivery principle is to build an artifact a single time and promote that exact artifact through every environment. Because staging and production run the identical bytes, you avoid the drift that creeps in when each environment rebuilds. The artifact is what makes "build once" possible.
Why it matters
Versioned, stored artifacts give you traceability (which commit produced this?), reproducibility (deploy the same thing again), and the ability to roll back (redeploy the previous artifact). They are the unit that flows through the deployment pipeline, so getting them right makes the whole pipeline trustworthy.
Key takeaways
- A build artifact is the packaged, deployable output of a build.
- Artifacts are versioned and stored so they can be reused.
- Building once and promoting the same artifact avoids drift.