Hosting Django i Python, bez stawiania serwera.

1. Django è il framework per chi vuole avere il controllo del server

Django, nato come framework pensato per offrire il controllo completo su livello dati, autorizzazione e struttura del progetto, attira naturalmente gli sviluppatori che desiderano avere lo stesso controllo sull'ambiente in cui gira l'applicazione, non solo sul codice Python.

Su Saplo, un'applicazione Django 5.x si installa scegliendo la versione di Python (3.11 o 3.12, con 3.12 predefinita), con configurazione automatica dell'host virtuale nginx e di gunicorn come server WSGI, senza dover scrivere manualmente da zero i file di configurazione di systemd o nginx.

Il manifest dichiara un minimo di 256 MB di RAM, una soglia d'ingresso piuttosto bassa. Le applicazioni Django reali con ORM, sessioni e middleware, però, raramente funzionano bene con meno di 2 GB di RAM, soprattutto con più utenti contemporanei. Per qualcosa di più di un prototipo, Box M è il minimo pratico.

2. SSH, migrazioni e gestione dell'applicazione dal terminale

Da Box M, l'accesso SSH completo con sudo permette di eseguire direttamente dal terminale le operazioni standard di Django: manage.py migrate, collectstatic, createsuperuser, senza dover passare da un pannello di hosting separato che non conosce i comandi Django.

Il deploy tramite Git aggiorna il codice dell'applicazione a ogni push sul branch impostato, ma le migrazioni del database e gli altri passaggi di rilascio (riavvio del processo gunicorn, raccolta dei file statici) richiedono ancora un comando manuale via SSH, un passaggio standard e noto per chi sviluppa con Django.

È possibile eseguire Celery per attività in background (promemorie, invio di email, elaborazione in coda) come processo separato nello stesso container, con un'adeguata configurazione systemd. Nelle applicazioni Django con attività asincrone, è spesso un elemento standard dell'architettura. In tal caso, monitora separatamente il consumo di memoria del processo web e del worker Celery: entrambi competono per lo stesso limite di RAM condiviso, assegnato all'intero container dell'applicazione sul Box, soprattutto quando aumentano le attività Celery eseguite in parallelo in background.

3. Database per Django

Django usa per impostazione predefinita un database relazionale. Su Saplo, Postgres e MySQL sono disponibili come moduli di database separati, che puoi avviare come container nel tuo Docker Compose, non come componenti a pagamento valutati separatamente dall'hosting dell'applicazione.

Per i progetti che richiedono Redis, ad esempio come broker Celery o cache delle sessioni, è disponibile un modulo Redis separato, che puoi eseguire sullo stesso Box dell'applicazione Django senza dover ricorrere a un servizio Redis esterno all'infrastruttura Saplo.

4. Django vs PaaS pronti per Python

Le piattaforme PaaS specializzate in Python fatturano spesso per istanza o in base al consumo orario di risorse, con prezzi in dollari, il che, in presenza di traffico reale in produzione in Polonia, complica la pianificazione del budget in złoty e espone a variazioni del tasso di cambio nella fattura.

Su Saplo il prezzo è fisso, annuale, in złoty e indipendente dal numero di richieste al secondo che l'applicazione gestisce in un dato momento. Per un progetto con traffico irregolare (ad es. un'applicazione interna aziendale usata solo durante l'orario di lavoro), è più semplice da stimare rispetto a un fatturaggio orario delle risorse.

5. Per chi è adatto

Per uno sviluppatore che costruisce un'applicazione web o un sistema interno aziendale con Django, Box M con accesso SSH completo offre un ambiente di produzione pronto per migrazioni e configurazione, senza dover preparare un server da zero.

Per un team che sviluppa un'applicazione di grandi dimensioni con Celery, Redis e un database separato, Box L offre RAM sufficiente per far funzionare in parallelo più processi, sia nello stesso container sia in moduli di database separati affiancati.

Per un'agenzia che sviluppa sistemi B2B in Django per i clienti, un singolo Box può ospitare contemporaneamente più installazioni Django indipendenti, ognuna in un container separato e con un database dedicato.

