# Artifact
An **artifact** in software engineering is a file or package produced by a build process that is intended for use or distribution. Source code is the input; artifacts are the outputs. Examples: a compiled binary, a `.jar` file, a Docker image, a firmware `.hex` file, a compiled PDF from LaTeX source.

In [[ci-cd]] pipelines, artifact management is a core concern. A pipeline builds the artifact once from a specific commit and then promotes that same artifact through environments: the binary tested in staging is the same binary deployed to production. This guarantees that what was tested is what was shipped.

```
commit SHA → build → artifact (versioned) → test → stage → production
```

Artifacts are versioned, either by a semantic version number (`v1.4.2`) or by the commit hash or build number that produced them. Versioning makes it possible to roll back to a known-good artifact without rebuilding from source.

**Artifact registries** store and serve artifacts: Docker Hub and GitHub Container Registry for container images, npm and PyPI for language packages, Artifactory or Nexus for generic binaries. They provide content-addressable storage (you can fetch an exact version) and access control.

In build systems like Make or CMake, the artifact concept is more local: each build target produces an artifact (an object file, a library, an executable) and the build system tracks dependencies between them. An **incremental build** only rebuilds artifacts whose inputs have changed since the last build, which is what makes large codebases buildable in seconds rather than minutes on incremental changes.