Enable or disable BuildKit deployment.Required For:
PROVIDER: BUILDKIT_KUBERNETES crew deployment mode.When Disabled: Crew container builds will fail unless using an alternative provider.Number of BuildKit daemon replicas.Recommendation: Single replica is sufficient for most deployments. Increase for high-concurrency build environments.
buildkit.image.*
BuildKit container image configuration.
Container registry hosting the BuildKit image.Default: Where
"" (empty) - Automatically uses global.imageRegistry valueFallback Behavior:When buildkit.image.host is empty or not set, the chart uses global.imageRegistry via the crewai-platform.buildkitImageRegistry template helper.Automatic Image Override:When buildkit.enabled: true, the chart automatically sets the BUILDKIT_IMAGE_OVERRIDE environment variable by combining these values:<registry> is determined by: buildkit.image.host OR global.imageRegistry (fallback)This allows the application to reference the same BuildKit image used by the BuildKit service, ensuring version consistency.When imageNamePrefixOverride is Set:The image name is automatically simplified:- Original:
proxy/crewai/crewai/crewai/buildkit - With
imageNamePrefixOverride: "crewai/"becomes:crewai/buildkit
BuildKit container image name.Default:
"proxy/crewai/crewai/crewai/buildkit" - Matches Replicated proxy path structurePath Transformation:When global.imageNamePrefixOverride is set, only the final component (buildkit) is used with the override prefix.BuildKit image version tag.Version Consistency: This tag must match the BuildKit version expected by the CrewAI Platform.
Image pull policy for BuildKit container.Valid Values:
"IfNotPresent"- Pull only if not cached locally (recommended)"Always"- Always pull latest version"Never"- Never pull, use local cache only
Image pull secret for BuildKit image. If empty, defaults to
image.pullSecret.buildkit.rootless.*
Rootless mode configuration for BuildKit. When enabled, BuildKit runs without requiring a privileged container, improving security by running as a non-root user with user namespace remapping.
Enable rootless BuildKit mode.Security Benefits:
- No privileged container required
- Runs as non-root user (UID 1000 by default)
- User namespace remapping for enhanced isolation
- Kubernetes nodes must allow
seccompProfile: UnconfinedandappArmorProfile: Unconfined - Some Kubernetes platforms (e.g., GKE Autopilot) may not support rootless mode
- Uses dedicated rootless BuildKit image
- Automatically configures security contexts and volume mounts
- Overrides
buildkit.usernssettings (deprecated)
BuildKit rootless container image name.Path Transformation:When
global.imageNamePrefixOverride is set, only the final component (buildkit-rootless) is used with the override prefix.BuildKit rootless image version tag.
User ID to run rootless BuildKit process.Default:
1000 (standard non-root user)Note: This value is used for both pod and container security contexts.Group ID to run rootless BuildKit process.Default:
1000Filesystem group ID for volume ownership.Default:
1000Purpose: Ensures proper volume permissions for rootless user.buildkit.service.*
BuildKit service configuration.
Service type for BuildKit.Valid Values:
"ClusterIP"- Internal cluster access (recommended)"NodePort"- Expose on node ports (development/testing)
Service port for BuildKit API.
NodePort when
type: NodePort.buildkit.userns.* (Deprecated)
Legacy user namespace configuration for enhanced container isolation.
Enable legacy user namespace remapping mode.Deprecation Notice: Use
buildkit.rootless.enabled: true instead for enhanced security without privileged containers.Security Benefit: Provides additional isolation by mapping container root user to unprivileged host user (when not using rootless mode).Note: This setting is ignored when buildkit.rootless.enabled: true.User ID to run BuildKit process (legacy mode only).Use With:
userns.enabled: true (when rootless.enabled: false)For Rootless Mode: Use buildkit.rootless.runAsUser insteadDefault: Undefined (runs as default user)Group ID to run BuildKit process (legacy mode only).Use With:
userns.enabled: true (when rootless.enabled: false)For Rootless Mode: Use buildkit.rootless.runAsGroup insteadDefault: UndefinedEnable OCI worker for BuildKit.Purpose: Provides OCI-compliant container runtime for builds.
Enable containerd worker for BuildKit.Purpose: Alternative runtime to OCI worker. Generally not needed.
Enable debug logging for BuildKit.Use Cases:
- Troubleshooting build failures
- Debugging registry authentication issues
- Performance analysis
Name of Kubernetes secret containing Docker config.json for registry authentication.Format: The secret should contain a
.dockerconfigjson key with base64-encoded Docker config.Example:Registry mirror and insecure registry configuration.Schema:Fields:
hostname: Registry hostnamehttp: Use HTTP instead of HTTPSinsecure: Skip TLS verificationmirrors: Mirror registries for pull-through
- Configure insecure internal registries
- Set up registry mirrors for faster pulls
- Configure air-gapped registry access
buildkit.healthcheck.*
Health check configuration for BuildKit pods.
Enable liveness and readiness probes for BuildKit.
Seconds to wait before first health check probe.Tuning: Increase if BuildKit takes longer to initialize.
Seconds between health check probes.
Health check probe timeout in seconds.
Consecutive successful probes required to mark pod healthy.
Consecutive failed probes before restarting pod.
buildkit.resources.*
Resource limits and requests for BuildKit container.
CPU limit for BuildKit pod.Performance Impact: CPU limits directly affect build performance. Higher limits = faster builds.Sizing Guidelines:
- Standard builds:
"4" - High-concurrency:
"8"or higher
Memory limit for BuildKit pod.Sizing Guidelines:
- Standard builds:
"8Gi" - Large/complex builds:
"16Gi"or higher
Guaranteed CPU allocation for BuildKit pod.Tuning: Start conservative, BuildKit scales based on build activity.
Guaranteed memory allocation for BuildKit pod.
Node selector for BuildKit pod placement.Example:
