> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cnap.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Package Generation

> How CNAP automatically creates versioned, self-contained packages from your templates

When you create a product or update a template, CNAP automatically generates a versioned, self-contained <Tooltip headline="Helm" tip="Helm is a package manager for Kubernetes that simplifies deploying and managing applications. Helm charts package Kubernetes resources into reusable, versioned units.">Helm</Tooltip> package. This package combines all your sources into a single deployable unit that works with standard Helm tools and <Tooltip headline="GitOps" tip="GitOps is a methodology for managing infrastructure and application deployments using Git as the single source of truth. Changes are tracked in Git and automatically applied to your infrastructure.">GitOps</Tooltip> workflows.

## What Gets Generated

CNAP creates a standard Helm package that combines all your Helm charts and manifests into a single, self-contained unit. Each template update automatically creates a new versioned release (e.g., `0.1.0`, `0.1.1`). All dependencies are bundled together, so no external downloads are needed during deployment. Packages are validated before being made available to ensure they're ready to deploy.

## Package Contents

Each generated package is a standard Helm chart containing:

<Tabs>
  <Tab title="Chart.yaml">
    Contains package metadata including the package name (e.g., `template-abc123`), semantic version (like `0.1.0`), a dependencies list with all Helm chart sources converted to dependencies, and an auto-generated description based on the template name.
  </Tab>

  <Tab title="values.yaml">
    Contains merged configuration from all your sources. Helm chart values are nested under chart names or aliases, while custom manifest values are placed at the root level. All values are automatically organized and ready for deployment.
  </Tab>

  <Tab title="templates/">
    Contains custom Kubernetes manifests you've defined, such as ConfigMaps, Secrets, HTTPRoutes, and other Kubernetes resources. All manifests are placed directly in the templates directory.
  </Tab>

  <Tab title="charts/">
    Contains bundled dependencies that make your package self-contained. All Helm chart dependencies are downloaded and packaged with version-pinned references (no "latest" tags). Everything needed for deployment is included, so packages work even if original sources become unavailable.
  </Tab>
</Tabs>

## Source Metadata and Capabilities

CNAP tracks metadata about your sources to enable powerful capabilities:

<AccordionGroup exclusive>
  <Accordion title="Artifact Hub Integration" icon="box">
    When you add charts from Artifact Hub, CNAP stores chart information, documentation, version details, compatibility information, and repository metadata. This enables features like automatic documentation updates and chart information display.
  </Accordion>

  <Accordion title="Container Image Tracking" icon="image">
    For container images, CNAP tracks the image URL and tag, source repository information, and build metadata.
  </Accordion>

  <Accordion title="GitHub Workflow Integration" icon="code-branch">
    When you use images built from GitHub workflows, CNAP stores GitHub repository information, workflow run details, and build metadata. This enables automatic image updates when new builds complete, keeping your deployments current with the latest code.
  </Accordion>

  <Accordion title="Auto-Deploy Configuration" icon="rocket">
    Sources can be configured for automatic deployment, enabling automatic package regeneration when sources update, automatic deployment of new versions, and streamlined update workflows.
  </Accordion>
</AccordionGroup>

## Why This Matters

Traditional deployment approaches require coordinating multiple sources, managing dependencies, and dealing with version drift. CNAP's automatic package generation solves these problems:

### Predictable Deployments

> *Companies manually pin versions to prevent unexpected updates from external charts. They monitor external sources for breaking changes and manually lock dependency versions. This process is error-prone and time-consuming, and production deployments remain vulnerable to external source changes.*

CNAP automatically locks all dependencies at generation time. Every install uses the exact same package version, so you won't encounter surprises from unexpected updates. Production deployments are isolated from external source changes, eliminating entire classes of vulnerabilities and downtime risks.

### Self-Contained Packages

> *In practice, companies create wrapper charts around external dependencies to control versions and configurations. They manually track and bundle dependencies, ensuring deployments work even if sources become unavailable. This requires significant engineering effort and ongoing maintenance.*

CNAP automatically bundles all dependencies into your package. Dependencies are packaged automatically, eliminating the need for manual wrapper charts. Packages work offline with no external fetches during deployment. They're source-independent and work even if original sources become unavailable. Deployments are faster since a single download contains everything, and more reliable with no network dependencies during install.

### Version Control

> *Companies manually track version history and manage rollbacks. They document changes between versions and plan gradual rollouts carefully. This requires discipline and process to maintain.*

CNAP automatically creates a new package version with each template update. You get complete version history, the ability to rollback to previous versions, gradual rollout capabilities, and clear tracking of what changed - all without manual effort.

### Standard Helm Compatibility

Generated packages work with all Helm tooling. You can use `helm install`, `helm template`, and all Helm CLI commands. Packages work with GitOps tools and deployment platforms, are portable and can be used outside CNAP, and give you access to the entire Helm plugin ecosystem.

## How It Works

When you create or update a template, CNAP automatically:

1. **Fetches your sources** - Retrieves all Helm charts and custom manifests
2. **Merges configurations** - Combines values from all sources into a unified configuration
3. **Bundles dependencies** - Downloads and packages all Helm chart dependencies
4. **Validates the package** - Ensures everything is correct and ready to deploy
5. **Creates the package** - Generates a versioned `.tgz` file
6. **Stores it securely** - Saves the package and records the version

<Note>
  Package generation happens in the background, so it won't block your product creation. The process typically completes in under a minute.
</Note>

## When Packages Are Generated

Packages are automatically generated when:

* **Creating a product** - First package version is created from your sources
* **Updating a product** - New package version is generated with updated sources
* **Creating a direct install** - Package is generated for standalone deployments

<Warning>
  If you create an install immediately after creating a product, CNAP will wait up to 3 minutes for package generation to complete.
</Warning>

## Example: Creating Your First Product

Here's what happens when you create a product:

1. **You add sources** - Select PostgreSQL and Redis charts, configure their settings
2. **Template created** - CNAP automatically creates a template from your sources
3. **Package generation starts** - Background process begins creating your versioned package
4. **Package ready** - Your package is stored and ready to deploy

The entire process happens automatically. You can create installs immediately - CNAP handles the timing for you.

## Benefits

### For Your Business

* **Faster time to market** - No manual package creation or dependency management
* **Reliable deployments** - Every install uses the same tested package
* **Version tracking** - Complete history of all package versions
* **Simplified operations** - One package instead of coordinating multiple sources
* **Automatic updates** - Packages can regenerate automatically when sources change

### For Your Customers

* **Consistent deployments** - Same package version every time
* **Faster installs** - Pre-computed packages deploy quickly
* **No surprises** - Dependencies are locked, no unexpected changes
* **Reliable service** - Self-contained packages work even if sources change

## Related Topics

* [Templates Guide →](/products/templates) - Learn how templates work
* [Package Versioning →](/charts/versioning) - Understand version management
* [Create a Product →](/products) - See package generation in action
* [Application Sources →](/app-sources) - Learn about different source types
* [Generic App Chart →](/tools/generic-chart) - Understand the chart used for GitHub deployments