What Is a Build Artifact in Software Development?

Every CI/CD pipeline produces files that never show up in your Git repo. Compiled binaries, Docker images, packaged libraries. These are build artifacts, and they are the actual thing that gets deployed to production.

Understanding what a build artifact is matters because it sits at the center of your deployment process, your security posture, and your ability to roll back when something breaks. If you cannot trace an artifact back to its source commit, you have a problem.

This guide covers how build artifacts are created, the common types across different language ecosystems, how they move through CI/CD pipelines, where to store them, and why artifact security has become a serious concern for engineering teams in 2025.

What Is a Build Artifact

A build artifact is any file or group of files produced as the output of a build process. Compiled binaries, packaged libraries, container images, bundled JavaScript files, WAR archives. All of these count.

The distinction matters because source code and build artifacts are not the same thing. Source code is what developers write. A build artifact is what the build automation tool produces after compiling, linking, packaging, or otherwise transforming that source code into something deployable.

In Java, a .jar or .war file is the artifact. In .NET, it is a .dll. A Go project compiles down to a single binary. A React app built with Webpack or Vite outputs a folder of static HTML, CSS, and JS bundles.

If you have worked with Docker, the container image itself is a build artifact. Same for Helm charts, Python wheels (.whl), npm tarballs, and NuGet packages.

The term “artifact” gets tossed around a lot in software development, but the meaning stays consistent. It is the packaged, deployable result of running your build.

According to the CD Foundation’s 2024 State of CI/CD Report, 83% of developers are now involved in DevOps-related activities like CI/CD, making build artifact management a daily concern for most engineering teams.

Source Code vs. Build Output

Source code lives in your repository. Build artifacts live in your pipeline output or an artifact repository.

You version source code with Git. You version artifacts with tags, checksums, and semantic versioning schemes like 1.4.2.

Key difference: source code requires a build step before it can run in production. Build artifacts are ready to deploy as-is (or close to it).

Took me a while early on to really internalize this, because when you are writing Python scripts that run directly, the line feels blurry. But once you start packaging wheels or building Docker images, the separation becomes obvious.

Why the Term Matters

Without a clear concept of “artifact,” teams end up with scattered outputs, no versioning, and no way to trace what actually shipped to production.

Build artifacts give you traceability. They let you roll back deployments, reproduce builds, and pass tested packages between pipeline stages without rebuilding from scratch.

Cybersecurity Ventures projects the global cost of software supply chain attacks will hit $60 billion by 2025. Knowing exactly what your artifact contains, and where it came from, is not optional anymore.

Common Types of Build Artifacts

Not all artifacts look the same. The type depends on your language, framework, and what you are building. But they tend to fall into a few familiar categories.

Compiled Binaries and Executables

These are the most straightforward artifacts. Your compiler takes source code and produces a binary that runs directly on an operating system.

Go is a good example. You run go build and get a single, statically linked binary. No runtime dependencies, no extra packaging. That binary is your artifact.

C and C++ projects produce object files first (intermediate artifacts), then a linker combines them into the final executable. The .o files are intermediate. The resulting binary or shared library is the final artifact.

Packaged Libraries

When your project produces a library for other projects to consume, the artifact is typically a package in your ecosystem’s format.

Maven Central hosts Java .jar files. PyPI hosts Python .whl and .tar.gz packages. npm stores tarballs for JavaScript modules.

These artifacts often include metadata alongside the compiled code: version information, dependency declarations, and sometimes license files. The package manager handles the rest.

Docker reports 8.3 million container image repositories on Docker Hub as of 2024, with roughly 40% year-over-year growth. Container images have become one of the most common artifact types in modern software development workflows.

Intermediate Artifacts vs. Final Artifacts

This trips people up sometimes. Not every file your build produces is meant for deployment.

Intermediate artifacts include transpiled TypeScript output, compiled object files, generated protobuf code, or minified-but-not-yet-bundled CSS. They exist temporarily during the build.

Final artifacts are what actually ships. The Docker image. The signed APK. The deployable WAR file.

Intermediate artifacts still matter, though. Caching them between builds can cut build times significantly. Bazel and Gradle both use aggressive caching of intermediate outputs to avoid redundant work.

How Build Artifacts Are Created

Artifacts do not appear out of nowhere. A build pipeline runs a series of steps, and the output of the final step (or sometimes several steps) is your artifact.

The exact steps vary by project. But the overall pattern looks similar across most stacks.

The Role of Build Tools

Maven and Gradle handle Java projects. make and CMake cover C/C++. Webpack and Vite bundle front-end applications. Cargo builds Rust projects. Bazel handles polyglot monorepos at scale.

