> ## 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.

# Application Sources

> Choose how to deploy your application with Helm Charts, GitHub repositories, or Docker images

Application sources define where your application comes from and how CNAP packages it for deployment. You can use <Tooltip headline="Helm Chart" tip="A Helm chart is a package of pre-configured Kubernetes resources. Charts define, install, and upgrade complex Kubernetes applications, making it easy to deploy applications with all their dependencies and configurations.">Helm charts</Tooltip> from <Tooltip headline="Artifact Hub" tip="Artifact Hub is a web-based catalog that finds and publishes packages and configurations for CNCF projects, including Helm charts. It provides a centralized catalog of thousands of pre-configured applications ready to deploy.">Artifact Hub</Tooltip>, GitHub repositories that build automatically, or pre-built Docker images. When you create a product with multiple sources, CNAP automatically generates a versioned package that combines all sources into a single, self-contained package.

## Source Types

<CardGroup cols={3}>
  <Card title="GitHub Repos" icon="github" href="#github-repositories">
    Auto-build from source code
  </Card>

  <Card title="Helm Charts" icon="box" href="#helm-charts">
    Deploy stacks from Artifact Hub
  </Card>

  <Card title="Docker Images" icon="docker" href="#docker-images">
    Deploy pre-built container images
  </Card>
</CardGroup>

## GitHub Repositories

Deploy applications directly from your GitHub repositories with automatic builds using <Tooltip headline="Railpack" tip="Railpack is a modern build system that transforms application source code into container images without requiring a Dockerfile. It uses BuildKit to run build steps in parallel for faster builds, analyzes your code to create optimized build plans, and uses granular caching to speed up subsequent builds.">Railpack</Tooltip>. Connect your GitHub accounts and organizations to access your repositories seamlessly.

When you connect a GitHub repository, Railpack analyzes your code and automatically detects your language and framework. It builds containerized applications without requiring a Dockerfile, with smart defaults for Node.js, Python, Go, Ruby, and more. This means you can push code and get containerized applications ready to deploy.

GitHub repositories work well for custom applications and APIs, rapid development and iteration, and modern web frameworks like Next.js, SvelteKit, FastAPI, and Django. They're also ideal for monorepos, microservices, and team projects where you want to integrate with your existing development workflow.

### Connecting GitHub

CNAP uses a GitHub App for secure, scoped access to your repositories. This provides enhanced security without storing personal access tokens, granular permissions to control which repositories are accessible, and team access so all workspace members can use connected repositories. You can connect both personal and organization accounts.

<Card title="Connect GitHub Account" icon="github" href="https://cnap.tech/installations/github">
  Get started by connecting your GitHub account or organization
</Card>

### Supported Languages and Frameworks

Railpack supports 10+ languages and frameworks with no configuration required for most projects:

* **Node.js** - Express, Next.js, SvelteKit, Remix, Nuxt
* **Python** - Django, FastAPI, Flask
* **Go** - Gin, Echo, Chi
* **Ruby** - Rails, Sinatra
* **Java** - Spring Boot, Quarkus
* **Rust** - Actix, Rocket, Axum
* **PHP** - Laravel, Symfony

### Deploying Open Source Projects

Deploy open source projects that don't have Helm charts or Docker images by forking them and deploying through GitHub repositories. This makes it easy to deploy any application that has source code, even if it hasn't been containerized or packaged yet.

Fork the project on GitHub, connect your fork to CNAP, and Railpack automatically detects the language and framework, builds the container image, and deploys it. You can customize the deployment configuration, add environment variables, and configure networking—all without writing a Dockerfile or creating a Helm chart.

This approach works well for projects that are still in development, applications that haven't been packaged for Kubernetes, or when you want to deploy a specific version or fork with custom modifications. You get the benefits of automatic containerization without the complexity of manual Docker builds or Helm chart creation.

<Note>
  GitHub repositories use CNAP's reusable GitHub Actions workflows to build images automatically. The built images are deployed using CNAP's generic application Helm chart. Learn more about [GitHub Actions →](/tools/github-actions) and the [generic chart →](/tools/generic-chart).
</Note>

<Tip>
  Many open source projects can be deployed in minutes by forking and connecting the repository, even if they don't have container images or Helm charts available.
</Tip>

## Helm Charts

