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

# Automation Configuration

> Configuration for crew pod scheduling and resource placement.

The automation configuration controls how crew pods (automation workloads) are scheduled within your Kubernetes cluster. These settings apply to all crew pods provisioned by the platform, including web servers, workers, and Redis instances for each automation.

<Note>
  This feature requires chart version 0.1.14 or later.
</Note>

## `automation.podScheduling.*`

Scheduling constraints applied to every crew pod provisioned by this platform installation. These settings are applied to each crew pod at creation time.

<ParamField path="automation.podScheduling.nodeSelector" type="object" default="{}">
  Node selector labels for crew pod placement.

  **Purpose:** Constrains crew pods to nodes with specific labels, useful for dedicating certain nodes to automation workloads.

  **Default Behavior:** Empty object (`{}`) - no node selector constraints applied.

  **Example - Pin crews to dedicated node pool:**

  ```yaml theme={null}
  automation:
    podScheduling:
      nodeSelector:
        workload-type: "automation"
        node-role.kubernetes.io/worker: "true"
  ```

  **Example - Pin to specific cloud provider node group:**

  ```yaml theme={null}
  automation:
    podScheduling:
      nodeSelector:
        eks.amazonaws.com/nodegroup: "crew-workloads"
  ```

  **When to Use:**

  * Isolate automation workloads on dedicated nodes
  * Ensure crews run on nodes with specific hardware (GPU, high CPU, SSD)
  * Separate automation pods from platform infrastructure pods
</ParamField>

<ParamField path="automation.podScheduling.tolerations" type="array" default="[]">
  Tolerations for crew pods to schedule on tainted nodes.

  **Purpose:** Allows crew pods to be scheduled on nodes with matching taints, typically used in combination with `nodeSelector` to reserve nodes exclusively for automation workloads.

  **Default Behavior:** Empty array (`[]`) - no tolerations applied.

  **Example - Tolerate dedicated automation node pool:**

  ```yaml theme={null}
  automation:
    podScheduling:
      tolerations:
        - key: "workload-type"
          operator: "Equal"
          value: "automation"
          effect: "NoSchedule"
  ```

  **Example - Multiple tolerations:**

  ```yaml theme={null}
  automation:
    podScheduling:
      tolerations:
        - key: "automation-pool"
          operator: "Equal"
          value: "enabled"
          effect: "NoSchedule"
        - key: "gpu-workload"
          operator: "Exists"
          effect: "NoExecute"
  ```

  **Toleration Operators:**

  * `Equal` - Key and value must match
  * `Exists` - Only key must exist (value ignored)

  **Taint Effects:**

  * `NoSchedule` - Pods won't schedule unless toleration exists
  * `PreferNoSchedule` - Soft constraint (scheduler tries to avoid)
  * `NoExecute` - Evicts running pods without matching toleration
</ParamField>

<ParamField path="automation.podScheduling.affinity" type="object" default="{}">
  Advanced scheduling rules for crew pod placement.

  **Purpose:** Provides fine-grained control over pod scheduling using node affinity, pod affinity, and pod anti-affinity rules.

  **Default Behavior:** Empty object (`{}`) - no affinity rules applied.

  **Example - Require SSD nodes:**

  ```yaml theme={null}
  automation:
    podScheduling:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: "disktype"
                    operator: "In"
                    values: ["ssd"]
  ```

  **Example - Prefer specific availability zones:**

  ```yaml theme={null}
  automation:
    podScheduling:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              preference:
                matchExpressions:
                  - key: "topology.kubernetes.io/zone"
                    operator: "In"
                    values: ["us-west-2a", "us-west-2b"]
  ```

  **Affinity Types:**

  * `nodeAffinity` - Schedule based on node labels
  * `podAffinity` - Schedule near other pods
  * `podAntiAffinity` - Schedule away from other pods

  **Scheduling Modes:**

  * `requiredDuringSchedulingIgnoredDuringExecution` - Hard constraint (pod won't schedule if rule not met)
  * `preferredDuringSchedulingIgnoredDuringExecution` - Soft constraint (scheduler tries to satisfy but not guaranteed)
</ParamField>

## Complete Example

This example demonstrates isolating automation workloads on a dedicated, tainted node pool with specific hardware requirements:

```yaml theme={null}
automation:
  podScheduling:
    # Pin crews to dedicated automation nodes
    nodeSelector:
      automation-pool: "enabled"
      disktype: "ssd"
    
    # Allow scheduling on tainted automation nodes
    tolerations:
      - key: "automation-pool"
        operator: "Equal"
        value: "enabled"
        effect: "NoSchedule"
    
    # Require high-performance nodes
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: "node.kubernetes.io/instance-type"
                  operator: "In"
                  values: ["c5.2xlarge", "c5.4xlarge"]
```

## Important Notes

<Warning>
  Changing `automation.podScheduling` values requires two steps to take effect:

  1. Run `helm upgrade` to update the platform configuration (this restarts the platform pod)
  2. Redeploy existing crews for them to adopt the new scheduling constraints

  Kubernetes only applies scheduling fields (nodeSelector, tolerations, affinity) at pod creation time. Existing crew pods will continue running with their previous scheduling configuration until redeployed.
</Warning>

### Chart Version Requirement

This feature is available in chart version 0.1.14 or later. Earlier chart versions do not support automation pod scheduling configuration.

### Empty Values Behavior

The chart preserves empty values (`{}` for objects, `[]` for arrays) so the platform can distinguish between:

* **Unset** - Key not present (use platform defaults)
* **Reset to empty** - Key present but empty (explicitly remove constraints)

Leave a sub-key at its default empty value to omit that scheduling constraint type.