Each tool reads a configuration file that defines what to build and how.

A Dockerfile tells Docker how to assemble a container image layer by layer. A build.gradle file specifies dependencies, compilation targets, and packaging instructions. A Makefile defines targets and their prerequisites.

Google uses Bazel internally across its massive codebase. Bazel’s hermetic build model ensures that two developers running the same build get identical artifacts, which is harder to achieve than it sounds.

Steps in a Typical Build

A standard build goes through several phases. The exact names differ between tools, but the pattern holds:

• Resolve dependencies: pull in third-party libraries and internal modules
• Compile: transform source code into machine code or bytecode
• Link: combine compiled units into a single binary (for compiled languages)
• Package: wrap the output into a distributable format (.jar, Docker image, .zip)
• Sign: optionally attach a cryptographic signature for integrity verification

Not every project hits all five steps. A Python project skips compilation entirely. A static site generator skips linking. But the overall flow stays recognizable.

Build Triggers

Builds can start manually on a developer’s laptop (local builds) or automatically through CI/CD systems.

According to a GitLab survey, 60% of organizations using CI/CD practices can release code at least twice as fast as they did before implementing automated pipelines. That speed comes directly from automated build triggers firing on every commit or pull request.

GitHub Actions triggers builds on push events, pull requests, or scheduled cron jobs. Jenkins watches repositories for changes. GitLab CI kicks off pipelines defined in .gitlab-ci.yml when code is pushed.

The build server executes the steps, produces the artifact, and stores it. That is the whole cycle.

Build Artifacts in CI/CD Pipelines

This is where build artifacts become more than just “files your build made.” Inside a continuous integration pipeline, artifacts are the connective tissue between stages.

A CI job compiles your code and produces an artifact. A later job picks up that same artifact and runs tests against it. Another job takes the tested artifact and deploys it to staging. Same artifact, every stage. No rebuilding.

Spacelift data shows that DevOps teams implementing these practices experience 46 times more frequent code deployments compared to low-performing teams. Artifacts moving cleanly through pipeline stages is a big part of that number.

How CI Platforms Handle Artifacts

Every major CI/CD platform has artifact support built in, but implementation varies.

GitHub Actions: uses upload-artifact and download-artifact actions to pass files between jobs. Artifacts are stored temporarily and expire after a configurable period (default 90 days).

GitLab CI: defines artifacts directly in the .gitlab-ci.yml file using the artifacts keyword. Supports path patterns, expiration rules, and access controls.

Jenkins: archives artifacts as part of the build record. Plugins extend this to push artifacts to external repositories.

CircleCI, Azure DevOps, and TeamCity all follow similar patterns. The artifact goes up after the build, comes down before the next stage.

Passing Artifacts Between Pipeline Stages

This is the part that actually matters for deployment speed.

Without artifact passing, every stage would need to rebuild from source. That means recompiling, re-downloading dependencies, re-running the entire build. Wasteful.

Research from Electroiq shows that automating CI/CD pipelines reduces delivery time by up to 40% while increasing deployment stability by about 70%. Reusing artifacts between stages is one of the reasons that number is so high.

Netflix built Spinnaker specifically to handle continuous deployment and artifact promotion across environments. Their pipeline moves the same artifact from build to test to staging to production. No surprises between what got tested and what gets shipped.

Retention and Expiration

CI platforms do not keep artifacts forever. Storage costs money, and old build outputs pile up fast.

Most platforms default to keeping artifacts for 30 to 90 days. GitLab lets you set expirein per job. GitHub Actions defaults to 90 days but allows customization down to 1 day.

A busy project running 50 builds a day can easily generate gigabytes of artifacts per week. Without cleanup policies, storage spirals.

Where Build Artifacts Are Stored

Build artifacts need a home. Leaving them scattered across CI servers, developer machines, and random S3 buckets is how teams lose track of what actually shipped.

Dedicated Artifact Repositories

JFrog Artifactory is the most widely adopted universal artifact repository. According to JFrog, their products are used by 80% of Fortune 100 companies. Artifactory supports over 40 package formats under one roof, from Docker images to Maven JARs to npm packages.

Sonatype Nexus Repository is the main alternative, especially popular in Java-heavy shops and organizations that already use Maven Central.

Both tools serve as centralized hubs where builds push artifacts and deployments pull them. They handle versioning, access control, and metadata automatically.

GitHub Packages and AWS CodeArtifact offer tighter integration with their respective platforms but less flexibility for multi-cloud or hybrid setups.

