Introduction
Understanding organizationsUnderstanding componentsManage organizationsManage componentsManage component Jira integrations
Set up your first organizationUnderstanding users and teamsUnderstanding role-based access controlManage usersManage teamsConfigure role-based access controlRBAC permissions reference
Understanding authentication in CloudBees UnifySet up multifactor authenticationConfigure SAML single sign-onConfigure OIDC authenticationConfigure network security policiesNetwork security reference
Understanding platform configurationUnderstanding environmentsManage properties and secretsManage environmentsTrack environment inventoryConfigure containersSet up preconfigured actionsConfigure notifications
Accessibility policy referenceShared responsibility model referenceSubscription and services agreementSupport policiesSupported browsers and external tools
Introduction
Understanding feature managementUnderstanding Configuration as CodeGet started with feature managementCreate and manage feature flagsConfigure feature flag targetingOrganize feature flagsImplement feature flag governanceConfiguration as Code reference
Understanding flag impressions and activity statusUnderstanding flag healthUnderstanding code referencesReview and clean up feature flagsSet up code references
Understanding Jira integration for feature flagsSet up the Jira integrationLink Jira tickets to feature flags
Understanding multiple SDK keysBuild your first mobile app with feature flagsBuild your first feature-flagged web applicationBuild your first feature-flagged backend serviceInstall client-side SDKsInstall server-side SDKsConfigure multiple SDK keysMobile SDK referenceWeb SDK referenceBackend SDK referenceClient SDK referenceFlag implementation reference
Introduction
Understanding CI workflowsCreate a build workflowCreate and manage workflowsCreate reusable workflowsTest and validate containers in workflowsCheck out source codeTrigger workflows remotelyWorkflow syntax referenceJobs syntax referenceSteps syntax referenceServices syntax reference
Monitor workflow runsView test results in runsView evidence in runsView deployments in runsManage workflow artifactsPublish test resultsPublish evidence itemsGenerate a software bill of materialsManage ServiceNow change requests
Configure workflow credentialsConfigure AWS credentialsConfigure container registry credentialsConfigure Git credentialsIntegrate external secret providers
Understanding GitHub Actions integrationSet up GitHub Actions integrationDisplay GitHub Actions workflows and runsRegister GHA build artifactsPublish GHA deployed artifactsPublish GHA test resultsPublish GHA evidence itemsTrigger CloudBees workflows from GitHub ActionsScan with GitHub Actions
Understanding CloudBees CI and Jenkins® integrationConnect CI and Jenkins controllersMonitor CI and Jenkins buildsRegister CI build artifactsRegister CI deployed artifactsPublish CI test resultsConfigure CI security scanningCI and Jenkins integration reference
Build and publish container imagesUnderstanding external CI/CD integrationsRun external CI/CD jobsExternal CI/CD action reference
Introduction
Understanding release orchestrationManage applicationsCreate deployer workflowsCreate staged workflowsCreate and manage releasesOrchestrate multi-workflow releasesRelease management reference
Understanding artifact managementRegister and track artifactsStore and retrieve artifactsPromote artifactsGenerate a software bill of materialsArtifact management reference
Deploy with HelmDeploy to KubernetesContainer deployment reference
Deploy to AWSAWS deployment reference
Deploy with enterprise platformsExecute remote deployment commandsEnterprise deployment reference
Verify deployments with New RelicDeployment verification reference

Understanding artifact management

4 minute read

Software delivery generates a stream of outputs: compiled binaries, container images, packaged archives, and dependency manifests. Without a systematic way to track what was built, where it lives, and what was deployed where, teams lose the ability to answer basic questions about their software at any given point in time. This page explains how CloudBees Unify manages artifacts throughout the build and deploy lifecycle, and how artifact tracking connects to the release model.

What CloudBees Unify manages and what it doesn’t

CloudBees Unify does not own artifact storage. Built artifacts live in external systems: Amazon S3 buckets, Amazon ECR registries, JFrog Artifactory repositories, or any other storage your team uses. CloudBees Unify’s role is to wrap storage operations with registration: the act of recording that an artifact exists, where it is, and what context produced it.

