Docker Desktop 4.71.0, rilasciato il 27 aprile 2026, introduce un cambiamento di comportamento che può rompere silenziosamente i workflow esistenti: Docker Model Runner è ora disabilitato per default. Chi lo ha configurato in versioni precedenti troverà il servizio spento dopo l’aggiornamento, senza errori espliciti al primo avvio.
Cosa cambia con il default disabilitato
Nelle versioni precedenti, Docker Model Runner si avviava automaticamente con Docker Desktop. A partire dalla 4.71.0, il servizio deve essere abilitato manualmente da Settings > Features in development > Enable Docker Model Runner.
Una volta abilitato, il supporto TCP lato host viene attivato automaticamente, senza bisogno di una configurazione separata. Il comportamento dell’API rimane invariato per chi lo riabilita.
L’impatto più probabile riguarda:
- Pipeline CI/CD locali che usano Model Runner per test con modelli LLM: se lo script presuppone che il servizio sia attivo, fallirà silenziosamente o con un errore di connessione.
- Docker Compose stack con servizi che dipendono dall’endpoint di Model Runner: la dipendenza non verrà risolta finché Model Runner non è esplicitamente abilitato.
- Script di setup ambiente che non includono il passaggio di abilitazione: dopo un aggiornamento o una reinstallazione su una macchina nuova, Model Runner non sarà disponibile.
Docker non ha comunicato le motivazioni esplicite del cambio nel changelog. Il pattern è coerente con una scelta di riduzione del footprint di default: Model Runner usa risorse (RAM e CPU) anche a riposo, e la maggior parte degli utenti non lo usa. Il modo più semplice per ridurre il consumo su macchine che non ne hanno bisogno è farne un opt-in.
Componenti aggiornati
La 4.71.0 include aggiornamenti ai componenti principali:
- Docker Engine 29.4.1
- containerd 2.2.3
- Runc 1.3.5
- Docker Compose 5.1.3
- Docker Agent 1.44.0
- Docker Model Runner v1.1.36
Fine del supporto per RHEL 8
La prossima versione di Docker Desktop richiederà RHEL 9 o RHEL 10 per l’installazione su Red Hat Enterprise Linux. Il supporto per RHEL 8 termina con la 4.71.0. Per i team che usano Docker Desktop su macchine con RHEL 8 nei propri ambienti di test o build, questo è il momento giusto per pianificare l’aggiornamento del sistema operativo prima che la prossima release lo renda obbligatorio.
Fix Mac
La 4.71.0 corregge un problema per cui il tracking degli errori continuava a trasmettere dati di sessione anche dopo che l’utente aveva disabilitato la raccolta dati analitici. Un fix di conformità alla preferenza dell’utente, non una correzione operativa — ma rilevante per chi opera in ambienti con policy di telemetria restrittive.
Cosa fare prima di aggiornare
Se usi Docker Model Runner nei tuoi workflow, conviene verificare quali script o pipeline assumono che il servizio sia già attivo e aggiungere un controllo esplicito o un passaggio di abilitazione. L’alternativa è abilitarlo manualmente subito dopo l’aggiornamento — bastano tre click nelle impostazioni — ma è meglio documentare il requisito prima che il prossimo collega reinstalli Docker su una macchina nuova e si chieda perché il modello non risponde.
