Publish artifacts

This guide explains how to publish a deployable artifact as an Open Component Model (OCM) component version to an Open Container Initiative (OCI) registry. After you publish it, you can reference the component version or an alias in a VectorTemplate.

For background about artifacts, aliases, and vectors, see Vectors and artifacts.

Prerequisites

Before you begin, make sure you meet these requirements:

• The kden CLI is installed.
• You have the registry URL, configured credentials, and permission to push to the target OCI registry.
• Your deployable content is already available in an OCI registry. For example:
  • A Helm chart published as an OCI artifact.
  • A Kustomize bundle published as an OCI artifact.
• Your deployable content follows the requirements in Author a Helm artifact or Author a Kustomize artifact.

Create the Konfidence manifest file

Create a file named manifest.json. It tells Konfidence how to deploy the artifact and whether an artifact instance can be reused across deployments.

For a Helm chart, add:

{
  "type": "helm.konfidence.cloud",
  "allowReuse": true
}

For a Kustomize bundle, use kustomize.konfidence.cloud as the type value.

Set allowReuse based on how the artifact should be deployed:

• Set it to true only when one running artifact instance can safely serve multiple VectorDeployment resources at the same time.
• Set it to false when each VectorDeployment needs its own artifact instance.

Reuse does not require an artifact to be independent of vector-specific runtime context. A reusable service can read X-Vector-ID and use data for the current vector. It must handle the context separately for each request, forward the header on outbound calls, and isolate vector-specific state and cached data by vector ID. Set allowReuse to false if the service keeps one vector's configuration or state as a process-wide value. For more information, see Choose whether vectors share one instance of your artifact.

Create the OCM component constructor

Create component-constructor.yaml in the same directory as manifest.json:

components:
  - name: github.com/my-org/my-service
    version: 1.0.0
    provider:
      name: my-org
    resources:
      - name: my-service-manifest
        type: cloud.konfidence.artifact.manifest
        version: 1.0.0
        relation: local
        input:
          type: file/v1
          path: ./manifest.json
      - name: my-service-chart
        type: helmChart
        version: 1.0.0
        relation: external
        access:
          type: ociArtifact
          imageReference: registry.example.com/my-org/charts/my-service:1.0.0

The component constructor contains two resources:

• my-service-manifest connects the component to manifest.json through input.path. Each component must contain exactly one resource of type cloud.konfidence.artifact.manifest.
• my-service-chart references the deployable content that already exists in the OCI registry. Its access type must be ociArtifact, and imageReference must contain the full OCI path.

Validate the artifact files

Validate the component constructor before you publish it:

kden artifact validate --files ./component-constructor.yaml

The command checks the OCM schema and the Konfidence-specific artifact requirements. If validation succeeds, the command completes without output. Fix any reported errors before you continue.

Publish the artifact

Publish the component version to the OCI registry:

kden artifact push \
  --file ./component-constructor.yaml \
  --registry registry.example.com

The command validates the files, resolves the referenced OCI resources, calculates their digests, and writes the OCM component descriptor to the registry. If the command completes without an error, the component version is available as:

registry.example.com//github.com/my-org/my-service:1.0.0

You can use this component version in a VectorTemplate.

Optional: Sign the artifact

Signing is optional and recommended for production environments. Sign the component version before you create an alias:

kden artifact sign \
  registry.example.com//github.com/my-org/my-service:1.0.0 \
  --signer-spec ./signer-spec.yaml \
  --signature-name default

The command prints the signature as JSON and stores it with the component descriptor in the registry. For signer configuration and verification steps, see Configure signing and verification.

Optional: Create an alias

Create an alias when you want a VectorTemplate to track a moving artifact version, such as the latest build from the main branch:

kden artifact alias \
  registry.example.com//github.com/my-org/my-service:1.0.0 \
  main

If the command completes without an error, it has created or updated the main alias. The alias must not use semantic version format. You can then use this reference in a VectorTemplate:

registry.example.com//github.com/my-org/my-service:main

Next steps

Use the following guides to build vectors and review related artifact requirements:

• Build vectors from your published artifacts.
• Read Vectors and artifacts to understand how component versions and aliases become part of a vector.
• Check Author a Helm artifact or Author a Kustomize artifact for packaging requirements.
• Configure signing and verification if your environment requires signed artifacts.