6. Primo deploy dell'applicazione Django su Saplo

Dopo il deploy dell'applicazione Django con la versione di Python scelta, collega il repository Git per aggiornare automaticamente il codice a ogni push. Poi, via SSH, esegui manage.py migrate e createsuperuser per completare la configurazione e accedere al pannello admin di Django.

Le variabili d'ambiente (SECRET_KEY, stringa di connessione al database, chiavi di API esterne) le imposti nel pannello dell'applicazione oppure nel file.env del container, in linea con la pratica standard di configurazione di Django fuori dal repository del codice.

Se l'applicazione usa Celery per attività in background, configura un processo systemd aggiuntivo nel container (worker e, se necessario, beat per le pianificazioni), che usa come broker Redis, configurato come modulo separato sullo stesso Box.

I file statici (collectstatic) vanno configurati nell'host virtuale nginx del Box, per non appesantire il processo gunicorn con la gestione di file che il server web può servire più rapidamente e con un minore consumo di RAM.

Dopo il primo rilascio, monitora via SSH i log di gunicorn e Django per individuare errori di configurazione (ad esempio un DEBUG=True dimenticato in produzione) prima che l'app riceva traffico reale.

7. Django REST Framework e app API su Saplo

Le app Django realizzate come API (Django REST Framework) funzionano sullo stesso Box esattamente come le app classiche con template, perché la differenza risiede nel codice Django, non nel modo in cui Saplo ospita l'app.

Per le API che usano l'autenticazione tramite token, è consigliabile conservare i segreti (chiavi JWT, chiavi API di servizi esterni) nelle variabili d'ambiente del container, non nel repository del codice, secondo le buone pratiche di sicurezza.

CORS e gli altri header di sicurezza si configurano a livello dell'app Django (middleware), mentre il reverse proxy di Saplo li inoltra senza modificarli, così la configurazione standard di Django funziona senza passaggi aggiuntivi.

Quando un'API gestisce un frontend ospitato su un altro dominio (ad es. un'applicazione Next.js su un Box separato o su un hosting esterno), è importante prestare attenzione alla configurazione di ALLOWED_HOSTS e CORS_ALLOWED_ORIGINS nelle impostazioni di Django.

8. Sicurezza della configurazione di Django in produzione

L'errore più comune nel distribuire Django in produzione è lasciare attivo DEBUG=True: in caso di errore, l'app mostra all'utente l'intero stack trace insieme alle variabili d'ambiente e a frammenti di codice, causando una grave fuga di informazioni sulla struttura interna dell'app.

Il SECRET_KEY usato da Django per firmare sessioni e token dovrebbe essere unico per ogni deployment. Non deve finire nel repository del codice, ma essere impostato come variabile d'ambiente nella configurazione dell'applicazione su Saplo, separatamente dal codice sorgente.

ALLOWED_HOSTS deve contenere esattamente i domini in cui l'app è disponibile, non un asterisco che ammette tutti gli host: è la protezione di base contro gli attacchi di Host header injection, particolarmente importante per le app che ricevono dati da utenti su internet.

Conviene separare logicamente i file statici dai media caricati dagli utenti (uploads), gestendo i file statici dell'applicazione tramite nginx e i file caricati dagli utenti tramite un meccanismo separato con autorizzazioni adeguate, per evitare che un utente possa caricare ed eseguire uno script dannoso sul server.

Gli aggiornamenti di Django e dei pacchetti Python utilizzati (requirements.txt) dovrebbero essere una pratica regolare: come nell'ecosistema Node.js, le dipendenze obsolete sono un vettore d'attacco frequente per vulnerabilità note e già corrette, sfruttate dagli scanner automatici di vulnerabilità.

Per le applicazioni che conservano dati personali degli utenti è importante configurare consapevolmente le impostazioni di sessione (tempo di scadenza, flag Secure e HttpOnly dei cookie). Django le supporta nativamente, ma richiede una configurazione esplicita nelle impostazioni del progetto: i soli valori predefiniti non bastano in ogni scenario. Vale la pena esaminare questa configurazione insieme all'elenco completo delle impostazioni di sicurezza di Django prima del primo deployment in produzione, anziché scoprire un'impostazione mancante solo dopo un vero incidente di sicurezza.

