Cloud in a Bottle vuole trasformare un server nel tuo cloud personale

La promessa del self-hosting è da sempre una, pesante come un macigno: consentire l’utilizzo di servizi online senza consegnare dati, applicazioni e controllo operativo a un fornitore esterno. Nella pratica, però, quasi sempre sono richieste competenze da amministratore di sistema o comunque un certo bagaglio esperienziale. Server da mantenere, reverse proxy, certificati TLS, container, DNS, backup, aggiornamenti, credenziali separate. Cloud in a Bottle ambisce invece a trasformare un server personale in qualcosa che assomigli più a uno smartphone sul quale installare applicazioni che a una macchina Linux da amministrare quotidianamente.

Il progetto è stato presentato pubblicamente il 5 settembre 2026 da Zack Polizzi, dopo oltre 6 mesi di sviluppo e test privati, ed è sostenuto dalla società Imbue. Il codice è open source con licenza AGPL-3.0 (repository GitHub ufficiale), può girare su hardware proprio, macchina virtuale o VPS e non integra telemetria.

Già nel 2014 Sandstorm sosteneva che il vero ostacolo per la diffusione delle applicazioni Web open source non fosse la disponibilità del codice, ma l’assenza di un sistema semplice con cui ogni utente potesse disporre di una propria istanza, installando software senza doversi occupare personalmente dell’intera infrastruttura.

Cloud in a Bottle: che cos’è e come funziona

L’approccio SaaS (Software-as-a-Service) ha reso Google Docs, Microsoft 365, Dropbox, Slack e centinaia di altri servizi immediatamente accessibili da qualunque dispositivo, eliminando quasi del tutto l’installazione locale. Il prezzo di quella comodità è però la centralizzazione: applicazione, dati, autenticazione e infrastruttura dipendono dallo stesso soggetto. Cloud in a Bottle tenta una strada diversa, cercando di mantenere la comodità del cloud senza rinunciare alla possibilità di possedere realmente il server su cui gira il software.

La piattaforma poggia, innanzi tutto, su di una macchina Ubuntu e costruisce sopra di essa uno strato che gestisce applicazioni, autenticazione, routing, dati e comunicazione tra servizi.

Le applicazioni non vengono eseguite direttamente sul sistema operativo host, ma all’interno di container Podman rootless: ambienti isolati che funzionano senza assegnare privilegi amministrativi reali ai processi dell’app. “Davanti” ai container opera un router centrale che riceve le richieste Web dirette al server e le inoltra all’applicazione corretta in base al dominio o al percorso richiesto.

Lo stesso componente verifica se l’utente è autorizzato ad accedere, instrada anche le connessioni WebSocket e coordina operazioni come avvio, arresto, installazione e aggiornamento delle applicazioni. Le singole app restano separate tra loro, mentre Cloud in a Bottle concentra in un unico punto le funzioni comuni necessarie per pubblicarle e amministrarle.

Un solo accesso per tutte le applicazioni

Uno degli aspetti più interessanti riguarda l’autenticazione unificata.

Per impostazione predefinita, il router protegge le applicazioni e consente l’accesso alle relative “rotte” soltanto dopo il login del proprietario dell’istanza. L’utente entra una volta nel proprio Cloud in a Bottle e può quindi aprire le applicazioni senza creare un nuovo account per ciascun servizio.

Le app che devono esporre endpoint pubblici possono dichiararli esplicitamente nel proprio manifest.

Cloud in a Bottle può decidere quali indirizzi di un’app richiedano l’autenticazione e quali, invece, debbano restare raggiungibili dall’esterno senza login. È il caso, per esempio, di un webhook, cioè un URL che deve poter ricevere automaticamente dati o notifiche da un altro servizio. Le pagine riservate all’utente passano quindi attraverso il controllo di accesso, mentre gli endpoint dichiarati pubblici restano disponibili senza autenticazione.

Ogni applicazione non deve costruire da zero un proprio sistema di login, gestione della sessione e verifica dell’identità: può affidare gran parte di queste funzioni al router centrale della piattaforma.

