Generic application chart

How Akua uses the generic Helm chart for GitHub repository and Docker image deployments

View repository

Browse the Helm charts repository.

When you deploy applications from GitHub repositories in Akua, your code is automatically built into a Docker image and deployed using Akua’s generic application Helm chart. This chart provides a production-ready deployment configuration without requiring you to create a Helm chart yourself.

What it is

The generic application chart is a Helm chart published at https://charts.akua.dev with the chart name app. It’s designed to deploy any Docker container image to Kubernetes with sensible defaults and extensive customization options.

While the chart is used by Akua for GitHub repository deployments, you can also use it directly with Helm if you want to deploy container images manually.

When Akua uses it

Akua automatically uses the generic chart when:

• Deploying from GitHub repositories: When you create a product or installation using a GitHub repository source.
• Using Docker images: When you deploy a Docker image without a custom Helm chart.
• Standalone installations: When you deploy a Docker image or GitHub repository directly to a cluster as a standalone installation, without packaging it as a product first.

The chart is automatically configured with your application’s settings, including:

• Container image and tag
• Resource limits and requests
• Environment variables
• Exposed ports
• Health checks
• Scaling configuration

Chart features

Container configuration

• Deploy any Docker container image with configurable pull policies
• Multiple ports and protocols (HTTP, HTTPS, TCP, gRPC, UDP)
• Override the container’s command (entrypoint) and args
• Environment variables with plain values or Kubernetes secretKeyRef
• Private registry support via Akua’s registry proxy

Gateway API integration

• HTTPRoute creation for external access with custom domains
• Support for multiple hostnames
• Path-based routing rules with header and query parameter matching
• Traffic splitting via additional backend refs and weights
• Request header modification filters
• Gateway parentRefs for routing through specific gateways (Cilium, Cloudflare, and others)

Health checks

• Liveness and readiness probes (disabled by default)
• HTTP, TCP, and exec probe types
• Configurable delays, intervals, timeouts, and failure thresholds

Scaling and resources

• Horizontal Pod Autoscaler (HPA) with CPU and memory utilization targets
• Configurable CPU and memory requests and limits
• Configurable replica count and min/max replicas

Advanced

• Init containers and sidecar containers
• Volume mounts and persistent storage
• Pod and container security contexts (runs as non-root by default)
• Node selectors, tolerations, and affinity rules
• Pod annotations and labels
• ServiceAccount creation and configuration

How it works

When you deploy from a GitHub repository:

1. Code is built: Your repository code is built into a Docker image using Railpack (via GitHub Actions workflows).
2. Chart is selected: Akua uses the generic app chart from https://charts.akua.dev as the upstream source.
3. Inputs are generated: Akua generates inputs from your deployment configuration (ports, env vars, resources, scaling, command/args, HTTPRoute hostnames).
4. Package is provisioned: Akua creates a private installation repository, vendors the chart, writes your inputs, and commits the rendered manifests.
5. Application runs: Your cluster syncs from the rendered manifests and runs your application.

For Docker image deployments, steps 2–5 are the same — the only difference is you provide the image directly instead of building from source.

Using the chart directly

The chart is published as a Helm repository:

helm repo add akua https://charts.akua.dev
helm repo update

You can inspect the chart directly:

helm show chart akua/app
helm show values akua/app

Customization

While Akua automatically configures the chart, you can customize the deployment through the Settings tab on any installed app (or during app creation):

• Ports: Configure container ports and expose them externally with hostnames.
• Environment variables: Add plain-text or secret configuration values.
• Scaling: Set replica count or enable HPA with CPU/memory targets.
• Resources: Set CPU and memory requests and limits.
• Command and args: Override the container’s entrypoint and arguments.

All customizations are automatically written to your installation’s inputs.yaml and applied on the next render.

Example inputs

Here’s an example of the inputs Akua generates for a typical Node.js application with an exposed port:

image:
  repository: ghcr.io/username/myapp
  tag: sha-abc123
  pullPolicy: IfNotPresent

replicaCount: 1

container:
  ports:
    - name: http
      containerPort: 3000
      protocol: TCP
  env:
    - name: NODE_ENV
      value: production
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secrets
          key: DB_PASSWORD
  command: []
  args: []

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 80

httpRoute:
  enabled: true
  hostnames:
    - myapp.example.com
  parentRefs:
    - name: cilium-gateway
      namespace: inst-abc123

Source code

The chart source code is available in the cnap-tech/charts repository. You can:

• Review the chart structure and templates
• Understand how it works
• Contribute improvements
• Use it as a reference for creating custom charts

Related topics

External access

Expose apps with custom domains via Gateway API.

GitHub Actions workflows

Build workflows that create images for this chart.

App sources

How GitHub repositories work as sources.

Installation repositories

How Akua packages and renders your application.