9. Ecosistema Python e pacchetti di supporto per le app Django

Python e Django offrono un ricco ecosistema di pacchetti (PyPI) che supportano le esigenze tipiche delle app web: autenticazione, integrazioni con API esterne, generazione di report PDF e gestione dei pagamenti. Puoi così costruire le funzionalità dell'app con soluzioni pronte e collaudate, invece di scrivere tutto da zero.

Su Saplo, l'accesso SSH completo con sudo (da Box M) consente di installare qualsiasi pacchetto Python tramite il normale gestore pip, senza i limiti imposti dalla piattaforma di hosting. Questo approccio si distingue da quello di alcuni ambienti PaaS chiusi, che supportano solo un elenco limitato di librerie.

La scelta tra le popolari estensioni di Django (Django REST Framework per le API, Django Channels per i WebSocket, Django CMS per la gestione dei contenuti) spetta interamente allo sviluppatore che costruisce l'app: l'hosting non impone limiti architetturali a priori.

L'aggiornamento della versione di Python (da 3.11 a 3.12) è disponibile come opzione di configurazione dell'app e consente di sfruttare le nuove funzionalità del linguaggio e i miglioramenti delle prestazioni senza dover migrare a un altro provider solo per cambiare la versione dell'ambiente di esecuzione.

Per i team che costruiscono applicazioni Django più complesse (con Celery, Redis e numerose integrazioni esterne), il pieno controllo dell'ambiente via SSH, insieme ai moduli base già pronti di Saplo, offre una flessibilità simile a quella di un VPS classico, ma con tempi di deployment più brevi per l'ambiente base.

10. Testare le migrazioni del database prima del rilascio in produzione

Le migrazioni Django che modificano la struttura del database (ad esempio aggiungendo una colonna o cambiando il tipo di un campo) vanno testate prima su una copia del database, non direttamente su quello di produzione: un errore nella migrazione può causare perdita di dati o rendere l'app indisponibile durante l'esecuzione.

Il backup di Box (disponibile da Box L) prima di una migrazione importante è un'ulteriore protezione che permette di tornare allo stato precedente alla migrazione se qualcosa va storto. È comunque buona pratica eseguire anche una copia manuale separata del database poco prima dell'operazione di migrazione.

Le migrazioni irreversibili (ad esempio la rimozione di una colonna con dati) richiedono particolare cautela, perché in caso di errore i dati rimossi possono essere recuperati solo dal backup creato prima della migrazione, non annullando la migrazione in Django.

Per i team che lavorano sullo stesso database, definite una procedura chiara per l'esecuzione delle migrazioni in produzione (chi, quando e dopo quali test), così da evitare che due persone tentino contemporaneamente migrazioni in conflitto sullo stesso database.

L'accesso SSH completo con sudo su Saplo (da Box M) fornisce tutti gli strumenti necessari per eseguire migrazioni in sicurezza, ma la disciplina del processo (test, backup, poi migrazione in produzione) resta interamente responsabilità del team di sviluppo.

11. Riepilogo: Django su Saplo per sviluppatori che vogliono avere il controllo

L'accesso SSH completo con sudo, la scelta della versione di Python e la configurazione già pronta di gunicorn e nginx offrono allo sviluppatore Django esattamente la combinazione di controllo e comodità che cerca quando distribuisce un'app in produzione: i comandi standard di manage.py funzionano come devono e l'intero livello server è già pronto, invece di doverlo costruire da zero per ogni nuovo progetto Django. Per i team che gestiscono più progetti Django contemporaneamente, la ripetibilità della configurazione fa sì che il progetto successivo parta rapidamente quanto il primo, senza ripetere gli stessi passaggi di configurazione del server ormai noti. In pratica, si riduce anche il rischio di piccole differenze di configurazione, difficili da individuare, tra i vari progetti, che nei server allestiti autonomamente sono spesso all'origine di errori di produzione non evidenti.