Va detto però che Cloud in a Bottle non pretende di rendere magicamente sicuro qualunque software installato: le applicazioni possono richiedere privilegi aggiuntivi e il proprietario deve valutare se concederli. Gli stessi sviluppatori chiariscono che il catalogo curato riduce il rischio, ma non rappresenta una garanzia assoluta: un’app inclusa nel catalogo può cambiare in tempi successivi e non vi è certezza che ogni modifica sia sottoposta a una nuova revisione completa.

Il punto forte è l’isolamento dei container

Il modello di sicurezza parte dall’esecuzione di ogni applicazione come container rootless sotto un utente host non privilegiato. Il root interno al container non coincide quindi con il vero root della macchina: viene mappato su un subuid non privilegiato dell’host. Cloud in a Bottle utilizza inoltre idmapped mounts per mantenere corretta la proprietà dei file senza concedere al container privilegi amministrativi reali.

Ogni applicazione vede soltanto le proprie directory dati, salvo autorizzazioni esplicite. Non può accedere direttamente al database del router, alle chiavi TLS o ai dati delle altre applicazioni.

C’è poi una scelta di rete interessante: la porta HTTP principale del container risulta pubblicata soltanto sull’interfaccia di loopback 127.0.0.1 dell’host. Il servizio non risulta quindi direttamente esposto su Internet: le richieste passano attraverso il router, che può applicare autenticazione e policy prima di inoltrarle all’applicazione corretta.

Un software compromesso può comunque esporre dati che gli appartengono o sfruttare eventuali permessi aggiuntivi concessi dall’utente. Il vantaggio sta nella riduzione della superficie laterale: compromettere un singolo servizio non dovrebbe equivalere automaticamente ad avere accesso all’intera macchina.

Le applicazioni comunicano tra loro, ma con permessi espliciti

Cloud in a Bottle introduce anche un meccanismo di Cross-App Services che ricorda, per certi aspetti, il modello delle API di Android e iOS.

Un’applicazione può offrire un servizio e un’altra può dichiarare nel proprio manifest di volerlo utilizzare. Le due app non comunicano direttamente: la richiesta passa dal router, che identifica il chiamante, individua il provider corretto e inoltra soltanto i permessi concessi dal proprietario.

I servizi hanno un identificatore e ogni app può dichiarare di richiedere, ad esempio, una determinata versione minima di un servizio. Se nessun provider compatibile risulta disponibile, il router restituisce un errore 503 anziché inoltrare la richiesta a un componente incompatibile.

Ogni applicazione riceve inoltre un token specifico, BOTTLE_APP_TOKEN, utilizzato per autenticare le chiamate server-side verso il router. Non si tratta della credenziale del proprietario: identifica l’app chiamante e non permette di entrare nel pannello amministrativo.

Il sistema dei grant consente di restringere ulteriormente l’accesso: un’app potrebbe chiedere di leggere soltanto una determinata cartella, una casella di posta specifica oppure un singolo segreto. L’approvazione può avvenire durante l’installazione o mediante un’interfaccia predisposta dall’app che fornisce i dati. L’integrazione tra software diversi non richiede necessariamente la condivisione indiscriminata delle rispettive directory o delle credenziali.

Come si prepara un’app per Cloud in a Bottle

Gli sviluppatori non devono riscrivere il software da zero. Qualunque applicazione capace di girare in un container OCI e di esporre un servizio HTTP o HTTPS può diventare candidata alla distribuzione. Se esiste già un Dockerfile, l’adattamento può essere relativamente limitato.

Alla radice del repository va aggiunto un file cloudinabottle.toml; il manifest descrive nome e versione dell’applicazione, immagine o Dockerfile da utilizzare, porta interna, risorse, directory persistenti, eventuali rotte pubbliche e servizi forniti o consumati. È possibile indicare anche limiti di memoria e CPU.

Durante l’esecuzione, l’app dovrebbe ascoltare su 0.0.0.0 e sulla porta dichiarata nel manifest.

Da Nextcloud a Jellyfin: il catalogo è già piuttosto vario

Al momento del lancio il catalogo comprende già software molto vario.

Ci sono Nextcloud, per file, calendari, contatti e collaborazione; Jellyfin, per organizzare e riprodurre film, serie TV e musica in streaming; Forgejo, piattaforma per ospitare repository Git e gestire lo sviluppo del software; Jitsi Meet, dedicato alle videoconferenze; e Matrix Synapse, server per la messaggistica decentralizzata basata sul protocollo Matrix, utilizzabile insieme al client Cinny.

