# Use auto-instantiation with `availablePackages`, `optional`, and

Use auto-instantiation when a cluster has a standard package for a dependency,
but should include it only when something needs it. Use an optional instance
when you also need to configure that dormant provider.

This guide assumes you already have packages whose required build arguments
describe their dependencies.

## Declare the dependencies

In the consuming package, make each dependency a required build argument. This
application reads values from `database` and `metrics`:

<Snippet {...autoInstantiatedDeps} />

Required arguments create demand. Kix first looks for a matching instance or
alias, then consults the cluster's package catalog.

## Add a default package to the catalog

Add the package under the dependency name in `availablePackages`. Set
`autoNamespace` if auto-instantiated packages should live in a shared
namespace:

<Snippet {...autoInstantiationCatalog} />

When an instance requires `database`, Kix creates a `database` instance in
`platform` with the package's default configuration. Without `autoNamespace`,
Kix creates it in the requesting instance's namespace. A `namespace` set on
the individual catalog entry takes precedence over `autoNamespace`.

## Keep a configured provider dormant

An `availablePackages` entry is instantiated with default configuration. When
the provider needs cluster-specific configuration, declare a normal instance
and set `optional = true`:

<Snippet {...optionalInstance} />

Kix excludes this instance when nothing depends on `metrics`. A required
`metrics` argument activates it with the configuration shown above.

## Add the consumer

Declare only the package you intend to run directly:

<Snippet {...autoInstantiationConsumer} />

The package's required arguments pull both providers into the evaluated
cluster. This also works transitively when an activated provider has required
dependencies of its own.

## Check the result

Evaluate the cluster:

<Command {...check} />

Inspect the dependency graph to confirm where the providers were created:

<Command expandable {...graph} />

The graph contains `database@platform`, `metrics@platform`, and `api@apps`.
Both provider ConfigMaps appear before the application ConfigMap that consumes
their outputs.

:::note[Explanation]
See [Dependency resolution and why explicit deps matter](/docs/v0.1/explanation/dependency-resolution-and-why-explicit-deps-matter/)
for how Kix chooses among explicit instances, aliases, and catalog packages.
:::

:::note[Reference]
See [`availablePackages`](/docs/v0.1/reference/cluster-module/availablepackages/),
[`autoNamespace`](/docs/v0.1/reference/cluster-module/autonamespace/), and
[`optional`](/docs/v0.1/reference/instance-schema/optional/) for the exact schemas.
:::