Deploy applications from the Helm ecosystem via [Artifact Hub](https://artifacthub.io). Helm charts provide production-ready configurations maintained by the community, with thousands of applications available for databases, web servers, monitoring tools, and more.

You can search Artifact Hub directly in the product creation flow, selecting from popular applications or searching for specific packages. CNAP automatically generates a versioned package from your Helm chart sources and deploys it to your clusters. Configure pricing and make it available to customers.

Helm charts work well for standard software stacks like PostgreSQL, Redis, NGINX, WordPress, and Grafana. They're also ideal for enterprise applications with complex configurations and teams that already know Helm. You can customize applications using <Tooltip headline="Helm Values" tip="Helm values are configuration parameters that customize how a Helm chart is deployed. Values allow you to modify settings like resource limits, environment variables, and application settings without changing the chart itself.">Helm values</Tooltip>, and many charts come from verified publishers for added reliability.

<Note>
  Multiple Helm charts are automatically composed into a single versioned package with all dependencies bundled.
</Note>

<Tip>
  Look for charts with verified publisher badges for added reliability and security.
</Tip>

### Version Selection and Diversions

When creating application sources from Artifact Hub, you can select specific chart versions to control which version of a chart is used in your deployments. This allows you to:

* Pin to specific chart versions for stability
* Track different chart versions across multiple products
* Manage version updates independently for each application source

<Note>
  Support for selecting chart version in Artifact Hub when creating application sources is planned for a future release. This will provide more granular control over chart version selection and tracking.
</Note>

## Docker Images

Deploy pre-built container images from any public <Tooltip headline="Container Registry" tip="A container registry is a repository for storing and distributing container images. Popular registries include Docker Hub, GitHub Container Registry (GHCR), AWS ECR, and Quay.io. Registries allow you to pull pre-built images for deployment.">registry</Tooltip>. Docker images give you full control over the build process, work with any programming language or stack, and let you leverage images you've already built.

You can search for images from Docker Hub or AWS ECR Public Gallery, or manually enter an image URL from any public registry. CNAP pulls the image from the registry, automatically generates a versioned package, and deploys it to your selected clusters. Configure pricing and availability to make it available to customers.

Docker images work well for legacy applications with complex build requirements, multi-stage builds with specific optimizations, images requiring special dependencies or configurations, and teams with established Docker workflows.

### Searchable Registries

CNAP provides search functionality for two major container registries:

**Docker Hub** - Search millions of official and community-maintained container images. Docker Hub includes official images from software vendors and community contributions covering databases, web servers, development tools, and more.

**AWS ECR Public Gallery** - Search the AWS ECR Public Gallery, which aggregates container images from multiple registry aliases including Amazon, Docker, Bitnami, and AWS. ECR Public Gallery provides verified, production-ready images with detailed metadata and security scanning.

### Manual Image Input

You can also manually enter any Docker image URL from any public registry. This works with:

* Docker Hub (`docker.io/library/nginx:latest`)
* GitHub Container Registry (`ghcr.io/owner/image:tag`)
* AWS ECR (`public.ecr.aws/registry/repo:tag`)
* Quay.io (`quay.io/owner/image:tag`)
* Any other public <Tooltip headline="OCI" tip="OCI (Open Container Initiative) is an industry standard for container image formats and registries. OCI-compatible registries follow standardized protocols, making container images portable across different platforms and tools.">OCI</Tooltip>-compatible registry

### Image Format

Specify images using standard Docker notation:

```text theme={null}
nginx:latest
redis:7-alpine
ghcr.io/owner/image:v1.2.3
docker.io/library/postgres:15
public.ecr.aws/bitnami/wordpress:latest
```

<Tip>
  For private images, configure your registry credentials in **Settings → Registries**. CNAP's registry proxy handles authentication automatically. [Learn more →](/platform/private-registries)
</Tip>

## Package Generation

When you create a product with multiple sources, CNAP automatically generates a versioned package that combines all sources into a single, self-contained package. Each package has a <Tooltip headline="Semantic Versioning" tip="Semantic versioning is a versioning scheme using three numbers (major.minor.patch) like 1.2.3. The major number indicates breaking changes, minor indicates new features, and patch indicates bug fixes. This helps track changes and manage compatibility.">semantic version</Tooltip> (for example, `0.1.0`, `0.1.1`), all dependencies are bundled in the package, and it works with all Helm tools and GitOps workflows.

<Card title="Learn More" icon="box" href="/charts/chart-generation">
  Understand how CNAP generates packages from templates
</Card>

## Choosing the Right Source

Select the best deployment method for your use case:

| Use Case                                       | Recommended Source            | Why                                              |
| ---------------------------------------------- | ----------------------------- | ------------------------------------------------ |
| Standard database (PostgreSQL, MySQL, MongoDB) | **Helm Charts**               | Battle-tested configurations, easy clustering    |
| Custom web API                                 | **GitHub Repo**               | Fast iteration, automatic builds                 |
| Existing containerized app                     | **Docker Image**              | Full control, existing workflows                 |
| Open source applications                       | **Helm Charts**               | Community maintained, well documented            |
| Rapid prototyping                              | **GitHub Repo**               | Quick deployments, no container knowledge needed |
| Microservices                                  | **GitHub Repo** or **Docker** | Flexible, supports both approaches               |

## Security Considerations

<AccordionGroup>
  <Accordion title="Helm Charts">
    Verify publisher badges before deployment. Review chart source code when possible. Keep charts updated for security patches. Use CNAP's built-in scanning for vulnerabilities.
  </Accordion>

  <Accordion title="GitHub Repositories">
    Ensure repository is private if it contains secrets. Use environment variables for sensitive configuration. Review Railpack build logs for unexpected behavior. Enable branch protection on source repositories.
  </Accordion>

  <Accordion title="Docker Images">
    Only use images from trusted registries. Verify image signatures when available. Scan images for vulnerabilities before deployment. Use specific version tags instead of `latest`.
  </Accordion>
</AccordionGroup>

## Related Topics

* [Templates →](/products/templates) - Understand how sources become reusable templates
* [Package Generation →](/charts/chart-generation) - Learn how CNAP creates versioned packages
* [Create a Product →](/products) - Start deploying applications to your clusters
* [Clusters →](/clusters) - Set up infrastructure for your applications
* [Docker Compose Converter →](/tools/compose-converter) - Convert Docker Compose files to Kubernetes