La tua Docker image è obesa. E ti sta costando una fortuna (e la sicurezza).

Ore due di notte, un deploy e l'amara verità: state spedendo un transatlantico dove basterebbe un gommone.

Ci siamo passati tutti. La macchinetta del caffè che rantola, la deadline che incombe, e una pipeline di CI/CD che si muove con la grazia di un elefante su un monociclo. Trascina immagini Docker colossali, gonfie di roba inutile, che intasano la rete e fanno lievitare i conti del cloud. E poi, la notifica di una nuova vulnerabilità critica. In una delle mille dipendenze di sviluppo che avete lasciato lì, in produzione. A questo punto, le notti insonni non sono più un'ipotesi, ma una certezza. Qui in ThinkPink Studio, che tu sia nella quiete di Rosignano Solvay o nel caos creativo di Kampala, la scena è sempre la stessa. Team brillanti, bloccati da un problema che sembra secondario. Ma non lo è. È un debito tecnico che vi sbrana il budget. È una falla di sicurezza che prega di essere sfruttata. È l'elefante obeso nella stanza, e sta seduto sulla vostra Docker image.

E se vi dicessi che la stessa, identica applicazione React, quella che pesa 760MB, può dimagrire fino a 94MB? Un taglio secco dell'87.6%. Non è un miracolo toscano né un rito ugandese. È pura, semplice e brutale efficienza ingegneristica. Si chiamano Build Multi-Stage in Docker, ed è una delle pratiche più criminalmente sottovalutate nel DevOps moderno. Ed è ora di usarle.

L'illusione della fase unica: la via più breve per il disastro.

Ragioniamoci sopra un secondo. L'approccio classico, quello single-stage, è un buffet all-you-can-eat per il vostro Dockerfile. Si prende un'immagine base bella comoda (tipo node:18), ci si butta dentro l'intero arsenale di sviluppo: Node.js, npm, compilatori, linter, cani e porci. Poi si fa la build dell'app e la si serve. Tutto nello stesso, unico, monolitico layer di grasso digitale. Facile da scrivere, certo. Un incubo da mantenere e deployare. L'immagine finale si porta in produzione l'intera officina, che non serve a niente se non a rendere tutto più lento, costoso e vulnerabile.

Questo approccio da "primo della classe pigro" genera mostri da oltre un Gigabyte. I nostri ragazzi a Kampala hanno dovuto fare i conti con questa roba su reti non esattamente stellari. Vi lascio immaginare il rosario di imprecazioni durante i trasferimenti. È un costo che non vedete in fattura alla fine del mese, ma che pagate in ore di attesa, in banda sprecata e in spazio di storage buttato. Un salasso silenzioso.

La dieta che funziona: i numeri non mentono.

Le build multi-stage sono la gastrectomia per le vostre immagini. Invece di una sola fase, ne create almeno due. La prima fase, che chiameremo "l'officina", fa tutto il lavoro sporco. Clona il codice, installa le dipendenze, compila, transpila, esegue i test. Fa tutto quello che serve per creare gli artefatti finali. La seconda e ultima fase, "la vetrina", parte da un'immagine pulitissima, anoressica. Un nginx:alpine, o ancora meglio, un'immagine 'distroless' di Google. E cosa fa? Semplicemente, con un comando `COPY --from=officina`, preleva solo ed esclusivamente i file statici generati nella prima fase e li mette al posto giusto. È come andare a una cena di gala: ti metti lo smoking, non ti porti dietro la macchina da cucire, il rocchetto di filo e il ditale.

I risultati? Parlano da soli. Ricerche aggiornate al 2026 confermano che le build multi-stage abbattono le dimensioni delle immagini Docker mediamente del 60-90%. Abbiamo visto un progetto di machine learning passare da un terrificante 4.3GB a un agile 76MB. Un taglio del 98.2%. Questo non è fuffa da marketing, sono vantaggi misurabili:

