Skip to main content

Documentation Index

Fetch the complete documentation index at: https://enterprise-docs.crewai.com/llms.txt

Use this file to discover all available pages before exploring further.

​
nameOverride
string
default:""
Override the name of the chart. This affects resource naming throughout the deployment.Example:
nameOverride: "crewai-prod"
​
serviceAccount
object
Kubernetes ServiceAccount configuration for CrewAI Platform pods. Includes a name field and an annotations field for cloud provider Workload Identity or IRSA bindings.Default Behavior: When rbac.create: true (the default), the chart automatically creates a ServiceAccount named {release-name}-sa (typically crewai-sa). You do not need to set serviceAccount.name explicitly unless using a pre-existing ServiceAccount with rbac.create: false.Example - AWS IRSA:
serviceAccount:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/crewai-platform
Example - GCP Workload Identity:
serviceAccount:
  annotations:
    iam.gke.io/gcp-service-account: crewai@my-project.iam.gserviceaccount.com
Example - Pre-existing ServiceAccount:
rbac:
  create: false

serviceAccount:
  name: my-existing-serviceaccount
See Also: ServiceAccount Configuration for complete documentation including cloud provider Workload Identity setup, IRSA trust relationships, and troubleshooting.
​
crewNamespace
string
default:"crewai-crews"
Namespace where deployed crews will run.Purpose: Defines the Kubernetes namespace for crew workloads separate from the platform components.Example:
crewNamespace: "production-crews"
Note: Ensure this namespace exists before deploying crews, or configure the platform to auto-create it.
​
supportBundle.crewLogNamespaces
array
default:"[]"
Additional Kubernetes namespaces to collect crew workload logs from when generating support bundles.Purpose: When using multi-organization namespace isolation (where crews are deployed into multiple separate namespaces), configure this field to ensure support bundles capture logs from all crew namespaces.Default Behavior: When empty (default), support bundles only collect crew logs from crewNamespace. The chart automatically collects logs for pods with labels app=web, app=worker, and app=redis in the specified namespaces.When to Configure:
  • Using multi-organization namespace isolation with K8S_NAMESPACE_ISOLATION=true
  • Deploying crews into multiple namespaces beyond the default crewNamespace
  • Troubleshooting issues across multiple crew deployment namespaces
Example - Single Additional Namespace:
crewNamespace: "crewai-crews"
supportBundle:
  crewLogNamespaces:
    - "crewai-org1"
Example - Multiple Organization Namespaces:
crewNamespace: "crewai-crews"
supportBundle:
  crewLogNamespaces:
    - "crewai-org1"
    - "crewai-org2"
    - "crewai-org3"
Collected Resources:For each namespace listed in crewLogNamespaces, the support bundle collects:
  • Web pod logs (label: app=web)
  • Worker pod logs (label: app=worker)
  • Redis pod logs (label: app=redis)
  • Kubernetes events for the namespace
Note: This setting only affects support bundle collection. It does not create namespaces or configure namespace isolation. See the Multi-Organization Namespaces guide for namespace isolation setup.See Also: Troubleshooting Guide for instructions on generating support bundles.

​
Global Subchart Configuration

The global.* section provides configuration values shared across the main chart and all subcharts (PostgreSQL, MinIO, etc.).
​
global.fullnameOverride
string
default:"crewai"
Global override for the full name used across all charts and subcharts. When set, this takes precedence over chart-specific nameOverride values.Example:
global:
  fullnameOverride: "crewai-production"
Impact: This value is used as the prefix for all Kubernetes resources across all charts (Deployments, Services, StatefulSets, etc.). Changing this after initial deployment may cause resource recreation.
​
global.imageRegistry
string
default:"images.crewai.com"
Global container registry hostname override for all charts.Purpose: Provides a central location to configure the image registry for all container images in the deployment. Individual image configurations (image.host, buildkit.image.host, postgres.image.host, etc.) automatically fall back to this value when not explicitly set.Default: "images.crewai.com" - Replicated proxy registryFallback Behavior:When a component’s image.host is empty (""), the chart automatically uses global.imageRegistry. This allows you to:
  • Configure the registry once at the global level
  • Override specific components when needed
  • Simplify air-gapped deployments
Example - Global Registry Override:
global:
  imageRegistry: "registry.company.com"

# All components automatically use registry.company.com
image:
  host: "" # Uses global.imageRegistry
buildkit:
  image:
    host: "" # Uses global.imageRegistry
postgres:
  image:
    host: "" # Uses global.imageRegistry
Example - Mixed Configuration:
global:
  imageRegistry: "registry.company.com"

image:
  host: "" # Uses global.imageRegistry (registry.company.com)

postgres:
  image:
    host: "postgres-registry.company.com" # Override for PostgreSQL only
Use Cases:
  • Air-gapped deployments with internal registry
  • Using a pull-through cache registry
  • Corporate registry requirements
  • Simplified multi-component registry configuration
