Español
English
Català
FrançaisSi un outil d’IA a généré un projet Django, son aperçu public n’est pas le serveur de production. Un site Django dynamique a besoin de Python et d’un serveur d’applications ; un VPS vous donne accès au système pour les installer et les maintenir. Le déploiement est autogéré : vous mettez à jour le système, configurez les services, protégez les secrets et préparez les sauvegardes.
Ce guide utilise Debian ou Ubuntu, Gunicorn pour un projet WSGI et Nginx en frontal. C’est un modèle, pas un déploiement testé avec votre dépôt. Remplacez djangoapp, myproject, le domaine et les chemins par les valeurs de votre projet. S’il fonctionne uniquement en ASGI, nécessite des workers ou gère autrement les fichiers statiques et téléversés, adaptez le serveur.
1. Vérifiez le projet avant de choisir le serveur
Repérez manage.py, requirements.txt ou pyproject.toml, ainsi que le module WSGI/ASGI. Lancez l’application en local et notez les versions de Python et de base de données nécessaires. Vérifiez dans les réglages générés par l’IA DEBUG, SECRET_KEY, ALLOWED_HOSTS, les origines CSRF de confiance, les URL de base de données, les clés d’API, les téléversements et les tâches en arrière-plan. Ne poussez ni .env ni secrets de production dans Git.
runserver de Django sert au développement, pas à la production. Django recommande un serveur WSGI ou ASGI adapté à la production, et sa checklist actuelle inclut manage.py check --deploy. Si le projet produit uniquement des fichiers statiques, un hébergement statique peut convenir ; le parcours VPS ci-dessous vise une application qui exécute Django pour les requêtes.
2. Préparez un VPS Linux et un utilisateur de service
Choisissez un VPS Hostbrid avec une image Debian ou Ubuntu compatible avec la version de Python du projet. Connectez-vous en SSH, appliquez les mises à jour système et n’ouvrez que les ports nécessaires. Installez les paquets du système et créez un compte de service distinct au lieu d’exécuter Django en root :
sudo apt update
sudo apt install git python3-venv nginx
sudo adduser --system --group --home /srv/djangoapp djangoappClonez le dépôt dans /srv/djangoapp/current avec cet utilisateur. Pour un dépôt privé, utilisez une clé de déploiement en lecture seule et gardez la clé privée hors du projet. Créez un environnement virtuel et installez les versions déclarées par l’application :
sudo -u djangoapp python3 -m venv /srv/djangoapp/venv
sudo -u djangoapp /srv/djangoapp/venv/bin/pip install -r /srv/djangoapp/current/requirements.txtVérifiez que Gunicorn est déclaré comme dépendance du projet avec une version fixée. N’installez pas ses paquets globalement pour cette application.
3. Configurez la production et préparez l’application
Stockez les variables de production dans un fichier géré par root et lisible par le compte de service, pas dans Git. Utilisez les noms de variables effectivement lus par vos réglages. Générez une clé secrète unique ; désactivez DEBUG ; limitez ALLOWED_HOSTS à vos domaines ; configurez les origines CSRF et HTTPS ; et fournissez les identifiants de base de données sans les pousser dans le dépôt.
Lancez ces commandes avec le même module de réglages de production et les mêmes variables d’environnement que le service utilisera. Sinon, le contrôle peut vérifier les valeurs de développement plutôt que la configuration réelle.
Avant de modifier une base de données en service, faites une sauvegarde et vérifiez comment la restaurer. Ensuite, activez l’environnement, appliquez les migrations, collectez les fichiers statiques et lancez les contrôles de déploiement de Django avec les réglages de production :
cd /srv/djangoapp/current
sudo -u djangoapp /srv/djangoapp/venv/bin/python manage.py migrate
sudo -u djangoapp /srv/djangoapp/venv/bin/python manage.py collectstatic --noinput
sudo -u djangoapp /srv/djangoapp/venv/bin/python manage.py check --deploycollectstatic nécessite un STATIC_ROOT configuré. Gardez les fichiers téléversés par les utilisateurs séparés des fichiers statiques ; prévoyez les permissions et les sauvegardes, et considérez ces téléversements comme des fichiers non fiables.
4. Exécutez Gunicorn avec un service systemd
Testez d’abord le point d’entrée WSGI depuis le dossier du projet. Remplacez myproject.wsgi:application par le module qui contient l’objet WSGI application de votre application :
cd /srv/djangoapp/current
sudo -u djangoapp /srv/djangoapp/venv/bin/gunicorn --bind 127.0.0.1:8000 myproject.wsgi:applicationUne fois le test réussi, utilisez systemd pour démarrer le processus au démarrage du VPS et le relancer après un échec. Cette unité minimale reprend le chemin WSGI du projet et charge le fichier d’environnement protégé :
[Unit]
Description=Django application
After=network.target
[Service]
User=djangoapp
Group=djangoapp
WorkingDirectory=/srv/djangoapp/current
EnvironmentFile=/etc/djangoapp.env
ExecStart=/srv/djangoapp/venv/bin/gunicorn --bind 127.0.0.1:8000 myproject.wsgi:application
Restart=on-failure
[Install]
WantedBy=multi-user.targetEnregistrez-la dans /etc/systemd/system/djangoapp.service, puis lancez sudo systemctl daemon-reload, sudo systemctl enable --now djangoapp et vérifiez sudo systemctl status djangoapp ainsi que journalctl -u djangoapp. Ajustez workers et mémoire après avoir observé les ressources du VPS et la charge de l’application.
5. Placez Nginx et HTTPS devant l’application
Pour un projet avec STATIC_URL défini sur /static/ et STATIC_ROOT dans /srv/djangoapp/current/staticfiles, une configuration Nginx de départ peut ressembler à ceci :
server {
listen 80;
server_name exemple.fr www.exemple.fr;
location /static/ {
alias /srv/djangoapp/current/staticfiles/;
}
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Enregistrez le site dans le répertoire de configuration Nginx de votre distribution, activez-le, puis exécutez sudo nginx -t avant de recharger Nginx. Gardez Gunicorn lié à loopback pour ne pas l’exposer directement à Internet. Faites pointer le domaine vers l’adresse du VPS, autorisez les ports 80/443, émettez un certificat avec la méthode prise en charge par votre distribution et forcez HTTPS avant d’accepter des connexions ou des données sensibles. Ce bloc HTTP est un point de départ pour le proxy, pas une configuration HTTPS complète.
Si Django se trouve derrière un proxy, ne configurez les réglages de proxy sécurisé que pour la chaîne de proxy que vous contrôlez. Testez la page d’accueil, l’administration, une route interne, les fichiers statiques, les formulaires et les intégrations API. Après un redémarrage, vérifiez les journaux et l’absence de secrets dans le navigateur et les logs.
Avant d’ouvrir le site
Exécutez la checklist de déploiement Django avec les réglages de production, vérifiez les sauvegardes de la base de données et des fichiers téléversés, puis testez une restauration. Consultez aussi Django avec Gunicorn et le module proxy de Nginx. Ces vérifications ne configurent ni ne surveillent le VPS à votre place.
Ce parcours convient à une application Python dont vous voulez administrer le processus. Si le projet utilise Flask, consultez le guide Flask avec Gunicorn et Nginx. Hostbrid fournit le VPS et l’accès root ; vous installez et exploitez Django, la base de données, Nginx, HTTPS, les mises à jour et les sauvegardes. Comparez les offres VPS et les tarifs actuels aux besoins en mémoire, CPU et stockage de votre application.