Crew Pod Scheduling

Overview

By default, crew pods (the autom-* web, worker, and Redis pods the platform spins up for every deployed automation) schedule on any node the cluster is willing to give them. automation.podScheduling lets you constrain that placement: pin them to a labeled node pool, tolerate a taint, or apply a full affinity rule. The chart passes your value through to the platform as CREW_POD_SCHEDULING (a JSON env var). The provisioner reads it at deploy time and renders nodeSelector, tolerations, and affinity on each crew pod’s spec — no per-crew configuration required.

When to use it

Isolate crew workloads on a dedicated node pool (cost tracking, blast-radius, compliance).
Force crews onto nodes with specific hardware — GPU, high CPU, SSD.
Send crews to spot / preemptible instances to lower cost.
Keep crews off nodes the platform itself runs on.

Leave it at the default ({} / [] on every sub-key) if any node in the cluster is fine.

What the chart expects

One block, under automation.podScheduling, with up to three sub-keys. Every sub-key maps 1:1 to the Kubernetes pod spec fields with the same name — no custom DSL, no renaming.

automation:
  podScheduling:
    nodeSelector: {}   # object — matches nodeSelector on a K8s pod
    tolerations: []    # array  — matches tolerations on a K8s pod
    affinity: {}       # object — matches affinity on a K8s pod

Rules:

Sub-keys are independent. Set the ones you need; leave the others at their default empty value. An empty sub-key is skipped — it does not clear anything else.
The shape is exactly the K8s pod spec. Copy-paste from a working pod manifest works. No wrapping, no translation.
The block applies to every crew pod — web, worker, and Redis — for every deployment provisioned by this install. There is no per-crew or per-org override.

Recipes

Pin crews to a labeled node pool

automation:
  podScheduling:
    nodeSelector:
      customer.com/pool: agents

Every crew pod lands on nodes labeled customer.com/pool=agents. If no matching node exists, the pod stays Pending.

Pin to a tainted, dedicated node pool

Label + taint the nodes, then match both:

automation:
  podScheduling:
    nodeSelector:
      customer.com/pool: agents
    tolerations:
      - key: customer.com/pool
        operator: Equal
        value: agents
        effect: NoSchedule

Without the toleration, the taint keeps the crew pod off the reserved nodes even though the selector matches.

Require SSD-backed nodes via affinity

automation:
  podScheduling:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: customer.com/disk
                  operator: In
                  values: [ssd]

required... is a hard constraint — pods stay Pending until a matching node exists. Use preferredDuringSchedulingIgnoredDuringExecution for a soft preference.

Combine all three

automation:
  podScheduling:
    nodeSelector:
      automation-pool: enabled
    tolerations:
      - key: automation-pool
        operator: Equal
        value: enabled
        effect: NoSchedule
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: node.kubernetes.io/instance-type
                  operator: In
                  values: [c5.2xlarge, c5.4xlarge]

Common pitfalls

Changes need a crew redeploy, not just helm upgrade. Kubernetes only applies nodeSelector, tolerations, and affinity at pod creation. After helm upgrade, existing crew pods keep their old scheduling until you redeploy the crew from the platform UI (or delete their pods so the operator recreates them). New crews pick up the new rules immediately.

The block replaces the platform’s default placement. When any sub-key is non-empty, it overrides the platform’s built-in workload-type / egress-group node placement for that constraint. This is deliberate — the intent is a full lift-and-shift of scheduling rules — but it means you own the whole picture. Include every selector / toleration your target nodes need.

Mind the YAML types. nodeSelector and affinity are objects ({}); tolerations is a list ([]). Getting the type wrong will fail Helm’s schema validation.

Verifying the change

After helm upgrade and a crew redeploy, confirm the scheduling landed:

kubectl -n <crew-namespace> get pod <autom-pod> -o jsonpath='{.spec.nodeSelector}{"\n"}{.spec.tolerations}{"\n"}{.spec.affinity}'

You should see the values you configured. If they are absent, the crew pod predates the upgrade — redeploy it.

Reference

Per-field defaults, types, and full ParamField reference: Automation Configuration Reference.
Kubernetes docs on scheduling: Assigning Pods to Nodes, Taints and Tolerations, Affinity and anti-affinity.

Core Configuration

Authentication

Built-In Integrations

Advanced

Overview

When to use it

What the chart expects

Recipes

Pin crews to a labeled node pool

Pin to a tainted, dedicated node pool

Require SSD-backed nodes via affinity

Combine all three

Common pitfalls

Verifying the change

Reference

​Overview

​When to use it

​What the chart expects

​Recipes

​Pin crews to a labeled node pool

​Pin to a tainted, dedicated node pool

​Require SSD-backed nodes via affinity

​Combine all three

​Common pitfalls

​Verifying the change

​Reference

Overview

When to use it

What the chart expects

Recipes

Pin crews to a labeled node pool

Pin to a tainted, dedicated node pool

Require SSD-backed nodes via affinity

Combine all three

Common pitfalls

Verifying the change

Reference