«Possiamo eseguirla sui nostri server?» è una delle prime domande che pongono gli acquirenti IoT seri — e una di quelle a cui si risponde con meno onestà. Il self-hosting di una piattaforma IoT è davvero la scelta giusta per alcuni deployment e una deviazione costosa per altri. Ecco come capire in quale dei due casi ti trovi.

Cosa significa davvero self-hosted

Una piattaforma IoT self-hosted gira su un'infrastruttura che controlli tu: i tuoi server, il tuo cloud privato o un segmento di rete isolato. I dati dei dispositivi non lasciano mai il tuo perimetro, l'autenticazione si integra con i tuoi sistemi di identità e la disponibilità della piattaforma è responsabilità del tuo team — sia nel senso gratificante del termine, sia in quello della chiamata alle 3 di notte.

Quest'ultima parte è il nucleo onesto di questo articolo: il self-hosting non è una funzionalità che attivi, è una funzione operativa che ti assumi.

Le buone ragioni per il self-hosting

Sovranità dei dati e conformità. I settori regolamentati, la pubblica amministrazione e le infrastrutture critiche hanno spesso requisiti stringenti per cui la telemetria deve restare on-premise o nel Paese. Se i tuoi auditor dicono che i dati non possono uscire, la discussione è chiusa: ti serve un deployment on-premise.

Siti isolati (air-gapped) e a bassa connettività. Una fabbrica, una nave o un impianto remoto con un collegamento inaffidabile può aver bisogno della piattaforma accanto alle macchine, non dall'altra parte dell'oceano.

Latenza e località. Quando le decisioni di automazione devono scattare in millisecondi su apparecchiature locali, una piattaforma locale elimina il viaggio di andata e ritorno.

Controllo a lungo termine. Alcuni team vogliono semplicemente la garanzia che nessun cambio di prezzi o dismissione di prodotto da parte del vendor possa lasciare a terra il loro deployment.

I costi che nessuno mette in landing page

Le piattaforme open source che ospiti in autonomia — la Community Edition Apache 2.0 di ThingsBoard è l'esempio più noto — sono gratuite nella licenza, non nell'esercizio. Qualcuno deve dimensionare e scalare il database, applicare le patch di sicurezza, testare gli aggiornamenti, monitorare il monitoraggio stesso e restare reperibile. Funzionalità che davi per incluse possono trovarsi nelle edizioni a pagamento; con ThingsBoard, ad esempio, la connettività LoRaWAN arriva tramite integrazioni con network server esterni riservate ai piani a pagamento. Il nostro confronto Kilo vs ThingsBoard espone questo compromesso con onestà, comprese le aree in cui ThingsBoard vince davvero.

Una regola pratica utile: se non sai nominare l'ingegnere che tra diciotto mesi sarà responsabile degli aggiornamenti della piattaforma, non stai scegliendo il self-hosting — stai scegliendo debito tecnico.

La via di mezzo: una piattaforma gestita, installata on-premise

La scelta non è solo «SaaS pubblico» o «open source puro». La piattaforma IoT di Kilo funziona come SaaS cloud e come deployment on-premise: la stessa piattaforma — network server LoRaWAN e mioty integrati, dashboard con gemello digitale 3D dell'edificio, regole con ciclo build-test-deploy-rollback, catene di escalation degli allarmi e l'assistente AI — installata dentro il tuo perimetro, con il vendor ancora responsabile del software in sé.

Questo divide la differenza esattamente dove la maggior parte dei team vuole dividerla: la tua infrastruttura e i tuoi dati, ma non il compito di sviluppare e mantenere la piattaforma.

Una breve checklist prima di decidere

Poniti cinque domande. Una normativa richiede davvero l'on-premise, o sembra solo più sicuro? Chi gestisce la piattaforma al secondo anno? L'edizione self-hosted include la connettività che ti serve (network server LoRaWAN, MQTT) o sono componenti aggiuntivi? Quanto costa tornare indietro se sbagli? E puoi testare prima entrambi i modelli a basso costo?

L'ultima domanda ha una risposta facile: il piano cloud di Kilo è gratuito per 5 dispositivi, quindi puoi dimostrare il valore applicativo nel cloud e passare poi all'on-premise con il modello di deployment già validato — invece di fare il debugging dell'infrastruttura e del caso d'uso allo stesso tempo.