Artifact
A shippable output: a concrete file (or set of files) produced by tooling, such as a binary, package, image, or archive.
Definition
An artifact is a concrete output produced by a build, packaging, or publishing step - something that can be stored, copied, shipped, deployed, and executed or consumed later.
Artifacts come in many forms:
- compiled outputs like a binary or executable
- language packages (a bundle, a wheel, a gem, a jar)
- deployment bundles (static site output, a zip/tar archive)
- container images and other “unit of deployment” formats
The point is not the file format. The point is that the artifact is the thing that moves through your delivery pipeline.
Synonyms and related terms
- Synonyms: build output, deliverable
- Related: package, bundle, image, release, binary, executable
Artifact vs source code
Artifacts are downstream of source code. Source code is human-authored input. Artifacts are tool-produced output.
This distinction is operationally important because:
- deployments typically ship artifacts, not source code
- rollbacks typically restore a prior artifact
- debugging “what is running?” usually means “what artifact version is deployed?”
Properties that matter in real systems
When treating artifacts as first-class objects, these properties become central:
- Identity: a stable version, digest, or hash. Ideally unique and immutable.
- Provenance: which inputs produced it (commit, build config, dependencies, compiler/toolchain versions).
- Reproducibility: whether it can be rebuilt byte-for-byte from the same inputs (not always possible, but a useful goal).
- Distribution: where it is stored (artifact repo, registry, object storage) and how it is retrieved.
- Verification: signing, checksums, and policies to ensure integrity.
How artifacts connect to “running”
Many “works locally, fails in prod” issues are not about source code at all. They come from differences in:
- the artifact (built with a different toolchain, different flags, different dependencies), or
- the runtime environment (different OS, permissions, config, network).
In other words: a clean mental model is “source code produces artifacts. Artifacts are what get executed or deployed.”
Mini-scenario
An incident occurs and the team knows which Git commit “should be” deployed. But the running system behaves differently. The missing piece is the deployed artifact identity: a hotfix artifact was built from the same commit but with a different dependency version. Without artifact identity and provenance, “what is running?” remains ambiguous.