HI Alessio, we now have the source build. Try patching the operator and submitting a pull request. You should also be able to test it locally. Looking forward to seeing your contribution. Furthermore do not forget to sign the Apache ICLA https://www.apache.org/licenses/contributor-agreements.html and send it to [email protected]
Michele Sciabarra | CEO m: +44 747 984 8388 e: [email protected] l: https://linkedin.com/in/msciab Nuvolaris Inc | 1209 Orange Street, 19801Wilmington DE - US www.nuvolaris.io linkedin.com/in/msciab On Fri, 12 Jun 2026 at 10:26, Alessio Marinelli via dev < [email protected]> wrote: > Hi all, > I noticed that several templates in openserverless-operator use > busybox:1.36.0 as init container images pulled directly from Docker Hub: > - nuvolaris/templates/couchdb-init.yaml- > nuvolaris/templates/invoker-sts.yaml- > nuvolaris/templates/nginx-static-sts.yaml- > nuvolaris/templates/enterprise-sts.yaml- > nuvolaris/templates/kafka-001-sts.yaml > On clusters without Docker Hub credentials or subject to anonymous pull > rate limiting (100 pulls/6h per IP), these init containers fail > with ImagePullBackOff, blocking the entire pod from starting. > All these init containers only use basic shell commands (sh, wget, > nslookup) to wait for dependent services. No busybox-specific features are > required. > The rest of the project already avoids Docker Hub for third-party images ( > ghcr.io/nuvolaris/, docker.io/bitnami). I would like to submit a PR to > fix this consistently. > Proposed options:1. Publish ghcr.io/nuvolaris/busybox:1.36.0 (consistent > with existing conventions)2. Use cgr.dev/chainguard/busybox:latest > (public, no rate limiting)3. Replace init containers using an > already-present image > Could you advise on the preferred approach before I submit a PR? > Thanks,Alessio Marinelli >
