What is an Artifact Repository?
Learn what an artifact repository is, how it enables build-once-deploy-everywhere, and common tools like Artifactory and Nexus.
Expected Interview Answer
An artifact repository is a centralized, versioned storage system for the binary outputs of a build — such as compiled packages, Docker images, JAR files, or npm modules — that CI/CD pipelines publish to and downstream deployments pull from.
Rather than rebuilding software from source at every stage, a build is compiled and tested once, then its exact output is pushed as an immutable, versioned artifact into the repository, so staging and production deploy the identical binary that passed CI. Artifact repositories typically support multiple package formats through dedicated repository types — Maven/Gradle for JVM artifacts, npm for JavaScript packages, Docker registries for container images, PyPI for Python wheels — and enforce access control, retention policies, and vulnerability scanning on stored artifacts. Many also act as a proxy/cache for public registries, so a team's builds do not depend directly on an external registry's uptime and can be scanned before use. Tools like JFrog Artifactory, Sonatype Nexus, GitHub Packages, and cloud-native registries (Amazon ECR, Google Artifact Registry) are common implementations.
- Guarantees the exact binary tested in CI is what gets deployed
- Provides versioning, rollback, and audit trail for build outputs
- Caches and proxies external dependencies for reliability and speed
- Centralizes access control and vulnerability scanning of packages
AI Mentor Explanation
An artifact repository is like a national cricket board's equipment certification store, where every bat that passes the official testing lab is logged with a serial number and stored centrally before any team can requisition it for a match. A franchise does not re-test a bat from scratch before every game; it simply requisitions the exact certified, serial-numbered bat already on record. If a batch of bats later fails a safety recheck, the board can trace and recall that exact serial number across every team that requisitioned it. The certified store is the single source of truth for what equipment is safe to field.
Step-by-Step Explanation
Step 1
Build once
CI compiles and tests the source code, producing a binary artifact (jar, wheel, image, package).
Step 2
Publish with a version
The pipeline pushes the artifact to the repository tagged with an immutable version or digest.
Step 3
Scan and gate
The repository can scan for vulnerabilities and enforce policy before allowing promotion.
Step 4
Pull for deployment
Staging and production deployments pull the identical versioned artifact rather than rebuilding.
What Interviewer Expects
- Understanding of “build once, deploy everywhere” using immutable artifacts
- Knowledge of common formats: Maven, npm, Docker images, PyPI
- Awareness of proxy/cache role for external registries
- Ability to name real tools: Artifactory, Nexus, ECR, GitHub Packages
Common Mistakes
- Rebuilding from source at each deployment stage instead of reusing one artifact
- Not versioning artifacts immutably, causing “latest” tag ambiguity
- Ignoring vulnerability scanning on stored artifacts
- Confusing an artifact repository with plain object storage that has no versioning or metadata
Best Answer (HR Friendly)
“An artifact repository is where we store the actual compiled output of a build — like a Docker image or a package — after it passes our tests, so every later stage of the pipeline deploys that exact same tested binary instead of rebuilding it. This gives us traceability, faster deploys, and the confidence that what we tested is exactly what goes to production.”
Code Example
# Tag and push a build artifact to a Docker registry
docker build -t registry.example.com/myapp:1.4.2 .
docker push registry.example.com/myapp:1.4.2
# Deploy pulls the exact same tested image, never “latest”
kubectl set image deployment/myapp myapp=registry.example.com/myapp:1.4.2
# Publishing an npm package to a private registry
npm publish --registry https://nexus.example.com/repository/npm-internal/Follow-up Questions
- Why should build artifacts be versioned immutably rather than tagged “latest”?
- How does an artifact repository help with rollback?
- What is the difference between a hosted, proxy, and virtual repository in Nexus/Artifactory?
- How would you enforce vulnerability scanning before an artifact can be deployed?
MCQ Practice
1. What is the main purpose of an artifact repository?
An artifact repository stores versioned, immutable build outputs so the same tested binary is promoted through every environment.
2. Why is the “build once, deploy everywhere” principle important?
Rebuilding at each stage risks environment drift; reusing one immutable artifact ensures consistency from test to production.
3. What additional role can an artifact repository play besides storage?
Repositories like Artifactory and Nexus proxy public registries for reliability and scan stored packages for known vulnerabilities.
Flash Cards
What is an artifact repository? — A centralized, versioned store for build outputs like packages and container images.
What principle does it enable? — "Build once, deploy everywhere" — reusing the exact tested binary across environments.
Name two artifact repository tools. — JFrog Artifactory and Sonatype Nexus (also GitHub Packages, Amazon ECR).
Why avoid the “latest” tag for deploys? — It is mutable and ambiguous — immutable version tags guarantee reproducible deployments.