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.