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

# Global Configuration

<ParamField path="nameOverride" type="string" default="">
  Override the name of the chart. This affects resource naming throughout the deployment.

  **Example:**

  ```yaml theme={null}
  nameOverride: "crewai-prod"
  ```
</ParamField>

<ParamField path="serviceAccount" type="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:**

  ```yaml theme={null}
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/crewai-platform
  ```

  **Example - GCP Workload Identity:**

  ```yaml theme={null}
  serviceAccount:
    annotations:
      iam.gke.io/gcp-service-account: crewai@my-project.iam.gserviceaccount.com
  ```

  **Example - Pre-existing ServiceAccount:**

  ```yaml theme={null}
  rbac:
    create: false

  serviceAccount:
    name: my-existing-serviceaccount
  ```

  **See Also:** [ServiceAccount Configuration](/reference/chart-values/service-account) for complete documentation including cloud provider Workload Identity setup, IRSA trust relationships, and troubleshooting.
</ParamField>

<ParamField path="crewNamespace" type="string" default="crewai-crews">
  Namespace where deployed crews will run.

  **Purpose:** Defines the Kubernetes namespace for crew workloads separate from the platform components.

  **Example:**

  ```yaml theme={null}
  crewNamespace: "production-crews"
  ```

  **Note:** Ensure this namespace exists before deploying crews, or configure the platform to auto-create it.
</ParamField>

<ParamField path="supportBundle.crewLogNamespaces" type="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:**

  ```yaml theme={null}
  crewNamespace: "crewai-crews"
  supportBundle:
    crewLogNamespaces:
      - "crewai-org1"
  ```

  **Example - Multiple Organization Namespaces:**

  ```yaml theme={null}
  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](/features/multi-org-namespaces) guide for namespace isolation setup.

  **See Also:** [Troubleshooting Guide](/troubleshooting#generate-support-bundle) for instructions on generating support bundles.
</ParamField>

### Global Subchart Configuration

The `global.*` section provides configuration values shared across the main chart and all subcharts (PostgreSQL, MinIO, etc.).

<ParamField path="global.fullnameOverride" type="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:**

  ```yaml theme={null}
  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.
</ParamField>

<ParamField path="global.imageRegistry" type="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 registry

  **Fallback 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:**

  ```yaml theme={null}
  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:**

  ```yaml theme={null}
  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
</ParamField>

<ParamField path="global.imageNamePrefixOverride" type="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:**

  ```yaml theme={null}
  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:

  ```bash theme={null}
  # 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:**

  * [Container Registry Configuration](/reference/chart-values/environment-variables#container-registry-configuration) - Related environment variables
</ParamField>

<ParamField path="global.imagePullSecrets" type="array" default="[{name: &#x22;docker-registry&#x22;}]">
  Global image pull secrets available to all charts.

  **Schema:**

  ```yaml theme={null}
  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.
</ParamField>