Container Registries

Container images get their own category of storage. Docker Hub remains the largest public registry, with 3.3 million Docker Desktop installations and growing (a 38% year-over-year increase as of 2024).

For private images, teams typically use Amazon ECR, Google Artifact Registry, or Azure Container Registry. These integrate directly with containerization workflows and Kubernetes deployments.

A container registry is really just a specialized artifact repository. It stores image layers, handles tagging, and serves pulls during deployment.

Cloud Storage as an Artifact Store

Some teams skip dedicated tools and use S3 buckets, Google Cloud Storage, or Azure Blob Storage directly. It works, but you lose built-in versioning, access control, and integration with package managers.

For small teams or simple projects, this is fine. For anything with regulatory requirements or a software audit process, dedicated repositories save a lot of headaches down the road.

Build Artifact Versioning and Traceability

Knowing what you built is only half the picture. You also need to know which version of it is running where, and which commit produced it.

Semantic Versioning on Artifacts

Most packaged artifacts follow the MAJOR.MINOR.PATCH convention. Bump the major version for breaking changes, minor for new features, patch for bug fixes.

This is not just a nice-to-have. Package managers like npm, Maven, and pip rely on version strings to resolve dependency trees. A malformed version breaks installs downstream.

Pre-release tags like 1.4.0-beta.2 let teams publish unstable builds without affecting consumers who pin to stable versions. Release candidates follow a similar pattern.

Linking Artifacts to Source

Every artifact should trace back to a specific Git commit. This is how you answer the question: “What code is actually running in production right now?”

Most CI systems embed commit SHAs, branch names, and build timestamps into artifact metadata automatically. Jenkins does it through build info. GitHub Actions exposes GITHUBSHA as an environment variable.

The 2025 Verizon Data Breach Investigations Report found that 30% of breaches now involve a third party, double the previous figure. Traceability from artifact back to source is one of the first things incident responders check when something goes wrong.

Provenance and Supply Chain Integrity

Traceability goes deeper than just “which commit.” The SLSA framework (Supply-chain Levels for Software Artifacts) defines levels of assurance for how artifacts were built.

• SLSA Level 1: build process is documented
• SLSA Level 2: build runs on a hosted service with signed provenance
• SLSA Level 3: build environment is hardened and tamper-resistant

Sonatype’s 2024 State of the Software Supply Chain report found that supply chain attacks doubled again in 2024. The SolarWinds breach in 2020 was the wake-up call, but the problem has only gotten worse since.

Build provenance records, generated by tools like Sigstore and Cosign, let consumers verify that an artifact was built by a trusted pipeline and has not been tampered with. Software configuration management practices tie directly into this, ensuring the build environment itself is consistent and auditable.

Gartner predicted that by 2025, 45% of organizations worldwide would experience attacks on their software supply chains. That prediction appears to be tracking close to reality.

Build Artifacts vs. Dependencies

This one confuses people more than it should. Your build artifact is someone else’s dependency. And every dependency you pull into your project was, at some point, somebody else’s build artifact.

The relationship is circular. Understanding it clears up a lot of headaches around versioning, security scanning, and reproducibility.

Your Output Is Their Input

When you publish a .jar to Maven Central or a Python wheel to PyPI, that file is your build artifact. The moment another team installs it into their project, it becomes their dependency.

Open source dependencies save the world roughly $8.8 trillion in development costs, according to Endor Labs’ 2024 Dependency Management Report. But that shared ecosystem also means your artifact’s bugs become everyone else’s problem.

The left-pad incident in 2016 made this painfully clear. One developer unpublished a tiny npm package, and thousands of builds broke worldwide because they all depended on that single artifact.

Direct vs. Transitive Dependencies

Direct dependencies: packages your project explicitly declares and installs.

Transitive dependencies: packages your direct dependencies pull in. You never asked for them, but they are in your build anyway.

DevOps.com research shows that managing just 10 direct dependencies can impact up to 170 transitive ones. That is a lot of code you did not write running inside your artifact.

This is why lock files matter. package-lock.json, Pipfile.lock, Cargo.lock. They pin every transitive dependency to an exact version so builds stay reproducible.

How Package Managers Pull Artifacts

Each manager resolves a dependency tree, downloads the required artifacts from a registry, and caches them locally. The build then compiles your code together with those downloaded artifacts to produce your own output.

Sonatype reports that the average Java application now contains 148 dependencies. Every single one of those is a build artifact produced by someone else’s pipeline.

Managing Build Artifact Size and Cleanup

