Găzduire Django: cerințe și opțiuni pentru producție

Actualizat / verificat: 12.10.2026 · Autor: Redacția Python Hosting România

Găzduire Django înseamnă mai mult decât un server pe care rulează runserver. În producție, Django are nevoie de o versiune de Python compatibilă, de o bază de date serioasă, de un loc pentru fișierele statice și media, de un server WSGI sau ASGI supravegheat și adesea de worker-e pentru sarcini de fundal. Explicăm fiecare cerință, comparăm un VPS românesc cu un PaaS din Frankfurt și propunem un plan de migrare în zece pași, verificat pe documentația oficială la 12.10.2026.

Cerințe pentru Django

Django 5.2 este versiunea LTS curentă, cu suport de securitate până în aprilie 2028, și rulează pe Python 3.10–3.14. Django 6.0 cere Python 3.12+. Ubuntu 24.04 vine cu Python 3.12, Debian 12 cu 3.11, iar pe PaaS fixezi versiunea cu .python-version.

Un proiect mic cu 2–3 procese Gunicorn, PostgreSQL și Redis pe aceeași mașină merge confortabil de la 2 GB RAM. Mai ai nevoie de secrete în variabile de mediu, DEBUG = False, ALLOWED_HOSTS corect și HTTPS; comanda manage.py check --deploy semnalează setările nesigure. Pentru alegerea modelului, vezi ghidul general de python hosting în România.

Bază de date și fișiere statice

SQLite e bun pentru dezvoltare, dar în producție blocările la scriere apar repede. PostgreSQL este alegerea implicită pentru Django: câmpuri JSON, căutare full-text, migrații tranzacționale. Pe VPS îl instalezi cu un utilizator separat pentru aplicație; pe PaaS primești un șir de conexiune în variabilele de mediu.

Staticele se adună cu collectstatic în STATIC_ROOT și, pe VPS, le servește Nginx. Pe PaaS, unde discul e efemer, folosești WhiteNoise pentru statice și o stocare compatibilă S3 pentru media.

WSGI/ASGI și procese background

Pentru pagini randate pe server, WSGI cu Gunicorn rămâne alegerea simplă. ASGI devine necesar pentru Channels, WebSocket-uri sau vizualizări async. Exemplu de unitate systemd (căile sunt exemple):

[Unit]
Description=Gunicorn pentru proiectul Django
After=network.target

[Service]
User=app
Group=www-data
WorkingDirectory=/srv/app
EnvironmentFile=/srv/app/.env
ExecStart=/srv/app/venv/bin/gunicorn proiect.wsgi:application --workers 3 --bind 127.0.0.1:8000
Restart=on-failure

[Install]
WantedBy=multi-user.target

Pentru ASGI, comanda devine uvicorn proiect.asgi:application --host 127.0.0.1 --port 8000 --workers 2, iar Nginx primește antetele Upgrade și Connection. Sarcinile lungi merg în Celery sau RQ, cu Redis și un worker separat. Șase greșeli frecvente:

1. DEBUG lăsat activ. Cu DEBUG = True, orice eroare afișează setări, căi și interogări SQL. Setează-l prin variabilă de mediu și rulează check --deploy înainte de lansare.
2. SECRET_KEY în Git. O cheie urcată pe GitHub trebuie considerată compromisă. Citește-o din mediu, generează una nouă pentru producție și nu o refolosi între medii.
3. runserver în producție. Serverul de dezvoltare nu e gândit pentru trafic real. Folosește Gunicorn sau Uvicorn, supravegheat de systemd ori de platformă, în spatele unui proxy HTTPS.
4. Media pe disc efemer. Pe PaaS, fișierele încărcate dispar la redeploy. Mută media pe stocare compatibilă S3 sau pe un disc persistent declarat explicit în serviciu.
5. Migrații uitate. Dacă migrate nu face parte din deploy, codul nou poate ajunge înaintea schemei. Include migrațiile în pasul de release și testează-le pe o copie.
6. Backup netestat. Un dump zilnic niciodată restaurat nu e o garanție. Programează pg_dump, păstrează copii în altă locație și încearcă o restaurare completă cel puțin trimestrial.

Plan de migrare

Mutarea pe o găzduire de producție merge bine în această ordine:

1. Inventariază dependențele. Notează versiunile de Python și Django, pachetele din requirements.txt, extensiile PostgreSQL și serviciile externe. Fixează versiunile exacte, ca mediul să fie reproductibil.
2. Alege ținta. Decide între VPS și PaaS după tabelul de mai sus, buget și timp de administrare; costul pe un an e calculat în analiza hosting Python România VPS vs PaaS.
3. Pregătește setările. Mută secretele în variabile de mediu și setează DEBUG = False, ALLOWED_HOSTS, CSRF_TRUSTED_ORIGINS și cookie-urile securizate pentru HTTPS. Păstrează setările de dezvoltare într-un fișier separat.
4. Creează mediul. Instalează Python, mediul virtual și dependențele, apoi rulează comanda check --deploy. Pe PaaS, configurează comenzile de build și de start ale serviciului web.
5. Configurează baza. Creează baza PostgreSQL și un utilizator cu drepturi minime. Dacă vii de pe SQLite, mută datele cu dumpdata și loaddata sau cu un instrument dedicat.
6. Copiază media. Transferă fișierele încărcate cu rsync sau urcă-le în stocarea S3. Verifică apoi drepturile pe fișiere și URL-urile media generate în șabloane.
7. Pornește aplicația. Configurează Gunicorn sau Uvicorn cu systemd și Nginx ca proxy și pentru statice. Testează pe IP-ul serverului sau pe un subdomeniu temporar.
8. Activează HTTPS. Obține certificatul Let's Encrypt cu Certbot sau lasă platforma să-l emită. Setează SECURE_PROXY_SSL_HEADER dacă proxy-ul trimite antetul X-Forwarded-Proto.
9. Mută domeniul. Scade TTL-ul DNS cu o zi înainte, sincronizează ultima dată baza, oprește scrierile pe serverul vechi și actualizează înregistrările DNS de tip A sau CNAME.
10. Monitorizează. Urmărește log-urile, erorile 500, memoria și durata interogărilor. Păstrează serverul vechi câteva zile ca variantă de revenire, apoi șterge-l în siguranță, cu tot cu copiile de date.

Cui i se potrivește și cui nu

Exemplu: dimensionarea unui VPS pentru Django

Rezumat

O găzduire Django bună combină Python 3.10+, PostgreSQL, un server WSGI sau ASGI supravegheat, statice servite eficient și backup testat. VPS-ul e mai ieftin, PaaS-ul mai rapid de pornit. Pentru proiecte fără ORM și admin, vezi ghidul de găzduire Flask pentru aplicații mici.

FAQ