This distinction matters because it means you can use the storage infrastructure your organization already has. The platform adds a traceability layer on top, making every artifact and deployment visible and queryable, without replacing existing tooling.

The two registration events

Two distinct events in the artifact lifecycle create the full traceability picture.

Build artifact registration

Build artifact registration happens when a workflow step produces an output worth tracking. A registration records the artifact’s name, version, storage URL, and content digest, along with source context including the commit hash, branch reference, and repository URL.

The artifact ID returned by registration is the platform’s handle for that artifact from this point forward. Every downstream operation (promotion, deployment, labeling, manifest inclusion) references this ID.

Without registration, an artifact is just a file in a storage system. With registration, it becomes a traceable record with provenance, version, and a known location.

Deployed artifact registration

Deployed artifact registration happens when a workflow step delivers an artifact to an environment. It links an artifact ID to a specific target environment, recording that a particular version of a component is now running somewhere.

These two events together close the loop. Build registration answers "what was produced and from what source?" Deploy registration answers "what is running where?" The gap between these two questions is where traceability most often breaks in practice: teams know what they built, but lose track of exactly which version is live in which environment. Both registrations together make the environment inventory in CloudBees Unify accurate and continuous.

Artifact storage and promotion

CloudBees Unify provides actions for common storage operations across the platforms teams typically use:

Amazon S3 for storing and retrieving file-based artifacts such as compiled binaries, archives, and build outputs.

Amazon ECR for storing and promoting container images within AWS infrastructure.

JFrog Artifactory for uploading, downloading, and promoting files and images in enterprise artifact repositories.

Crane for copying container images between registries, independent of cloud provider.

Each of these operations follows the same pattern: execute the storage action, then optionally register the result with CloudBees Unify so the artifact becomes trackable. Most storage actions include optional registration parameters for this reason.

Promotion is the practice of moving an artifact from one location to another as it progresses through delivery stages, for example copying an image from a development registry to a production registry after it passes testing. Promotion is a first-class pattern in CloudBees Unify: the promoted artifact is registered at its new location with a new artifact ID, preserving the chain of custody while reflecting the artifact’s current authoritative location.

Labels and version management

Artifact labels are mutable tags applied to immutable artifact records. An artifact version, once registered, does not change. But the labels on that version can be added and removed freely, reflecting evolving assessment of the artifact’s status.

This pattern is useful for release gating. A team might apply an approved label after security review passes, a release-candidate label after integration testing, and remove a hold label after a blocking issue is resolved. Downstream release workflows can check for specific labels before including an artifact in a release manifest, without needing to modify the artifact registration itself.

SBOMs as artifacts

A Software Bill of Materials (SBOM) is a structured inventory of the libraries, packages, and dependencies that a software artifact contains. Generating an SBOM at build time answers the question "what exactly is inside this binary?" This matters for security vulnerability assessment, license compliance, and supply chain visibility.

CloudBees Unify supports SBOM generation from container images and filesystems using the Syft scanner. The generated SBOM can be registered as an artifact alongside the binary it describes, following the same registration pattern as other artifact types. Security tooling in CloudBees Unify, including implicit SBOM analysis, can then consume registered SBOMs as part of ongoing security posture management.

Refer to Generate a software bill of materials for the workflow integration steps.

How artifacts connect to releases

A release manifest is a collection of artifact IDs, one per component, specifying exactly which registered version of each component should be deployed. When you create a release in CloudBees Unify, you are pinning specific artifact registrations into a versioned, auditable record.

The environment inventory view in an application reflects deployed artifact registrations across all environments. When a deployer workflow registers a deployment, the inventory updates to show which artifact version is live in each environment. This means the inventory is a live view of registered deployments, not a manually maintained record.

The connection between artifact management and the release model is therefore: registration produces the artifact IDs that go into manifests; deployment registration keeps the inventory accurate after those manifests are executed.

Related pages

Register and track artifacts