1. Immagini che pesano come un'email: Usare Alpine Linux (che pesa meno di un MP3) o le 'distroless' (che non hanno nemmeno una shell) è diventato il minimo sindacale. Meno roba da spingere sui registry, meno spazio occupato, meno soldi regalati ad Amazon, Google o Microsoft. Semplice.

2. CI/CD che sembra fantascienza: Immagini piccole significano pull e push che durano secondi, non minuti. Le aziende che hanno messo in pratica questa roba nel 2026 parlano di cicli di rilascio più veloci del 50-80%. Se poi si usa con intelligenza la cache dei layer di Docker (copiando prima il `package.json` e solo dopo il resto del codice), le build diventano quasi istantanee se le dipendenze non cambiano. Piattaforme come CircleCI o GitHub Actions sono nate per questo, ignorarlo è masochismo.

3. Una porta blindata al posto di una tenda: Ogni singolo pacchetto inutile che vi portate in produzione è una potenziale porta di servizio per chi ha cattive intenzioni. Togliendo compilatori, tool di debug e dipendenze di sviluppo, la superficie d'attacco si riduce a zero o quasi. Se un malintenzionato buca un container del genere, si ritrova in una stanza vuota. Niente shell, niente `curl`, niente di niente. Se a questo aggiungete l'uso di utenti non-root e la scansione delle vulnerabilità in pipeline, iniziate a dormire sonni tranquilli. Nel 2026, con l'ossessione per le SBOM (Software Bill of Materials) e le immagini firmate, non farlo non è più un'opzione, è una colpa grave.

La nostra filosofia: tra la cinta senese e la resilienza di Kampala.

Una cosa che abbiamo imparato qui in ThinkPink Studio è che questa non è una roba da big tech. Anzi. Per la PMI italiana, quella che misura ogni centesimo, ottimizzare è una questione di sopravvivenza. La precisione quasi maniacale che abbiamo nel DNA qui in Toscana ci impone di guardare a questi dettagli. Ogni euro risparmiato in storage, ogni ora-uomo non passata a fissare una barra di caricamento, è un euro e un'ora che reinvestiamo per spaccare sul mercato. È così che si compete.

Dall'altra parte del mondo, il nostro team di Kampala usa questo approccio per necessità. Lì, dove la connettività può essere un lusso, un'immagine leggera non è un vezzo da ingegneri, è la condizione necessaria per poter lavorare. È la dimostrazione che l'efficienza non è un obiettivo, ma un mindset. È questo che permette a un'anima divisa tra Rosignano e l'Uganda di avere la stessa agilità di chi sta nella Silicon Valley.

Smettetela di chiamarlo trend. È il nuovo standard.

Nel 2026, le build multi-stage non sono più un argomento da conferenza per nerd. Sono le fondamenta. L'evoluzione di Docker (siamo alla versione 26.1.3, tenetevi aggiornati) e il martellamento su DevSecOps e SBOM lo urlano ai quattro venti. L'ottimizzazione non è più un'opzione. Chi non si adegua, sta semplicemente scegliendo di pagare di più, essere più lento e dormire peggio la notte.

L'idea di mettere in produzione un'app React con dentro tutto Node.js e la sua paccottiglia è, per dirla senza troppi giri di parole, una stupidaggine. La soluzione c'è, è elegante, è robusta, e si scrive in dieci righe di Dockerfile: una fase per costruire, una fase per servire con un Nginx leggero. Punto.

Da noi, in ThinkPink, i "Saggi Ribelli" non sono quelli che usano l'ultima tecnologia uscita ieri, ma quelli che usano la tecnologia giusta, nel modo giusto. Adottare le build multi-stage è questo: costruire software che non solo va online oggi, ma che è pronto a reggere l'urto di domani. Più sicuro, più veloce, più solido. A prova di futuro, e a prova di budget.

Dobbiamo mettere le mani nel vostro Dockerfile? Scriveteci. Senza impegno, ma anche senza fronzoli.