Artifact storage grows faster than most teams expect. A project running automated builds on every pull request can generate gigabytes of output per week, and nobody notices until the bill arrives or the disk fills up.

Why Artifact Storage Gets Out of Hand

Active projects produce a lot of builds. And most of those builds generate artifacts that nobody will ever look at again.

A team running 50 CI builds per day, each producing a 200MB Docker image, is generating nearly 10GB of artifacts daily. Over a month, that is around 300GB from a single project.

Sonatype’s 2024 report found that 85% of projects on Maven Central are inactive (fewer than 500 downloads per month), yet their artifacts still take up storage. The same principle applies to your internal repository.

Retention Policies

GitHub Actions: default retention is 90 days, configurable down to 1 day per repository or organization.

GitLab CI: uses the expirein keyword per job. Set it to 1 week for feature branch builds and never for release tags.

JFrog Artifactory: supports cleanup policies based on age, download count, and property filters. You can configure automatic pruning of artifacts not downloaded in the last 90 days.

The trick is being aggressive with development artifacts and conservative with production releases. Nobody needs last Tuesday’s feature branch build. But you absolutely need the artifact that is running in production right now.

Techniques for Reducing Artifact Size

Multi-stage Docker builds are the single biggest win for container-based projects. One team documented reducing a Go application image from 400MB down to 10MB (a 97.5% reduction) by using multi-stage builds with distroless base images.

• Tree shaking removes unused code from JavaScript bundles (Webpack, Vite, Rollup all support it)
• Stripping debug symbols cuts binary size for compiled languages like Go and C++
• .dockerignore files prevent nodemodules, test files, and docs from bloating container images

For front-end projects, code refactoring and dead code removal before the build step can shave significant size off the final bundle. Your mileage may vary, but I have seen 30-40% reductions just from cleaning up unused imports.

Cost at Scale

Cloud-hosted registries charge per GB stored and per GB transferred. Amazon ECR, Google Artifact Registry, and Azure Container Registry all follow this model.

For a company with dozens of microservices each producing daily builds, artifact storage can quietly become a meaningful line item. Setting up automated cleanup early saves real money later. And honestly, most teams learn this the hard way.

Security Considerations for Build Artifacts

Build artifacts are a target. Attackers who compromise an artifact can reach every system that deploys it, and that is exactly what makes supply chain attacks so effective.

Cybersecurity Ventures projects the global cost of software supply chain attacks at $60 billion in 2025, growing to $138 billion by 2031. Gartner predicted that 45% of organizations would face supply chain attacks by 2025.

Supply Chain Attacks Targeting Artifacts

The SolarWinds breach in 2020 remains the reference point. Attackers infiltrated the build environment and injected malicious code into the Orion platform’s update artifacts. More than 18,000 organizations downloaded the compromised build.

Sonatype’s 2024 report found that supply chain attacks doubled again in 2024. The XZ Utils incident that same year showed how a patient attacker (likely state-backed) spent two years gaining a maintainer’s trust before embedding a backdoor in the build artifacts of a widely-used compression library.

The 2025 Verizon DBIR reports that 30% of breaches now involve a third party, up from 15% previously. Your artifacts are part of someone else’s supply chain, and vice versa.

Signing Artifacts

Signing binds a cryptographic identity to an artifact. If the artifact changes after signing, verification fails.

Sigstore has become the standard for open-source artifact signing. Within 13 months of its launch, Sigstore recorded 46 million artifact signatures. It uses keyless signing, where short-lived certificates replace long-lived private keys, making the process much simpler to adopt.

Major ecosystems already integrate Sigstore: npm, PyPI, Maven Central, Kubernetes, and GitHub artifact attestations. Red Hat describes it as the de-facto signing system for containers.

Cosign (part of Sigstore) handles container image signing and stores signatures alongside images in OCI registries. For teams running production environments on Kubernetes, verifying image signatures before deployment is becoming standard practice.

Scanning Artifacts Before Deployment

Signing tells you who built the artifact. Scanning tells you what is inside it.

Endor Labs found that fewer than 9.5% of vulnerabilities in open source dependencies are actually exploitable via a reachable call path. That means most alerts from vulnerability scanners are noise, but the ones that are real can be serious.

• JFrog Xray scans artifacts stored in Artifactory for known CVEs
• Snyk Container scans Docker images during CI builds
• Trivy (open source, by Aqua Security) runs fast and integrates with most CI platforms

The software quality assurance process should include artifact scanning as a gate in the deployment pipeline. If a critical vulnerability is found, the artifact does not move to the next stage.

Reproducible Builds

A reproducible build means that given the same source code, build tools, and environment, you get a bit-for-bit identical artifact every time.

This matters because if you cannot reproduce a build, you cannot verify that the artifact was not tampered with. The SLSA framework treats reproducibility as a property of the highest assurance levels.

Achieving true reproducibility is tricky. Timestamps, random seeds, file ordering differences, and compiler non-determinism all get in the way. But tools like Bazel, Nix, and Guix are purpose-built for it.

The collaboration between dev and ops teams is what makes this work in practice. Developers define the build. Operations controls the build environment. Both sides need to agree on configuration management policies, or reproducibility stays theoretical.

Access Control on Repositories

Read access: who can download artifacts.

Write access: who can publish new artifacts.

Admin access: who can modify repository settings and retention policies.

Both JFrog Artifactory and Sonatype Nexus support LDAP/Active Directory integration and fine-grained permissions per repository. For teams subject to software compliance requirements (HIPAA, SOC 2, FedRAMP), audit logs on artifact access are not optional.

Lock down write access to CI/CD service accounts. No human should be pushing artifacts to production repositories manually. That is the kind of thing that build engineers configure once and enforce through policy.

FAQ on What Is a Build Artifact

What is a build artifact in software development?

A build artifact is any file produced by a build process. Compiled binaries, container images, packaged libraries, and bundled static files all qualify. It is the deployable output that results from transforming source code through compilation, linking, or packaging steps.

What are examples of build artifacts?

Common examples include .jar files in Java, .dll files in .NET, Docker images, Go binaries, npm tarballs, and Python .whl packages. For mobile app projects, APK and IPA files are the primary artifacts.

What is the difference between a build artifact and source code?

Source code is what developers write and store in version control. A build artifact is the output of processing that source code through a build tool. Source code needs a build step before it can run. Artifacts are ready for deployment.

Where are build artifacts stored?

Artifacts are stored in dedicated repositories like JFrog Artifactory or Sonatype Nexus. Container images go to registries such as Docker Hub, Amazon ECR, or Google Artifact Registry. Some teams use cloud storage like S3, though dedicated tools offer better versioning.

Why are build artifacts important in CI/CD?

Artifacts are the connective tissue between pipeline stages. A CI job builds the artifact once, then later jobs test and deploy that same output. This avoids rebuilding from source at each stage, saving time and keeping software reliability consistent.

How do you version build artifacts?

Most teams use semantic versioning (MAJOR.MINOR.PATCH). CI systems also tag artifacts with Git commit SHAs and build timestamps. This metadata links every artifact back to the exact source code that produced it, supporting traceability and rollback.

What is an intermediate build artifact?

Intermediate artifacts are temporary files created during the build but not included in the final output. Object files (.o), transpiled code, and generated protobuf files are typical examples. They matter for build caching but never ship to production.

How do you reduce build artifact size?

Multi-stage Docker builds are the most effective technique for container projects. Tree shaking removes unused JavaScript code. Stripping debug symbols shrinks compiled binaries. Using .dockerignore files prevents unnecessary files from entering the image.

What security risks do build artifacts carry?

Compromised artifacts can distribute malware to every system that deploys them. The SolarWinds attack exploited this exact vector. Teams mitigate risk through artifact signing with tools like Sigstore, vulnerability scanning, and verifying source control provenance.

What is the difference between a build artifact and a dependency?

Your build artifact is someone else’s dependency. When you publish a package, your artifact becomes a component other projects consume. The software release cycle connects these two sides of the same coin.

Conclusion

A build artifact is the concrete output of your entire build process. It is what actually runs in staging, passes through your software testing lifecycle, and lands in production.

Getting artifact management right means fewer failed deployments, faster rollbacks, and a clear audit trail from commit to release. Skip it, and you are guessing at what shipped.

Version your artifacts with care. Store them in a dedicated repository. Sign them. Scan them before they move through your deployment workflow. Clean up what you do not need.

As supply chain attacks continue to rise, artifact integrity is no longer something only large enterprises worry about. Every team shipping software needs a plan for it.

Whether you are building JAR files with Maven, container images with Docker, or static bundles with Vite, the principles stay the same. Know what your build produces, control where it goes, and verify it has not been tampered with along the way.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web design, focusing on creating user-friendly websites, and innovative UI kits.

Many of his resources are available on various design marketplaces and for free on Codepen.

Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• From AI Draft to Final Document: Writing, Exporting, and Annotating PDFs Without Desktop Software - May 21, 2026
• The Best Android Launchers for App Organization - May 20, 2026
• What Are the Best PEO Services for Web Development Businesses? - May 20, 2026