Basta con il 'da me funziona': come Dinghy ci ha salvato da nottate insonni e fatture gonfiate.

Il deploy del venerdì sera. Un classico.

Le ultime righe di codice sono scritte, i test passano che è un piacere, la macchinetta del caffè implora pietà. Clicchi. E si scatena l'inferno. Un'oscenità di errore che non avevi mai visto, quella libreria che fino a cinque minuti fa andava e ora ti guarda come se venisse da Marte, o il redivivo bug di sei mesi fa che torna a perseguitarti. Se hai fatto questo mestiere, sai di cosa parlo. Non è solo una scocciatura. È un buco nero che risucchia tempo, soldi e la tua sanità mentale. A Rosignano abbiamo visto team perdere settimane su problemi che non erano nel codice, ma nell'infrastruttura fantasma che ci girava sotto. Una guerra persa in partenza se non cambi le regole del gioco. Ecco, parliamo di come abbiamo iniziato a barare, usando Dinghy.

Il costo di un team che non parla la stessa lingua (infrastrutturale)

Guardiamo in faccia la realtà. La gestione delle dipendenze nel 2026 non è più un dettaglio tecnico, è un costo operativo mascherato da "imprevisto". I numeri non mentono: uno studio del 2025 ha calcolato che un dev spreca in media 4.3 ore a settimana a combattere con le dipendenze. Fanno quasi un mese di lavoro all'anno. Buttato. Perso a rincorrere fantasmi tra versioni di pacchetti, breaking changes e conflitti che nemmeno in un film di spionaggio. Questo disastro, che i fighi chiamano "dependency hell", non ti rallenta e basta. Ti espone. Nel 2025, gli attacchi alle supply chain del software, sfruttando pacchetti open-source farlocchi, sono aumentati del 73%. Ogni dipendenza non aggiornata perché "sennò si spacca tutto" è una porta aperta che lasci a chi vuole farti del male.

L'Infrastructure as Code (IaC) dovrebbe essere la soluzione, no? Certo, se non fosse che senza un minimo di disciplina, è come dare un lanciafiamme a un bambino. Il mercato dell'IaC arriverà a 2.03 miliardi di dollari nel 2026, e con l'avvento di generatori di codice basati su AI, ci troveremo sommersi da una valanga di configurazioni. Più codice, più possibilità di fare un casino. La governance e la sicurezza non possono essere una "pezza" che metti alla fine. Devono essere il punto di partenza. Come ci ripetono fino alla nausea i profeti della DevSecOps.

Dinghy: l'unica cosa su cui essere d'accordo quando tutto va a fuoco

Dinghy è nato per questo. Per spegnere l'incendio. L'idea è talmente semplice da essere quasi brutale: un solo comando, una sola installazione, un unico modo per descrivere come le cose devono funzionare. E tutto, ovviamente, come codice. La maledizione del "da me funziona" finisce qui. Dinghy è quel coltellino svizzero che usi per svitare il bullone giusto in un motore che sta per esplodere.

La promessa è la coesione attraverso il codice. Permette di orchestrare un sacco di roba diversa che di solito vive in mondi separati:

• Diagrams as Code: Basta diagrammi di architettura disegnati a mano e dimenticati in una cartella. Qui vengono generati da metadati, sempre aggiornati, sempre coerenti. Nel 2026, un diagramma non è un disegnino, è un artefatto compilato che un'AI può leggere per capire come gira il sistema.
• Infrastructure as Code (con la finezza di React TSX): Questa è la vera genialata. Scrivere l'infrastruttura con la stessa logica con cui costruisci una UI. A Rosignano, i nostri sviluppatori front-end hanno iniziato a scrivere IaC senza nemmeno accorgersene. Modularità, componenti, testabilità. Un altro pianeta rispetto a certi linguaggi dichiarativi un po' ingessati.
• Site Builder: Tira su siti di documentazione con Docusaurus. La doc, quella cosa che nessuno vuole mai fare, diventa parte del flusso, si aggiorna da sola. Meno scuse per tutti.
• Slide Builder: Anche le presentazioni per i clienti diventano codice. Versionabili, collaborabili. Con un piccolo extra: uno zoom tipo Prezi che fa sempre la sua porca figura.

Deno e Docker: la polizza assicurativa contro il "codice marcio"

Sotto il cofano, Dinghy usa Deno e Docker. Una coppia che va dritta alla radice del problema. Invece di bestemmiare con le versioni di Node, i virtualenv di Python o i provider di Terraform, Dinghy impacchetta tutto in un'immagine Docker. Fine della discussione.

