Provisioner CrashLoopBackOff: "unable to get provisioner key details"
Last updated: June 25, 2026
Problem
External provisioner pods fail to start with CrashLoopBackOff status and error message:
error: unable to get provisioner key details
Symptoms
- Provisioner pod repeatedly crashes and restarts
-
kubectl logsshows authentication/connection errors to Coder server - Provisioner cannot retrieve its pre-shared key from the Coder deployment
Root Cause
This issue occurs when the provisioner is configured to communicate with Coder through an external load balancer (e.g., AWS NLB) that performs TLS termination, rather than using the internal Kubernetes service URL.
The provisioner pod, running inside the same cluster as Coder, should communicate directly with the internal service to avoid:
- Certificate validation issues at the load balancer
- Unnecessary network hops
- TLS termination complexity
- Potential missing CA certificates for internal PKI
Solution
Update the provisioner Helm chart values.yaml with two changes:
1. Use the internal service URL
Change coder.url from the external load balancer address to the internal Kubernetes service:
coder: url: "http://coder-" # Replace with your actual Coder service name # Example: "http://coder" or "http://coder.coder-namespace.svc.cluster.local"
Do not use:
- External NLB/ALB URLs
- HTTPS endpoints with TLS termination
- Public DNS names
2. Configure certificate secrets
Add any required CA certificates or custom PKI:
coder:
url: "http://coder-"
certs:
secrets:
- name: your-ca-cert-secret-name3. Redeploy the provisioner
helm upgrade coder-provisioner coder-v2/coder-provisioner \ -f values.yaml \ --namespace coder
Verification
Confirm the provisioner is running successfully:
# Check pod status kubectl get pods -n coder -l app=coder-provisioner # Verify no crashes in logs kubectl logs -n coder -l app=coder-provisioner --tail=50 # Confirm provisioner registered with Coder # In Coder UI: Deployment > Provisioners
You should see the provisioner listed as "Connected" in the Coder admin UI.
Additional Notes
- Internal communication: Pods within the same Kubernetes cluster should always use internal service names for communication
-
Certificate handling: The Helm chart automatically mounts secrets specified in
coder.certs.secretsand configures the appropriate environment variables -
Service discovery: Use the format
..svc.cluster.localfor fully qualified internal DNS, or justif in the same namespace
Related Issues
- Provisioner authentication failures
- TLS certificate validation errors
- NLB/ALB hairpinning problems