Hosting Django i Python, bez stawiania serwera.

1. Django est un framework pour les personnes qui veulent garder le contrôle sur leur serveur.

Django, conçu dès l'origine pour offrir un contrôle total sur la couche de données, l'autorisation et la structure du projet, attire naturellement les développeurs qui souhaitent garder un contrôle équivalent sur l'environnement dans lequel leur application s'exécute, et pas seulement sur le code Python.

Sur Saplo, pour déployer une application Django 5.x, tu choisis la version de Python (3.11 ou 3.12, 3.12 par défaut). La configuration du virtual host nginx et de gunicorn comme serveur WSGI est automatique, sans que tu doives écrire manuellement un fichier de configuration systemd ou nginx à partir de zéro.

Le manifeste indique un minimum de 256 Mo de RAM. C'est un seuil d'entrée faible, mais les applications Django réelles utilisant un ORM, des sessions et des middleware fonctionnent rarement confortablement avec moins de 2 Go de RAM, en particulier avec plusieurs utilisateurs simultanés. Box M est donc le minimum pratique pour aller au-delà d'un prototype.

2. SSH, migrations et gestion de l'application depuis le terminal

Dès Box M, l'accès SSH complet avec sudo permet d'exécuter directement les opérations Django habituelles depuis le terminal: manage.py migrate, collectstatic, createsuperuser, sans passer par un panneau d'administration de l'hébergement distinct, qui ne comprend pas les commandes Django.

Le déploiement Git met à jour le code de l'application à chaque push sur la branche définie. En revanche, les migrations de base de données et les étapes suivantes du déploiement, comme le redémarrage du processus gunicorn ou la collecte des fichiers statiques, exigent encore une commande manuelle via SSH. Pour un développeur qui maîtrise Django, c'est une étape standard et bien maîtrisée.

Celery et les tâches en arrière-plan, comme les rappels, l'envoi d'e-mails ou le traitement en file d'attente, peuvent être lancés comme processus distinct dans le même conteneur, avec une configuration systemd adaptée. Pour les applications Django utilisant des tâches asynchrones, cela fait souvent partie de l'architecture standard. Surveille alors séparément la consommation de mémoire du processus web et du processus worker Celery, car les deux partagent la même limite de RAM allouée à l'ensemble du conteneur de l'application sur un Box donné, surtout lorsque plusieurs tâches Celery s'exécutent en parallèle en arrière-plan.

3. Base de données pour Django

Django utilise par défaut une base de données relationnelle. Sur Saplo, Postgres et MySQL sont proposés comme modules de base de données distincts, déployés en conteneurs dans ton propre compose. Ils ne constituent pas des options payantes facturées séparément de l'hébergement de l'application.

Pour les projets qui nécessitent Redis, par exemple comme broker Celery ou cache des sessions, un module Redis distinct est disponible. Tu peux le déployer sur le même Box que l'application Django, sans devoir te connecter à un service Redis extérieur à l'infrastructure Saplo.

4. Django face aux PaaS Python

Les plateformes PaaS spécialisées en Python facturent souvent selon un modèle par instance ou en fonction des ressources consommées à l’heure, avec des prix en dollars. Avec un trafic réel de production en Pologne, cela complique la planification d’un budget en PLN et expose la facture aux variations de change.

Sur Saplo, le prix est fixe, annuel et libellé en PLN, quel que soit le nombre de requêtes par seconde que l’application traite à un moment donné. Pour un projet au trafic irrégulier (par ex. une application interne d’entreprise utilisée uniquement pendant les heures de travail), c’est plus simple à estimer qu’une facturation horaire des ressources.

5. À qui cela s'adresse

Pour un développeur qui construit une application web ou un système interne d'entreprise en Django, Box M avec un accès SSH complet offre un environnement de production prêt à exécuter les migrations et à être configuré, sans devoir installer un serveur de toutes pièces.

Pour une équipe qui développe une application plus volumineuse avec Celery, Redis et une base de données dédiée, Box L offre suffisamment de RAM pour faire tourner plusieurs processus en parallèle dans le même conteneur ou sur des modules de base de données distincts à côté.

Pour une agence qui développe des systèmes B2B en Django pour ses clients, un seul Box peut héberger simultanément plusieurs installations Django indépendantes, chacune dans son propre conteneur et avec sa propre base de données.