​
global.imageNamePrefixOverride
string
default:""
Optional prefix to override/replace image path prefixes when mirroring images to a private registry.Purpose: Simplifies image path structure by replacing complex multi-level paths (like proxy/crewai/dockerhub/library/) with a custom prefix. This is particularly useful when mirroring images to a private registry with a flatter organizational structure.Default: "" (empty - uses original image paths)Behavior: When set, this value REPLACES the entire path prefix in image names by extracting only the final image name component and applying the override prefix to it.Path Transformation Examples:Original image paths in the default configuration:
  • Main app: proxy/crewai/crewai/crewai-enterprise-platform
  • PostgreSQL: proxy/crewai/dockerhub/library/postgres
  • MinIO: proxy/crewai/dockerhub/minio/minio
  • Buildkit: proxy/crewai/crewai/crewai/buildkit
With imageNamePrefixOverride: "crewai/" (note: this replaces the path, not prepends):
  • Main app: crewai/crewai-enterprise-platform (not crewai/proxy/crewai/crewai/crewai-enterprise-platform)
  • PostgreSQL: crewai/postgres (not crewai/proxy/crewai/dockerhub/library/postgres)
  • MinIO: crewai/minio (not crewai/proxy/crewai/dockerhub/minio/minio)
  • Buildkit: crewai/buildkit (not crewai/proxy/crewai/crewai/crewai/buildkit)
Full Image Reference Construction:Without override:
<global.imageRegistry>/<original-image-path>:<tag>
# Example: images.crewai.com/proxy/crewai/dockerhub/library/postgres:16
With override:
<global.imageRegistry>/<imageNamePrefixOverride><final-component>:<tag>
# Example: 123456789012.dkr.ecr.us-west-2.amazonaws.com/crewai/postgres:16
Example - AWS ECR Private Registry:
global:
  imageRegistry: "123456789012.dkr.ecr.us-west-2.amazonaws.com"
  imageNamePrefixOverride: "crewai/"

image:
  registries:
    - host: "123456789012.dkr.ecr.us-west-2.amazonaws.com"
      credHelper: "ecr-login"

envVars:
  CREW_IMAGE_REGISTRY_OVERRIDE: "123456789012.dkr.ecr.us-west-2.amazonaws.com"
This configuration:
  1. Pulls all platform images from your ECR registry with simplified paths (e.g., crewai/postgres instead of proxy/crewai/dockerhub/library/postgres)
  2. Uses ECR credential helper for authentication
  3. Configures crew image storage in the same ECR registry
Affected Components:The imageNamePrefixOverride applies to all image references throughout the chart:
  • Main application image (image.name)
  • PostgreSQL image (postgres.image.name)
  • MinIO image (minio.image.name)
  • Buildkit image (buildkit.image.name)
  • Internal registry image (internalRegistry.image.name)
  • Busybox image (busybox.image.name)
  • Redis image (redis.image.name)
  • MinIO MC (client) image (used in init containers)
Automatic Environment Variable Updates:When imageNamePrefixOverride is set, the following environment variables are automatically updated to use the override prefix:
  • CONTAINER_REGISTRY_HOSTNAME: Uses <imageRegistry>/<imageNamePrefixOverride> instead of <imageRegistry>/proxy/dockerhub
  • AUTOMATION_ECR_REPOSITORY_PREFIX: Uses <imageNamePrefixOverride> instead of proxy/crewai/crewai/
  • BUSYBOX_IMAGE_OVERRIDE: Generated with override prefix
  • REDIS_IMAGE_OVERRIDE: Generated with override prefix
Use Cases:
  • Mirroring images to AWS ECR with simplified paths
  • Mirroring images to Azure ACR with organization prefix
  • Air-gapped deployments with custom registry structure
  • Simplifying image management in private registries
  • Compliance with corporate image naming conventions
Image Mirroring Workflow:Before deploying with imageNamePrefixOverride, you must mirror all required images to your private registry:
  1. Pull images from source registry (images.crewai.com)
  2. Tag with new simplified paths
  3. Push to your private registry
Example for PostgreSQL image:
# Pull from source
docker pull images.crewai.com/proxy/crewai/dockerhub/library/postgres:16

# Tag with simplified path
docker tag images.crewai.com/proxy/crewai/dockerhub/library/postgres:16 \
  123456789012.dkr.ecr.us-west-2.amazonaws.com/crewai/postgres:16

# Push to private registry
docker push 123456789012.dkr.ecr.us-west-2.amazonaws.com/crewai/postgres:16
Automatic Application:The chart automatically applies imageNamePrefixOverride to all component images throughout the deployment, ensuring consistent image path transformation.See Also:
​
global.imagePullSecrets
array
default:"[{name: \"docker-registry\"}]"
Global image pull secrets available to all charts.Schema:
global:
  imagePullSecrets:
    - name: "docker-registry"
    - name: "additional-registry-secret"
Purpose: Provides registry authentication credentials to all pods across all charts.Important: It is not recommended to set this value manually. When deployed via Replicated KOTS, the docker-registry secret is automatically created and configured with proxy registry credentials. Manual configuration should only be used for non-Replicated deployments or when additional registry secrets are required.