• Versioni che non mentono: Con un singolo file .dinghyrc, ogni singola macchina del team, da Milano a Kampala, usa le stesse, identiche, spiccicate versioni di tutto. Il "funziona sulla mia macchina" diventa, finalmente, "funziona ovunque". Le pipeline di CI/CD ringraziano.
• Container, quelli seri: Docker non è una moda, è uno standard. Usare container leggeri e ottimizzare la cache ci ha salvato ore di attesa nelle build.
• Mai più codice in decomposizione: Hai presente quel progetto di due anni fa che non compila più perché metà delle dipendenze è morta o è cambiata? Un brutto ricordo. Questo approccio blinda la supply chain. In un'epoca in cui gli attacchi si basano proprio su questo, è come avere un caveau.

Mentre il 71% dei team ammette che l'AI generativa sta facendo esplodere la quantità di IaC e il 63% dice che è un incubo governarla, avere uno strumento come Dinghy che impone un po' di sano rigore non è un'opzione, è pura sopravvivenza.

OpenTofu: perché l'open source (quello vero) vince sempre

La scelta di Dinghy di integrare OpenTofu è una dichiarazione d'intenti. Dopo le recenti capriole di HashiCorp con la licenza BSL e l'acquisizione da parte di IBM, la community ha reagito. E ha reagito bene. OpenTofu è la dimostrazione che il vero open source non lo metti in un angolo.

Terraform è ancora il re del mercato, con oltre il 32.8% di share nel 2026, ma OpenTofu non è un clone sbiadito. Ha un paio di assi nella manica:

• Crittografia dello stato. Nativa: Permette di criptare il file di stato a riposo senza fare i salti mortali. Per chiunque tratti dati sensibili o debba rispettare normative come HIPAA o PCI-DSS, questa non è una feature, è la pace dei sensi.
• Governance trasparente: Essendo un progetto della Linux Foundation, le regole sono chiare. Niente cambi di licenza notturni, niente "vendor lock-in" mascherati.
• Migrazione indolore: Per la maggior parte dei progetti, passare da Terraform a OpenTofu è questione di cambiare un binario. Un'operazione a zero rimpianti.

Usare Dinghy con OpenTofu permette ai nostri team, sia a Kampala dove la rapidità è tutto, sia a Rosignano dove la robustezza è legge, di costruire infrastrutture che non solo funzionano oggi, ma che saranno manutenibili anche domani. Senza dover chiedere il permesso a nessuno.

Dalla Val di Cecina alla Silicon Savannah: il nostro modo di fare le cose

In ThinkPink Studio abbiamo questa fissa. Crediamo che l'approccio al problema, quasi testardo, che impari lavorando con le PMI toscane, unito alla capacità di trovare soluzioni impensabili che vedi ogni giorno a Kampala, sia un mix esplosivo. Per una piccola o media impresa italiana, oggi, usare un accrocchio come Dinghy non è un vezzo da startupper. È una necessità.

Pensa cosa vuol dire avere tutta la tua architettura, dai server ai diagrammi, dalla documentazione alle slide per gli investitori, in un unico posto. Versionata. Riproducibile. Questo non solo fa a pezzi il debito tecnico e i costi nascosti. Questo ti dà una velocità disumana. Ti permette di giocare nello stesso campionato di una multinazionale, ma con l'agilità di chi sa ancora come si tira su una pezza al volo.

Tutti parlano di "Platform Engineering". È il trend del 2026. L'idea è semplice: costruire una piattaforma interna che renda la vita dei dev più facile, automatizzando le rotture di scatole. Dinghy è esattamente questo. Un pezzo fondamentale per costruire la tua "fabbrica" di software. Per trasformare il caos in un vantaggio competitivo.

La tua infrastruttura è codice. Fattela piacere, perché non si torna indietro.

Questo mondo corre. Quello che oggi è rivoluzionario, domani è scontato. L'unica cosa che conta è la capacità di adattarsi, di essere solidi, di non andare a gambe all'aria al primo imprevisto. Dinghy non è l'ennesimo tool da imparare. È un modo di pensare. Un modo più adulto, più sostenibile di scrivere software.

Portare tutto "as Code", dai disegni all'infrastruttura, dalla documentazione al deploy, non è più una scelta. È un imperativo. Significa smettere di sperare che le cose funzionino, e iniziare a progettarle perché non possano fare altro. Significa costruire software che non solo "gira", ma è fatto bene, è sicuro. Ed è pronto per qualunque casino ci riserverà il futuro.

Dobbiamo mettere ordine anche nel tuo progetto? Parliamone.