Cloud aziendale self-hosted nel 2026: cosa resta di OwnCloud e come lo costruisco oggi

Quando un'azienda mi chiede di stimare il costo di Google Workspace o Microsoft 365 su un orizzonte di tre anni, il numero che esce non è il canone mensile per utente: è quel canone moltiplicato per il numero di dipendenti, per 36 mesi, senza che alla fine resti in mano nulla di proprio. Per un team di venti persone parliamo facilmente di cifre a cinque zeri spese in affitto di spazio e funzionalità su infrastruttura altrui. È la stessa osservazione che da sempre rende attraente un'alternativa autogestita come OwnCloud: un server Linux, un software open source, e il controllo dei propri file senza pagare un abbonamento che cresce a ogni gigabyte.

Quel ragionamento sul costo resta valido, ma il software a cui ci si riferiva allora non esiste più nella forma in cui lo conoscevamo. Vale la pena rifare la guida da zero, perché chi cerca "cloud aziendale con OwnCloud" oggi arriva su un panorama profondamente diverso, e seguire istruzioni datate significa installare un prodotto a fine corsa su uno stack obsoleto.

TL;DR

• OwnCloud oggi: il progetto si è biforcato nel 2016; il fork Nextcloud è diventato lo standard del self-hosting, mentre OwnCloud è stato riscritto in Go come oCIS (niente più PHP né database).
• Cosa installare: per la maggior parte delle PMI, Nextcloud (suite completa, comunità ampia, governance europea). oCIS solo se serve throughput puro su volumi enormi.
• Server: un VPS europeo modesto (qualche core, ~8 GB di RAM) per un team piccolo; dimensiona sulla concorrenza reale, non sul totale dei dipendenti.
• Produzione: dietro reverse proxy (Traefik/Nginx) con TLS automatico (Let's Encrypt); il backend non va mai esposto direttamente.
• Perché autogestire nel 2026: non più il prezzo, ma la sovranità del dato.

Cosa è successo a OwnCloud, e perché conta per la tua scelta

OwnCloud nasce nel 2010 come piattaforma open source di file sharing self-hosted. Nel 2016 il suo fondatore, Frank Karlitschek, lascia il progetto e ne crea un fork, Nextcloud, in disaccordo con il modello di licenza open-core. Da quel momento le due strade divergono in modo netto, e capire questa divergenza è la chiave per non scegliere lo strumento sbagliato.

Nextcloud ha puntato sull'ampiezza: da semplice sincronizzazione file è diventato una suite di collaborazione completa, con videoconferenza, groupware, editing documentale collaborativo e, nelle versioni recenti, persino un assistente AI eseguibile in locale. OwnCloud ha puntato sulla profondità di un singolo caso d'uso: la sua nuova architettura, Infinite Scale (oCIS), è stata riscritta da zero in Go per ottenere prestazioni grezze su scala enterprise.

Questa riscrittura è il fatto tecnico più importante del 2026. OwnCloud Infinite Scale non usa più PHP né un database: la documentazione ufficiale è esplicita nel dichiarare che non servono né l'uno né l'altro, e che il prodotto si distribuisce come singolo binario o container, con interfaccia web inclusa. La motivazione dichiarata dal team era prestazionale, riassunta nella frase per cui "PHP ha raggiunto i suoi limiti di performance": Go avrebbe portato costi hardware ridotti e un'architettura svincolata dal database, più facile da scalare anche geograficamente. L'architettura a microservizi, in cui ogni servizio può essere spostato su nodi diversi per scalare in orizzontale, è descritta nella documentazione ufficiale di oCIS.

Il punto pratico è che OwnCloud oggi mantiene due linee di prodotto separate, e confonderle è l'errore più comune:

• OwnCloud Infinite Scale (oCIS): la riscrittura in Go, l'unica in sviluppo attivo. La versione corrente di metà 2026 è la 8.0.3, rilasciata l'11 maggio 2026 con fix di sicurezza.
• OwnCloud Classic (la linea PHP 10.x, quella delle vecchie guide): in sola manutenzione, senza nuove funzionalità previste. Per un nuovo deployment non ha più senso.

A questo si aggiunge un fattore di governance che nel 2026 pesa sulla decisione quanto la tecnologia. OwnCloud è stato acquisito a fine 2024 dalla statunitense Kiteworks, e l'operazione ha sollevato preoccupazioni di sovranità nella sua comunità. Kiteworks ha poi fatto passi verso l'apertura, con l'avvio nel maggio 2026 di un Open Source Program Office, il ritiro del Contributor License Agreement e il piano di rilicenziare oltre cento progetti sotto Apache 2.0. Ma per un'azienda europea che valuta dove mettere i propri documenti, una proprietà extra-UE è un dato da iscrivere a registro, non da ignorare.

Allora cosa installo nel 2026: Nextcloud o oCIS?

La risposta dipende da cosa ti serve davvero, e mi sono convinto nel tempo che la domanda giusta non sia "quale è più potente" ma "quale problema sto risolvendo".

Se vuoi un ufficio digitale sovrano che sostituisca Google Workspace o Microsoft 365, con condivisione file, chat, videocall, editing collaborativo e calendario, la scelta è Nextcloud. È la piattaforma con più funzioni disponibili gratuitamente, interamente sotto licenza AGPL-3.0 senza distinzioni tra edizione gratuita e a pagamento sul piano delle feature: l'abbonamento, che parte intorno ai 68 euro per utente all'anno, compra il supporto enterprise e le patch di sicurezza anticipate, non funzionalità aggiuntive. Nextcloud resta basato su PHP e raccomanda oggi PHP 8.4 dove possibile, con risorse adeguate per ogni processo.

Se invece il tuo problema è spostare grandi volumi di file a velocità elevata per molti utenti concorrenti, e la collaborazione documentale ti interessa poco, oCIS è tecnicamente superiore: il backend in Go gestisce trasferimenti pesanti e concorrenza meglio di uno stack PHP, e il modello a "Spaces" è più pulito per l'organizzazione dei file di team. Il rovescio della medaglia è la maturità dell'ecosistema: Nextcloud ha molta più documentazione, molti più tutorial di comunità e un percorso di migrazione più rodato.

Un caveat che dichiaro sempre, perché è una trappola costosa: la migrazione non è simmetrica. Passare da OwnCloud 10 a Nextcloud è ben documentato e generalmente lineare, vista l'origine comune del codice. Migrare verso o da oCIS è invece complesso, perché si tratta di una riscrittura architetturale incompatibile con una migrazione a livello di database: nella pratica, se vai su oCIS metti in conto di ri-caricare i file, non di trasferirli in place. È una decisione da prendere consapevolmente all'inizio, non da scoprire a metà progetto.

Per la maggior parte delle PMI italiane che mi contattano, la raccomandazione del 2026 è Nextcloud: vince su funzionalità, comunità e prevedibilità del percorso, e la sua governance resta una fondazione europea senza le incognite della proprietà cambiata. Riservo oCIS ai casi in cui il throughput puro su volumi enormi è davvero il vincolo dominante.

Quanto serve di server, e dove lo prendo

La vecchia guida consigliava un provider economico che oggi non esiste più: è il destino dei fornitori a basso costo, e linkare un servizio morto è uno dei modi più rapidi per rendere inutile un articolo. Nel 2026 il punto di riferimento per un VPS europeo a buon rapporto prezzo-prestazioni resta Hetzner, su cui ho gestito infrastrutture per anni.

Per un cloud self-hosted di un piccolo team, un VPS Hetzner della linea CX o CPX con qualche core, 8 GB di RAM e storage adeguato è il punto di partenza ragionevole; lo storage in crescita si gestisce con i Volumi a blocchi o, per i backup, con le StorageBox a costo contenuto. La regola che applico è dimensionare la RAM sul numero di utenti realmente concorrenti, non sul totale dei dipendenti: un team di venti persone non ha mai venti sincronizzazioni attive nello stesso istante.

Il sistema operativo su cui costruisco è Debian, nella versione stabile corrente, per la prevedibilità degli aggiornamenti di sicurezza e il ciclo di vita lungo. Su questa base, lo stack cambia radicalmente a seconda della piattaforma scelta: per Nextcloud serve il classico ambiente con PHP 8.4, web server e database, mentre per oCIS è sufficiente un singolo binario o un container, senza web server applicativo né database da configurare.

Il dimensionamento iniziale è la decisione che pago di più se sbaglio: un server sottodimensionato si traduce in sincronizzazioni lente e utenti frustrati, uno sovradimensionato in costi inutili che si trascinano per anni. Su questo tipo di scelte infrastrutturali, dal sizing alla strategia di crescita dello storage, lavoro da molti anni con le PMI: nel mio profilo professionale trovi il metodo e l'esperienza diretta con cui affronto le infrastrutture self-hosted, senza nostalgia dell'on-premise né fede cieca nel cloud commerciale.

Come metto Nextcloud in produzione senza esporre il backend al mondo

L'errore architetturale che vedo più spesso è esporre direttamente il web server applicativo su Internet. Io metto sempre davanti un reverse proxy che termina il TLS, gestisce i certificati e isola il backend. È lo stesso pattern che descrivo nel dettaglio nell'articolo su Traefik come reverse proxy su VPS Hetzner con HTTPS automatico, e che si adatta perfettamente a un'installazione Nextcloud containerizzata.

Lo schema operativo è questo:

• Reverse proxy in testa. Traefik o Nginx ricevono le richieste su cloud.tuodominio.it, terminano il TLS e inoltrano al backend sulla rete interna. Il backend non è mai raggiungibile direttamente dall'esterno.
• Certificato TLS valido e automatico. Il certificato si ottiene gratuitamente con Let's Encrypt e si rinnova da solo: la procedura con certbot la spiego passo passo in Let's Encrypt e certbot su Nginx, automazione multi-dominio. Il TLS qui non è un dettaglio estetico: senza, le credenziali tra i client di sincronizzazione e il server viaggerebbero in chiaro, e un attaccante anche poco esperto, in posizione di man-in-the-middle, prenderebbe il controllo dell'intero ambiente.
• Backend containerizzato. Eseguire Nextcloud in container rende l'aggiornamento e il rollback operazioni pulite e ripetibili. Le tecniche per costruire immagini PHP minimali e veloci da aggiornare le tratto in ottimizzare le build Docker per PHP con il layer caching.
• Database e cache separati. PostgreSQL o MariaDB per i metadati, Redis per il caching delle sessioni e il file locking: sono i componenti che fanno la differenza tra un cloud che striscia e uno che risponde, soprattutto con molti client che sincronizzano in parallelo.

Quali estensioni e configurazioni PHP non posso saltare?

Per un'installazione Nextcloud sana servono i moduli PHP per la manipolazione di file e immagini, l'accesso al database, la gestione dello ZIP e dell'XML, più una OPcache configurata con generosità e un APCu per la cache locale. La regola pratica che applico: alzare i limiti di upload_max_filesize e post_max_size ai valori reali dei file che il team scambia, dimensionare l'OPcache in base alla quantità di codice e impostare il file locking via Redis. Sono dettagli che sembrano minori ma che determinano se l'utente vede un caricamento istantaneo o un timeout.

E la sicurezza? Quali sono gli errori da non commettere

Un cloud self-hosted contiene i documenti più sensibili dell'azienda: contratti, anagrafiche, fatture. Difenderlo non è opzionale, e ci sono tre errori ricorrenti che chiudo sempre per primi.

Il primo è la password debole sull'amministratore: durante tutta la configurazione vanno usate password lunghe e casuali, generate, non inventate. Il secondo è l'assenza di backup verificati: un cloud aziendale senza una strategia di backup testata è una bomba a orologeria, e il backup deve essere off-site e cifrato, non una copia sullo stesso disco che stai proteggendo. I principi di un backup incrementale affidabile, recuperabile e senza blocchi sul sistema in esercizio li ho descritti per i database in backup incrementale con recovery point senza blocchi, e la stessa logica vale per i dati del cloud. Il terzo è l'aggiornamento trascurato: sia Nextcloud sia oCIS rilasciano patch di sicurezza con regolarità, e la versione oCIS 8.0.3 del maggio 2026 è proprio un rilascio di sicurezza. Un cloud non aggiornato è un cloud che prima o poi viene compromesso.

A questi aggiungo l'autenticazione a più fattori, che entrambe le piattaforme supportano e che per un sistema esposto su Internet considero un requisito minimo, non un di più.

C'è poi un livello di difesa che molti dimenticano perché non riguarda l'applicazione ma il perimetro: la protezione contro gli attacchi a forza bruta sul login. Un endpoint di autenticazione esposto su Internet riceve tentativi automatizzati nel giro di poche ore dalla messa online, ed è una costante, non un'eventualità. La contromisura che applico sempre combina il rate limiting a livello di reverse proxy, per rallentare le richieste ripetute dalla stessa origine, con uno strumento come fail2ban che osserva i log e banna a livello di firewall gli indirizzi che superano una soglia di tentativi falliti. È una difesa a basso costo computazionale che taglia alla radice la stragrande maggioranza del rumore ostile, e che vale la pena configurare prima ancora di aprire il servizio agli utenti reali.

La vera ragione per autogestire un cloud nel 2026

Per anni l'argomento decisivo a favore dell'autogestione è stato il prezzo: lo storage commerciale costava e cresceva, l'autogestione lo abbatteva. Quel vantaggio economico esiste ancora, ma non è più la ragione principale, ed è qui che il panorama del 2026 cambia davvero la prospettiva.

La ragione che metto al primo posto oggi è la sovranità del dato. Affidare i documenti aziendali a una piattaforma di terze parti significa accettarne i termini di servizio, le politiche di retention e la giurisdizione, che possono cambiare unilateralmente. Un cloud self-hosted su infrastruttura europea che controlli direttamente ti restituisce qualcosa che l'affitto non dà: il dato resta tuo, sul tuo server, sotto la tua governance, con la tua chiave di cifratura. Per un'azienda con vincoli di conformità, o semplicemente con la volontà di non dipendere da fornitori che possono cambiare le regole su ciò che è tuo, questo conta più dei pochi euro al mese risparmiati.

È un lavoro che richiede competenze reali di amministrazione Linux e di sicurezza: dimensionamento del server, reverse proxy, TLS, backup, hardening, aggiornamenti. Non è un'installazione "click e via", e chi promette il contrario sta nascondendo il costo della manutenzione. Ma con tempo, pazienza e un'architettura impostata bene fin dall'inizio, è perfettamente alla portata di un'azienda che voglia riprendere il controllo dei propri dati.

Se hai un'esigenza specifica da qualificare, dal dimensionamento del server alla strategia di uscita dalla soluzione commerciale che usi oggi, scrivimi dal modulo di contatto: la prima call serve esattamente a capire se il self-hosting è la risposta giusta per te o se, nel tuo caso, conviene un'altra strada. Perché la consulenza onesta comincia dal dire anche quando non serve, e un cloud aziendale ben fatto deve reggere per anni, non solo superare la prima settimana.