6. Premier déploiement d'une application Django sur Saplo

Après avoir déployé une application Django avec la version de Python choisie, connecte le dépôt Git pour que le code se mette à jour automatiquement à chaque push. Puis, via SSH, exécute une première fois manage.py migrate et createsuperuser afin d'accéder au panneau d'administration Django.

Tu définis les variables d’environnement (SECRET_KEY, chaîne de connexion à la base, clés d’API externes) dans le panneau de l’application ou dans un fichier.env du conteneur, conformément à la pratique standard qui consiste à tenir la configuration de Django hors du dépôt de code.

Si ton application utilise Celery pour les tâches en arrière-plan, configure un processus systemd supplémentaire dans le conteneur, avec un worker et, en option, beat pour les tâches planifiées. Redis sert de broker et est déployé comme module distinct sur le même Box.

Il vaut mieux configurer les fichiers statiques avec collectstatic au niveau du virtual host nginx du Box, afin qu'ils ne sollicitent pas le processus gunicorn pour les servir. Le serveur web les traitera plus rapidement, avec une consommation de RAM plus faible.

Après le premier déploiement, surveille les journaux gunicorn et Django via SSH afin de repérer les erreurs de configuration, par exemple un DEBUG=True oublié en production, avant que l'application ne soit soumise au trafic réel des utilisateurs.

7. Django REST Framework et applications API sur Saplo

Les applications Django conçues comme des API (Django REST Framework) fonctionnent sur le même Box exactement comme les applications classiques qui utilisent des templates. La différence réside dans le code Django, pas dans la manière dont Saplo les héberge.

Pour une API qui utilise l'authentification par jeton, il est recommandé de conserver les secrets (clés JWT, clés API de services externes) dans les variables d'environnement du conteneur, plutôt que dans le code du dépôt, conformément aux bonnes pratiques de sécurité.

CORS et les autres en-têtes de sécurité se configurent au niveau de l'application Django elle-même, via son middleware. Le proxy inverse Saplo transmet ces en-têtes sans les modifier, si bien que la configuration standard de Django fonctionne sans étapes supplémentaires.

Pour une API qui sert un frontend intégré à un autre domaine (par ex. une application Next.js hébergée dans une autre Box ou sur un hébergement externe), il faut prêter attention à la configuration des paramètres ALLOWED_HOSTS et CORS_ALLOWED_ORIGINS dans les réglages de Django.

8. Sécuriser la configuration Django en production

L'erreur la plus fréquente lors du déploiement de Django en production est de laisser DEBUG=True. En cas d'erreur, l'application expose alors à l'utilisateur la pile d'appels complète, avec les variables d'environnement et des fragments de code, ce qui constitue une fuite grave d'informations sur la structure interne de l'application.

Le SECRET_KEY utilisé par Django pour signer les sessions et les jetons doit être unique pour chaque déploiement et ne jamais figurer dans le dépôt de code. Il doit être défini comme variable d’environnement dans la configuration de l’application sur Saplo, séparément du code source.

ALLOWED_HOSTS doit contenir exactement les domaines qui donnent accès à l'application, et non un astérisque autorisant tous les hôtes. C'est une protection fondamentale contre les attaques par injection d'en-tête Host, particulièrement importante pour les applications qui reçoivent des données d'utilisateurs depuis Internet.

Il est recommandé de séparer logiquement les fichiers statiques et les médias téléversés par les utilisateurs (uploads): les fichiers statiques de l’application sont servis par nginx, tandis que les fichiers téléversés passent par un mécanisme distinct avec des permissions adaptées, afin d’éviter qu’un utilisateur puisse téléverser puis exécuter un script malveillant sur le serveur.

Les mises à jour de Django et des paquets Python utilisés (requirements.txt) doivent être régulières. Comme dans l'écosystème Node.js, les dépendances obsolètes constituent en effet un vecteur d'attaque fréquent pour des failles de sécurité connues, déjà corrigées et souvent exploitées par des scanners de vulnérabilités automatisés.

Pour les applications qui stockent des données personnelles d’utilisateurs, il est important de configurer explicitement les paramètres de session (durée d’expiration, options Secure et HttpOnly des cookies). Django les prend en charge nativement, mais ils exigent une configuration explicite dans les paramètres du projet et ne fonctionnent pas correctement avec les seules valeurs par défaut dans tous les cas. Il est recommandé d’examiner cette configuration et la liste complète des paramètres de sécurité de Django avant la première mise en production, plutôt que de découvrir un paramètre manquant après un véritable incident de sécurité.

