Skip to main content
Application sources define where your application comes from and how CNAP packages it for deployment. You can use from , 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

GitHub Repositories

Deploy applications directly from your GitHub repositories with automatic builds using . 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.

Connect GitHub Account

Get started by connecting your GitHub account or organization

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.
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 → and the generic chart →.
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.

Helm Charts

Deploy applications from the Helm ecosystem via Artifact Hub. 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 , and many charts come from verified publishers for added reliability.
Multiple Helm charts are automatically composed into a single versioned package with all dependencies bundled.
Look for charts with verified publisher badges for added reliability and security.

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

Docker Images

Deploy pre-built container images from any public . 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 -compatible registry

Image Format

Specify images using standard Docker notation:
nginx:latest
redis:7-alpine
ghcr.io/owner/image:v1.2.3
docker.io/library/postgres:15
public.ecr.aws/bitnami/wordpress:latest
For private images, configure your registry credentials in Settings → Registries. CNAP’s registry proxy handles authentication automatically. Learn more →

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

Learn More

Understand how CNAP generates packages from templates

Choosing the Right Source

Select the best deployment method for your use case:
Use CaseRecommended SourceWhy
Standard database (PostgreSQL, MySQL, MongoDB)Helm ChartsBattle-tested configurations, easy clustering
Custom web APIGitHub RepoFast iteration, automatic builds
Existing containerized appDocker ImageFull control, existing workflows
Open source applicationsHelm ChartsCommunity maintained, well documented
Rapid prototypingGitHub RepoQuick deployments, no container knowledge needed
MicroservicesGitHub Repo or DockerFlexible, supports both approaches

Security Considerations

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.
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.
Only use images from trusted registries. Verify image signatures when available. Scan images for vulnerabilities before deployment. Use specific version tags instead of latest.