Jitendra Singh Bisht
05/14/2026, 12:22 AMkapa.ai
05/14/2026, 12:22 AMuseConnectorResourceDefaults: false, persisted actor definitions in the database may take precedence over Helm values and environment variables. [Resource limits ignored]
Available Workarounds 1. Set resource overrides directly at the connection level via SQL UPDATE connection
SET resource_requirements = jsonb_build_object(
'cpu_request', '0.5',
'cpu_limit', '2',
'memory_request', '1Gi',
'memory_limit', '4Gi'
)
WHERE id = '<your-connection-id>';
> ⚠️ Note: This applies to source/destination containers. There is currently no direct override for the orchestrator container via this method. [Orchestrator ignores limits]
2. Set env vars directly on the workload-launcher deployment (not just ConfigMap) workloadLauncher:
extraEnv:
- name: JOB_MAIN_CONTAINER_CPU_LIMIT
value: "4"
- name: JOB_MAIN_CONTAINER_CPU_REQUEST
value: "2"
- name: JOB_MAIN_CONTAINER_MEMORY_LIMIT
value: "8Gi"
- name: JOB_MAIN_CONTAINER_MEMORY_REQUEST
value: "4Gi"
Verify the values are actually visible to the pod:
kubectl exec -n airbyte deploy/airbyte-workload-launcher -- env | grep JOB_MAIN
3. Kubernetes Mutating Webhook (for orchestrator container specifically) If the orchestrator container is stuck at 1Gi, a MutatingWebhookConfiguration can intercept pod CREATE requests and patch the orchestrator container's memory. It targets pods with label airbyte=job-pod. This has been confirmed to work by multiple users. [Orchestrator ignores limits]
Status This is an open bug tracked internally by the Airbyte engineering team. There is no native fix available yet. The issues are tracked at:
• #72833 — orchestrator memory always 1Gi
• #73346 — resource limits ignored by abctl/workload-launcher 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.