Types of artifacts

An artifact is a deployable part of your application, such as a microservice, packaged as an Open Component Model (OCM) component. A vector references artifacts by version, and a deployer renders each one into a landscape.

The component holds your deployable content, such as a Helm chart or a Kustomize bundle, and a small manifest. The manifest names the required deployment class and states whether one running instance may serve several vectors. The authoring guides show both.

A vector bundles artifacts. Each artifact bundles a manifest and its deployable content.

Choose a deployment class

The artifact manifest's type is a deployment-class identifier. It selects both the deployer that understands the artifact and the capability a target landscape must provide.

Before choosing a class, confirm that the landscapes where the artifact will run have a matching deployment target. See the Deployment model for the complete relationship and Configure deployment targets for a landscape for the operator workflow.

Konfidence deploys these artifact types

The Kubernetes deployer supports both Helm and Kustomize.

Choose the type that matches the deployment configuration you already maintain:

• If your service has a Helm chart, follow Author a Helm artifact.
• If your service has Kubernetes manifests organized with Kustomize, follow Author a Kustomize artifact.

If both formats are available, follow your team's existing release workflow. You do not need to convert your deployment configuration for Konfidence.

Deployers are extensible. To add a deployment method or a target platform, see Extend & Customize.

Choose whether vectors share one instance of your artifact

The manifest field allowReuse decides how many running instances of your artifact exist in a landscape. Set it explicitly for every artifact.

How the deployer scopes an instance

The deployer derives the name of an instance from the artifact, its version, and the reuse policy:

• allowReuse: false: the instance name also includes the vector. Every vector gets its own copy, even for the same artifact version.
• allowReuse: true: the instance name does not include the vector. All vectors in the landscape that reference the same artifact version share one copy.

Changing allowReuse changes the instance name. The next deployment creates a new instance next to the old one.

Why reuse exists

Without reuse, 10 vectors that reference the same stable version of a service run 10 copies of it. Reuse reduces that to one. It saves cluster resources and shortens activation. A new vector uses a running instance instead of starting its own.

Reuse also fits services you never want to duplicate, such as a shared backend with its own data.

What reuse demands from your service

A shared instance receives requests from several vectors at once. Those vectors can reference different versions of the other services. Vector A may pair my-service 1.0.0 with checkout 2.3.0, while vector B pairs it with checkout 2.4.0.

One shared instance serves two vectors and calls the service version that belongs to each request's vector.

The same holds when the shared instance sits downstream. Each vector's own frontend calls one shared catalog instance and passes its vector ID along.

Two vector-specific frontends fan in to one shared instance. The vector ID travels with every call.

Your service must therefore handle vector-specific behavior in the context of each request:

• Read X-Vector-ID from each request and forward it on every outbound call.
• Resolve the addresses of other services, feature flags, and configuration for the current vector through the vector data service instead of loading one vector's values once at startup.
• Key cached vector data by vector ID. Never use one process-wide cached value for requests from different vectors.
• Keep vector-specific state isolated by vector ID so that requests from one vector cannot read or modify another vector's state.

Choose allowReuse: true when

Set allowReuse to true only when one running instance can safely serve several vectors at the same time and your service meets every demand above.

Reuse is especially useful when:

• The service is expensive to run, slow to start, or must exist only once.
• Vectors in a landscape mostly reference the same version of the service.

Choose allowReuse: false when

Set allowReuse to false when any of the following applies:

• Your service loads vector-specific configuration once at startup and uses it for every request.
• Your service hard-codes the addresses of other services or assumes fixed versions of those services.
• Your service cannot isolate vector-specific state or cached data by vector ID.
• Your service requires a dedicated running instance for each vector, for example because its lifecycle must be managed independently.
• You want each vector fully isolated, for example for load tests, or for destructive experiments.

Next steps

Use the following guides to prepare and publish your artifact:

• Author a Kustomize artifact
• Author a Helm artifact
• Publish artifacts to package and push an artifact to a registry.