Indice
La community paga il prezzo delle immagini gratuite
Cronologia della transizione (con brownout inclusi)
La community paga il prezzo delle immagini gratuite
Negli ultimi mesi la community DevOps ha assistito a un cambiamento che ha fatto discutere parecchio: Bitnami — oggi inglobata in Broadcom — ha deciso di chiudere l’era delle immagini Docker e Helm chart gratuite che per anni hanno facilitato i deployment Kubernetes.
Un passaggio che non solo mette in difficoltà migliaia di team che si affidavano a queste risorse, ma che rappresenta anche un segnale preoccupante: le community open-source non possono più dare per scontato il supporto gratuito da parte di vendor commerciali.
Cronologia della transizione (con brownout inclusi)
Per arrivare alla rimozione definitiva del catalogo pubblico, Broadcom ha scelto una serie di tappe progressive, con interruzioni programmate che hanno messo in crisi molti cluster:
- 28 agosto 2025 → avvio della transizione: le immagini gratuite non hardened sono state spostate su docker.io/bitnamilegacy, senza più aggiornamenti di sicurezza.
- 29 agosto 2025 → primo brownout di 24 ore: il catalogo pubblico è stato reso inaccessibile.
- 2–3 settembre 2025 → secondo brownout di 24 ore, con nuove interruzioni di accesso alle immagini.
- 17–19 settembre 2025 → terzo brownout, questa volta di 48 ore, che ha mostrato l’impatto reale di un futuro senza immagini pubbliche.
- 29 settembre 2025 → rimozione definitiva delle immagini dai repository pubblici. Da questa data, chi non aveva già migrato si è trovato con cluster in errore (ImagePullBackOff) e pipeline bloccate.
Queste finestre non sono state “incidenti”, ma veri e propri avvisi di sfratto, con l’obiettivo di spingere gli utenti verso alternative a pagamento.
Cosa è cambiato davvero
Dietro la narrativa ufficiale sulla “sicurezza” e le “immagini hardened”, la realtà è più semplice: Broadcom ha deciso di monetizzare un asset che per anni era stato gratuito.
- Le immagini Debian-based gratuite sono finite in bitnamilegacy e non riceveranno più patch.
- I tag versionati sono stati rimossi: restano solo pochi latest, inutilizzabili in contesti enterprise.
- Il catalogo pubblico è stato ridotto a poche immagini hardened, senza LTS né retrocompatibilità.
- È stata introdotta l’offerta a pagamento Bitnami Secure Images (BSI): un pacchetto con aggiornamenti, firme, SBOM e supporto. In altre parole, ciò che prima era disponibile per tutti ora è vincolato a una licenza enterprise.
L’impatto sulla community Kubernetes
La scelta ha colpito duramente non solo chi lavora in produzione, ma anche chi utilizza Kubernetes per test, formazione o progetti open-source.
Gli effetti principali:
- Blocchi operativi: chi non aveva un mirror interno si è trovato con applicazioni ferme.
- Aumento del rischio: continuare a usare immagini legacy significa accumulare vulnerabilità note.
- Perdita di fiducia: la community che per anni aveva fatto affidamento su Bitnami si ritrova ora costretta a riorganizzare pipeline e manifest.
- Costi non previsti: Broadcom spinge verso una soluzione a pagamento, lasciando chi non può (o non vuole) pagare senza alternative supportate.
Alternative concrete
Fortunatamente, la fine delle immagini gratuite Bitnami non significa che non esistano soluzioni.
Alcune opzioni già disponibili:
- Immagini ufficiali upstream → PostgreSQL, Redis, NGINX, WordPress e molte altre hanno repository mantenuti dalle community originali.
- Progetti community-driven → Chainguard, Red Hat UBI, Google Distroless offrono immagini minimali e sicure.
- Registry privati e self-hosting → replicare e mantenere in autonomia le immagini necessarie tramite Harbor, Nexus, Artifactory o simili.
- Build personalizzate → i sorgenti Bitnami restano open, quindi è possibile creare immagini personalizzate integrate con il proprio ciclo CI/CD.
Quindi come mitigare il problema? Se non l’hai ancora fatto, il consiglio è muoversi subito con:
- Inventario delle dipendenze → mappa tutte le immagini Bitnami usate nei tuoi cluster.
- Mirror interno → scarica e conserva le immagini critiche in un registry privato.
- Aggiornamento dei manifest → sostituisci i riferimenti a docker.io/bitnami.
- Adozione di pratiche di supply chain security → firma delle immagini, SBOM, scansioni CVE integrate nella CI/CD.
- Diversificazione dei fornitori → riduci la dipendenza da vendor che possono cambiare modello da un giorno all’altro.
Considerazioni finali
Il caso Bitnami/Broadcom è emblematico: affidarsi troppo a soluzioni gratuite fornite da aziende private è un rischio per la stabilità della supply chain.
Se da un lato il modello di business di Broadcom può essere legittimo, dall’altro la community si ritrova a pagare il prezzo di una scelta che privilegia i clienti enterprise a discapito dell’ecosistema open.
La lezione è chiara: per chi gestisce ambienti Kubernetes serve più indipendenza, maggiore consapevolezza delle proprie dipendenze e la capacità di non legarsi troppo a un singolo fornitore.
👉 E tu? Usi ancora immagini Bitnami nei tuoi cluster? Hai già migrato verso alternative? Raccontaci la tua esperienza, la community ha bisogno di condividere soluzioni concrete.
Emilio Veronesi
Fonti: