Hosting Docker Compose. Twój compose, nasz serwer.

1. Docker come tipo di applicazione, non come prodotto a parte

Molti provider di hosting trattano Docker come una funzionalità riservata ai piani VPS o cloud più costosi, perché richiede più isolamento e controllo rispetto al classico shared hosting. Su Saplo Docker è invece uno dei tipi di applicazione del catalogo, disponibile come WordPress o un sito statico, senza soglie di prezzo superiori per il solo fatto di eseguire container.

In pratica, 152 applicazioni su 166 nel catalogo Saplo usano Docker in background, quindi il motore di container funziona su ogni Box dotato di Docker, indipendentemente dal fatto che il cliente installi un template pronto dal catalogo o crei una propria immagine custom.

Il tipo di applicazione custom ti permette di usare la tua immagine Docker, specificando il tuo Dockerfile o il tuo docker-compose, senza limitarti alle ricette pronte nel catalogo. Così hai piena libertà nei progetti non standard.

2. Registro privato di immagini incluso nel prezzo

Il catalogo delle applicazioni include anche Docker Registry: un registro privato di immagini (immagine ufficiale registry:2) con una UI semplice per esplorare repository, tag e layer nel browser, protetto da basic auth con nome utente e password generati casualmente durante l'installazione.

Per un team che costruisce le proprie immagini in CI/CD, questo significa poter mantenere immagini private senza un account su Docker Hub e senza i limiti di pull rate che i conti gratuiti dei registri pubblici impongono ai download frequenti di immagini durante i deployment.

L'interfaccia del registro funziona come reverse proxy verso l'API dello stesso registro, sotto un unico dominio e senza CORS. In questo modo, docker login, docker push e docker pull funzionano direttamente tramite il dominio dell'applicazione, senza porte aggiuntive da configurare separatamente.

3. Quanta RAM richiedono le applicazioni Docker

Le tipiche applicazioni Docker nel catalogo Saplo richiedono da 1 a 2 GB di RAM (Baserow, Chatwoot, Flowise, n8n, Windmill e Typebot), perché un'immagine ufficiale contiene di solito più dipendenze rispetto a una leggera installazione PHP o a una semplice applicazione statica.

Box M (2 GB di RAM) consente di ospitare comodamente una tipica applicazione Docker, mentre Box L (6 GB di RAM) offre spazio per eseguire diverse applicazioni Docker in parallelo. Quando si costruisce un insieme più ampio di strumenti (CRM, chat e automazione insieme), Box L rappresenta in pratica il minimo per evitare che le applicazioni competano per la memoria. Con un insieme ancora più ampio di applicazioni Docker, valuta Box XL: i 12 GB di RAM offrono un margine concreto per ampliare il catalogo degli strumenti senza dover controllare spesso quale applicazione occupa la maggior parte della memoria sul Box.

Per le tue immagini Docker personalizzate (tipo custom), il fabbisogno di RAM dipende da ciò che l'immagine fa realmente. Verifica il consumo di memoria in locale prima di scegliere il Box, come per qualsiasi altra distribuzione containerizzata.

4. Docker su Saplo vs Docker su un VPS da zero

Su un VPS pulito devi installare Docker, configurare il firewall per le porte dei container e impostare manualmente un reverse proxy con SSL per ogni servizio avviato. Per chi non conosce l'amministrazione di Linux, questo è un vero ostacolo per iniziare.

Su Saplo il container LXC del Box ha già il supporto per Docker configurato (keyctl, nesting), quindi docker run e docker compose up funzionano subito dopo l'accesso via SSH. Il reverse proxy e l'SSL per le applicazioni accessibili pubblicamente vengono configurati dal pannello quando colleghi il dominio.

A parità di risorse, la differenza di costo tra un VPS da zero e un Box con Docker è di solito contenuta, ma su Saplo il tempo necessario per avviare il primo servizio è decisamente più breve, perché non devi configurare da zero il motore di container.

5. Per chi è adatto

Per uno sviluppatore che vuole distribuire la propria immagine Docker senza dover impostare un VPS da zero, il tipo di applicazione custom su Box M o Box L offre un ambiente pronto con supporto per Docker e SSL automatico per il dominio collegato.

Per un team che costruisce le proprie immagini in CI/CD, il Docker Registry privato del catalogo delle applicazioni elimina la necessità di un account su un registro pubblico e dei relativi limiti di pull rate.

Per chi prova contemporaneamente più applicazioni Docker del catalogo (ad esempio CRM, chat e automazione), Box L con 6 GB di RAM offre spazio sufficiente per eseguirne diverse in parallelo senza che competano per la memoria.

6. Primo deployment della tua immagine Docker su Saplo

Dopo aver scelto il tipo di applicazione custom, collegati via SSH (disponibile a partire da Box M) e prepara un docker-compose.yml o un Dockerfile per il tuo progetto, come in qualsiasi altro ambiente con Docker installato.

Configura il reverse proxy e l'SSL per il servizio accessibile pubblicamente dal pannello Saplo dopo aver collegato il dominio, indicando la porta su cui il container è in ascolto. Non devi configurare manualmente nginx né il certificato lato client.

Configura i volumi di dati in modo che i dati dell'applicazione sopravvivano al riavvio del container e siano inclusi nel backup del Box, se il piano che usi include il backup.

Per le applicazioni multi-container (ad esempio database + applicazione + worker in un unico docker-compose), verifica che la somma della RAM di tutti i container rientri nel limite del Box scelto prima di avviare l'intero stack.

Il Docker Registry privato del catalogo delle applicazioni ti permette di archiviare le immagini che hai costruito e poi di scaricarle sul Box con docker pull usando lo stesso dominio, senza un account su un registro pubblico.

7. CI/CD e build automatica delle immagini Docker

Il flusso CI/CD tipico prevede di costruire l'immagine in un sistema esterno (GitHub Actions, GitLab CI), caricarla tramite push sul Docker Registry privato su Saplo, quindi eseguire docker pull e riavviare il container sul Box di produzione.

L'automatizzazione dell'ultimo passaggio (pull e riavvio dopo una nuova immagine) può essere realizzata con un semplice script eseguito via SSH oppure con un webhook che avvia un workflow in n8n ospitato sullo stesso Box.

Un registro privato di immagini elimina i limiti alle operazioni di pull imposti dagli account gratuiti sui registri pubblici, un problema concreto per chi distribuisce più volte al giorno con un account esterno senza piano a pagamento.

Per i team che lavorano in più ambienti (staging, produzione), puoi mantenere tag separati nello stesso registro privato. Così è più semplice controllare quale versione dell'applicazione è in uso in ciascun ambiente.

8. Buone pratiche per le immagini Docker personalizzate in produzione

Fissare una versione specifica dell'immagine base (ad esempio node:20.11-alpine, non node:latest) evita che un aggiornamento dell'immagine base da parte del produttore modifichi inaspettatamente il comportamento della tua applicazione dopo un nuovo rebuild del container, spesso senza alcuna notifica chiara della modifica.

La build multi-stage consente di mantenere piccola l'immagine finale di produzione, senza strumenti di build e dipendenze per lo sviluppo. Ciò velocizza il trasferimento dell'immagine verso il registro e dal registro al server di produzione, riducendo anche la superficie d'attacco del container.

Le variabili d'ambiente e i segreti (password, chiavi API) non devono mai essere inseriti direttamente nell'immagine Docker come valori nel Dockerfile, ma devono essere passati al momento dell'avvio del container. Un'immagine costruita con un segreto al suo interno potrebbe infatti finire in un registro ed essere ricostruita da chiunque abbia accesso al registro.

Un healthcheck configurato nell'immagine o in docker-compose permette di rilevare automaticamente che il container è in esecuzione, ma l'applicazione al suo interno ha smesso di rispondere, ad esempio perché un processo è bloccato. Senza healthcheck, la condizione potrebbe passare inosservata, perché il container sarebbe ancora ufficialmente attivo.

Conviene indirizzare i log del container allo standard output (stdout/stderr), non a file interni al container. I log scritti nei file scompaiono con l'eliminazione del container, mentre quelli dello standard output si raccolgono e consultano più facilmente con gli strumenti standard di Docker.

Controllare regolarmente quali immagini e tag del registro privato sono ancora in uso aiuta a mantenere l'ordine e a liberare spazio disco occupato da vecchie versioni ormai inutili, accumulate dopo deploy ripetuti tramite CI/CD.

9. Ecosistema Docker Hub e immagini della community come punto di partenza

Vastissima gamma di immagini Docker ufficiali, già pronte e disponibili pubblicamente (database, server applicativi, strumenti di utilità). Puoi così ospitare la maggior parte dei servizi più comuni su Saplo senza scrivere un Dockerfile da zero, partendo da immagini già collaudate e mantenute attivamente.

Il catalogo delle applicazioni Saplo contiene configurazioni pronte basate su molte di queste immagini ufficiali (ad esempio prestashop/prestashop, n8nio/n8n, flowiseai/flowise). Non devi quindi nemmeno sapere che l'applicazione gira in Docker, perché tutta la configurazione è già pronta.

Per esigenze su misura (tipo di applicazione custom), l'accesso all'intero ecosistema di Docker Hub e ad altri registri pubblici di immagini ti permette di partire da immagini pronte e di adattarle alle tue esigenze tramite un Dockerfile personalizzato basato su un'immagine di base.

Il Docker Registry privato nel catalogo delle app di Saplo completa l'ecosistema offrendo uno spazio in cui conservare le immagini buildate, senza doverle pubblicare su Docker Hub. Per i progetti commerciali e ad accesso ristretto può essere un requisito di sicurezza fondamentale.

Per i team tecnici che seguono l'evoluzione dell'ecosistema dei container (nuovi strumenti di orchestrazione, nuove pratiche per la build delle immagini), l'accesso SSH completo al container LXC con supporto Docker su Saplo non impone limiti rispetto a quanto è possibile fare su un server classico con Docker gestito autonomamente.

10. Test delle immagini Docker prima del rilascio in produzione

È consigliabile testare una nuova immagine Docker localmente o in un container temporaneo sullo stesso Box prima di sostituire quello di produzione, perché un errore nella nuova immagine, ad esempio una versione incompatibile delle dipendenze, può rendere il servizio indisponibile fino al rollback.

Assegnare alle immagini nel registro privato un tag con la versione, anziché solo latest, permette di tornare rapidamente alla versione precedente funzionante se la nuova si rivela problematica dopo il rilascio nel container di produzione.

Per le app multi-container (docker-compose con database, app e worker), è consigliabile testare la modifica completa, non solo il singolo container, perché le incompatibilità di versione tra container collegati sono una causa comune di problemi invisibili quando si testa un singolo elemento isolato.

Un healthcheck configurato nell'immagine aiuta a rilevare automaticamente che il nuovo container non funziona correttamente dopo il rilascio. Insieme a un semplice script di rollback al tag precedente dell'immagine, permette di annullare rapidamente una modifica problematica senza un lungo downtime del servizio. Questo meccanismo semplice di test e rollback, pur non essendo un sistema CI/CD completo, riduce già in modo significativo il rischio di un'interruzione prolungata causata da un singolo rilascio di una nuova immagine male testata.

11. Riepilogo: Docker è uno standard, non una funzione premium

Considerare Docker come un elemento standard dell'infrastruttura, disponibile su ogni Box e non come una funzione riservata ai piani più alti e costosi riflette quanto questo metodo di packaging delle applicazioni sia ormai diffuso. Che tu scelga una configurazione pronta dal catalogo o distribuisca una tua immagine personalizzata tramite il tipo di app custom, il motore dei container è già configurato e pronto all'uso dal primo giorno sul tuo Box. Per i team tecnici abituati a lavorare con Docker sulle proprie macchine di sviluppo, il passaggio a Saplo non richiede quindi di cambiare le abitudini, ma solo di trasferire lo stesso metodo di lavoro conosciuto in un ambiente di produzione con gestione del dominio e certificato SSL già inclusi.