9. L'écosystème Python et les paquets qui soutiennent les applications Django

Python et Django profitent d'un riche écosystème de paquets (PyPI) couvrant les besoins courants des applications web: authentification, intégration à des API externes, génération de rapports PDF ou gestion des paiements. Tu peux ainsi développer les fonctionnalités de ton application avec des solutions éprouvées, au lieu de tout créer de zéro.

Sur Saplo, l'accès SSH complet avec sudo (à partir de Box M) permet d'installer n'importe quel paquet Python via le gestionnaire pip standard, sans les restrictions imposées par la plateforme d'hébergement. Cette approche se distingue de certains environnements PaaS fermés, qui ne prennent en charge qu'une liste limitée de bibliothèques.

Le choix entre les extensions Django populaires (Django REST Framework pour les API, Django Channels pour les WebSockets et Django CMS pour la gestion de contenu) revient entièrement au développeur qui construit l'application. L'hébergement n'impose aucune contrainte architecturale a priori.

La mise à niveau de Python (de 3.11 à 3.12) est proposée comme option de configuration de l'application. Tu peux ainsi profiter des nouvelles fonctionnalités du langage et des correctifs de performance sans devoir migrer vers un autre fournisseur simplement pour changer de version d'environnement d'exécution.

Pour les équipes qui développent des applications Django plus complexes (avec Celery, Redis et de nombreuses intégrations externes), le contrôle total de l’environnement via SSH, combiné aux modules de base prêts à l’emploi de Saplo, offre une souplesse proche de celle d’un VPS classique, tout en réduisant le temps de déploiement de l’environnement de base.

10. Tester les migrations de base de données avant le déploiement en production

Les migrations Django qui modifient la structure de la base de données, comme l'ajout d'une colonne ou le changement du type d'un champ, doivent d'abord être testées sur une copie de la base plutôt que sur la base de production. En effet, une erreur de migration peut entraîner une perte de données ou rendre l'application indisponible pendant son exécution.

Une sauvegarde de la Box (à partir de Box L) avant une migration importante constitue une protection supplémentaire et te permet de revenir à l’état précédant la migration si quelque chose tourne mal. Il est néanmoins recommandé de créer aussi manuellement une sauvegarde distincte de la base juste avant l’opération de migration.

Les migrations irréversibles (par exemple la suppression d'une colonne contenant des données) exigent une attention particulière: en cas d'erreur, les données supprimées ne peuvent être restaurées qu'à partir d'une sauvegarde effectuée avant la migration. Annuler simplement la migration dans Django ne suffit pas.

Pour les équipes qui travaillent sur la même base de données, il est conseillé de définir une procédure claire d'exécution des migrations en production (qui les réalise, à quel moment et après quels tests), afin d'éviter que deux personnes ne lancent simultanément des migrations incompatibles sur la même base.

L'accès SSH complet avec sudo sur Saplo (à partir de Box M) fournit tous les outils nécessaires pour effectuer une migration en sécurité. La discipline du processus (test, sauvegarde, puis migration en production) reste toutefois entièrement de la responsabilité de l'équipe de développement qui gère le projet.

11. Résumé: Django sur Saplo pour les développeurs qui veulent garder le contrôle

L'accès SSH complet avec sudo, le choix de la version de Python et la configuration prête à l'emploi de gunicorn et nginx offrent au développeur Django l'équilibre entre contrôle et simplicité qu'il recherche lors du déploiement d'une application en production. Les commandes manage.py standard fonctionnent comme prévu, et toute la couche serveur qui les accompagne est déjà prête, au lieu de devoir être reconstruite à la main pour chaque nouveau projet Django. Pour les équipes qui gèrent plusieurs projets Django, cette configuration reproductible permet au projet suivant de démarrer aussi vite que le premier, sans répéter les mêmes étapes de configuration du serveur, désormais bien maîtrisées. Concrètement, cela laisse moins de place aux petites différences de configuration difficiles à détecter entre projets, souvent à l'origine d'erreurs de production subtiles sur les serveurs installés manuellement.