Il catalogo include inoltre Miniflux, lettore RSS essenziale e self-hosted; Navidrome, server musicale compatibile con numerosi client Subsonic; Overleaf Community Edition, ambiente collaborativo per scrivere e compilare documenti LaTeX; Pi-hole, che filtra a livello DNS domini pubblicitari e di tracciamento; SearXNG, metamotore di ricerca orientato alla privacy; Uptime Kuma, utile per controllare disponibilità e tempi di risposta di siti e servizi; Vaultwarden, implementazione leggera e compatibile con i client Bitwarden per la gestione delle password.

Non mancano strumenti più specialistici: GraphHopper calcola percorsi e itinerari a partire da dati cartografici OpenStreetMap; Lichess è la piattaforma open source per giocare e gestire partite di scacchi online; LimeSurvey consente di creare questionari e sondaggi; Open WebUI, infine, fornisce un’interfaccia Web per interagire con modelli linguistici e server di inferenza eseguiti localmente o su infrastrutture controllate dall’utente.

Installazione: semplice sì, ma non ancora per tutti

Per installare Cloud in a Bottle su una macchina VPS pubblica serve attualmente una macchina con Ubuntu 24.04, un filesystem compatibile con idmapped mounts come ext4, XFS o Btrfs, accesso SSH con privilegi sudo e un indirizzo IPv4 pubblico statico.

Servono inoltre un dominio controllato dall’utente e le porte TCP 80 e 443 raggiungibili via Internet.

La porta 53 deve risultare disponibile sia TCP sia UDP perché la piattaforma utilizza il proprio server DNS autoritativo. Il dominio utilizzato per Cloud in a Bottle deve affidare la propria gestione DNS al server su cui gira la piattaforma.

Da quel momento CoreDNS risponde alle query per il dominio e per i suoi sottodomini, così applicazioni diverse possono essere raggiunte con indirizzi come notes.example.com, jellyfin.example.com o git.example.com senza creare manualmente un record DNS per ciascuna di esse. La piattaforma usa inoltre una configurazione wildcard, cioè valida per qualunque sottodominio dello stesso dominio.

Lo stesso meccanismo serve per ottenere un certificato TLS wildcard, necessario per offrire HTTPS su tutti questi indirizzi. Cloud in a Bottle utilizza la verifica ACME DNS-01: l’autorità di certificazione controlla uno speciale record DNS temporaneo per verificare che il server abbia effettivamente il controllo del dominio. Superata la verifica, può rilasciare un certificato valido, ad esempio, per *.example.com, evitando di richiederne uno separato per ogni applicazione.

Siamo ancora lontani dal classico “scarica, fai doppio clic e dimenticatene“. Chi conosce DNS, record NS, firewall e SSH non avrà grosse difficoltà a configurare, installare e usare Cloud in a Bottle; per un utente non tecnico, invece, qualche concetto potrebbe risultare ancora complesso da masticare.

Il ritorno del personal cloud, ma con idee più moderne

L’intuizione alla base di Cloud in a Bottle è convincente perché affronta un problema che Docker, Kubernetes e i vari pannelli di deployment non hanno realmente eliminato. Avviare un container è diventato facile; costruire un ambiente personale composto da dieci applicazioni significa ancora gestire dieci sistemi di login, integrazioni differenti, autorizzazioni, backup e meccanismi di aggiornamento.

Cloud in a Bottle riprende l’idea di un server personale nel quale installare applicazioni con la semplicità di un app store usando strumenti ormai maturi: container OCI, Podman rootless, ACME, reverse proxy moderni, storage S3 e un modello esplicito per lo scambio di servizi tra applicazioni.

Non mancano i punti da verificare sul lungo periodo: la sicurezza dipenderà molto dalla qualità del catalogo, dal processo di aggiornamento delle app e dalla prudenza con cui gli utenti concederanno permessi elevati.

Anche backup, recovery e manutenzione del server rimangono responsabilità concrete quando si sceglie la modalità completamente self-hosted.

Cloud in a Bottle ha comunque il merito di cementare uno strato comune capace di far percepire applicazioni e strumenti di deployment come parte integrante dello stesso sistema.