1 14/04/2026 8 min

Su Windows 11 o 10 Django si installa senza stranezze, ma conviene farlo con un flusso pulito: Python corretto, ambiente virtuale dedicato, dipendenze isolate e verifica immediata con il server di sviluppo. Il punto non è “far partire Django”, ma evitare di sporcare il sistema con pacchetti globali e tenere tutto sotto controllo quando il progetto cresce.

Prerequisiti da sistemare prima di toccare pip

Il requisito vero è Python 3.11 o superiore, con il launcher py disponibile. Su Windows questo è il modo più robusto per gestire più versioni senza litigare con il PATH. Se hai già Python installato ma py non risponde, la prima verifica è lì: non Django.

Apri PowerShell o il Prompt dei comandi e controlla versione e launcher:

py --version
python --version
where py
where python

Atteso: py --version restituisce una versione Python recente, e where py punta al launcher di Windows. Se python --version mostra una versione vecchia o un alias del Microsoft Store, non è un problema se usi py per tutto. Se invece py manca, reinstalla Python da python.org e abilita il launcher durante l’installazione.

Durante l’installazione di Python su Windows conviene selezionare due opzioni: Add python.exe to PATH e il launcher Install launcher for all users. La prima è utile, la seconda evita ambiguità nelle macchine dove operano più utenti o più installazioni.

Creare un progetto Django in un ambiente virtuale

La sequenza corretta è: cartella progetto, virtual environment, upgrade di pip, installazione di Django. Non partire con install globali; su Windows il vantaggio del virtualenv è ancora più concreto perché riduce conflitti con tool preesistenti e con pacchetti installati per altri progetti.

Crea una cartella di lavoro e un ambiente virtuale:

mkdir C:\progetti\miosito
cd C:\progetti\miosito
py -m venv .venv

Attivazione dell’ambiente virtuale in PowerShell:

.\.venv\Scripts\Activate.ps1

Se PowerShell blocca lo script di attivazione, il problema è la policy di esecuzione, non Django. La correzione minima e reversibile è per la sessione corrente o per l’utente, non a livello macchina intera, a meno di policy aziendali esplicite.

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Se non vuoi toccare la policy, usa il Prompt dei comandi e attiva con:

.venv\Scripts\activate.bat

Una volta attivo l’ambiente, aggiorna pip e installa Django:

python -m pip install --upgrade pip
pip install django

Verifica immediata:

python -m django --version
pip show django

Atteso: una versione Django coerente con il pacchetto appena installato e un percorso sotto .venv\Lib\site-packages. Se il comando mostra un Django installato altrove, stai usando l’interprete sbagliato o non hai attivato l’ambiente.

Creare il progetto e capire cosa cambia davvero

Con Django installato, il comando iniziale crea lo scheletro del progetto. Qui conviene distinguere tra progetto e app: il progetto è il contenitore di configurazione, l’app è il modulo funzionale. Molti problemi iniziali nascono perché si confondono questi due livelli.

django-admin startproject config .

Il punto finale è importante: indica a Django di creare i file nella directory corrente invece di annidare una cartella aggiuntiva. Dopo il comando, dovresti vedere almeno:

manage.py
config\
    __init__.py
    asgi.py
    settings.py
    urls.py
    wsgi.py

Per confermare che la struttura è corretta, esegui la migrazione iniziale del database SQLite incluso nel progetto e avvia il server di sviluppo:

python manage.py migrate
python manage.py runserver

Apri http://127.0.0.1:8000/. Se vedi la pagina di benvenuto di Django, l’installazione è andata a buon fine. Se il server non parte, gli errori tipici sono porta occupata, interprete sbagliato o dipendenze rotte. In quel caso la prima cosa da leggere è l’output della console, non il browser.

Dal primo avvio a un progetto ordinato

Appena il progetto è vivo, conviene impostare tre abitudini: tenere .venv fuori dal versionamento, fissare le dipendenze in un file e separare i segreti dalla configurazione. Anche su Windows questo evita il classico progetto che funziona solo sulla tua macchina.

Esporta le dipendenze quando la base è stabile:

pip freeze > requirements.txt

In un repository Git, aggiungi almeno queste esclusioni a .gitignore:

.venv/
__pycache__/
*.pyc
.db
.env

La presenza di .env nel file di ignore non basta: non mettere segreti in chiaro nel codice o nei template. Usa variabili d’ambiente per chiavi API, stringhe di connessione e credenziali. Su Windows puoi impostarle a livello utente o sessione, ma per sviluppo locale il file .env gestito con attenzione è spesso la via più pratica, purché non finisca nel repository.

Se vuoi un approccio semplice per leggere variabili d’ambiente in Django, il pacchetto python-dotenv è una scelta comune. Installazione:

pip install python-dotenv

Nel file settings.py puoi caricare il file locale in modo esplicito, senza inventare magie:

from pathlib import Path
from dotenv import load_dotenv
import os

BASE_DIR = Path(__file__).resolve().parent.parent
load_dotenv(BASE_DIR / '.env')

SECRET_KEY = os.environ['SECRET_KEY']
DEBUG = os.environ.get('DEBUG', 'False') == 'True'

Qui il comportamento è chiaro: se SECRET_KEY manca, l’app si ferma subito. È meglio fallire in avvio che scoprire la mancanza del segreto in produzione. Se usi questo schema, la chiave va generata e salvata fuori dal codice; se è già stata esposta, ruotala.

Creare una app e verificare il flusso end-to-end

Per capire che Django è operativo, crea una app minimale e collegala alle URL del progetto. È il test più onesto: dimostra che il framework, la configurazione e il routing lavorano insieme.

python manage.py startapp core

Registra l’app in config/settings.py dentro INSTALLED_APPS:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'core',
]

Definisci una vista semplice in core/views.py:

from django.http import HttpResponse

def home(request):
    return HttpResponse('Django su Windows funziona')

Collega la rotta nel progetto. Se il file config/urls.py è quello standard, puoi usare:

from django.contrib import admin
from django.urls import path
from core.views import home

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', home),
]

Riavvia il server e verifica http://127.0.0.1:8000/. Se la risposta è la stringa definita nella view, hai validato il ciclo completo. Questo è più utile del solo “server avviato”, perché conferma che URL, import e app registry sono corretti.

Admin Django su Windows: utile, ma solo se lo prepari bene

L’admin è uno dei motivi per cui Django resta pratico: ti dà subito una console di gestione. Ma funziona bene solo se hai già applicato le migrazioni e creato un superuser.

python manage.py createsuperuser

Se l’operazione fallisce, controlla che il database sia inizializzato con python manage.py migrate e che tu stia usando l’ambiente virtuale giusto. Il login admin poi passa da http://127.0.0.1:8000/admin/.

Per chi lavora su Windows con progetti multipli, l’admin è anche un buon test di coerenza della configurazione: se la pagina si apre ma il login non funziona, il problema spesso è nella sessione, nel database o nelle migrazioni mancanti, non nell’interfaccia web.

Problemi tipici su Windows e come leggerli senza perdere tempo

Il punto debole non è Django, è la catena di strumenti intorno. I casi più frequenti sono tre: PATH confuso, policy di PowerShell e porta occupata. La cosa giusta è leggere il messaggio e agire sul livello corretto.

1. Django non viene trovato. Verifica che l’ambiente virtuale sia attivo e che il comando punti al binario giusto:

where python
where pip
python -m django --version

2. L’attivazione del virtualenv fallisce. In PowerShell il problema è quasi sempre la execution policy. Usa Set-ExecutionPolicy -Scope CurrentUser RemoteSigned oppure passa al Prompt dei comandi. Non forzare policy globali se non hai un motivo amministrativo preciso.

3. Il server non parte sulla porta 8000. Cambia porta solo se serve e dopo aver verificato il processo che occupa la 8000:

python manage.py runserver 127.0.0.1:8001

Se il progetto cresce, conviene passare presto a un setup più strutturato: database separato da SQLite, file di configurazione per ambiente, logging sensato e, in produzione, un server WSGI/ASGI adeguato. Il server di sviluppo di Django non è pensato per esporre un sito reale.

Quando passare oltre l’installazione base

L’installazione base è sufficiente per imparare, prototipare e validare logica applicativa. Appena però entrano in gioco utenti reali, autenticazione, upload, static files e prestazioni, devi aggiungere disciplina: deployment separato, variabili d’ambiente, logging centralizzato e un database vero.

Su Windows puoi sviluppare comodamente, ma non confondere ambiente di sviluppo con ambiente di esecuzione finale. Molti team usano Windows sul desktop e Linux in produzione: va benissimo, purché il progetto resti portabile. Questo significa evitare path hardcoded, dipendenze non dichiarate e file generati localmente che finiscono nel repository.

Se vuoi una regola pratica: dopo l’installazione, il test minimo non è “vedo la pagina iniziale”, ma “posso creare un ambiente isolato, installare Django, avviare un progetto, migrare il database e servire una view personalizzata senza errori”. Se quei cinque passaggi sono solidi, hai una base corretta per tutto il resto.

Sequenza rapida riassuntiva

  1. Installa Python recente da python.org e verifica py --version.
  2. Crea una cartella di progetto e un virtualenv con py -m venv .venv.
  3. Attiva l’ambiente con .\.venv\Scripts\Activate.ps1 o activate.bat.
  4. Aggiorna pip e installa Django con python -m pip install --upgrade pip e pip install django.
  5. Crea il progetto con django-admin startproject config ..
  6. Esegui python manage.py migrate e python manage.py runserver.
  7. Apri http://127.0.0.1:8000/ e verifica la pagina di benvenuto.

Da qui in avanti il lavoro vero non è più installare Django, ma costruire il progetto con ordine. Su Windows questo è perfettamente fattibile, a patto di non saltare l’ambiente virtuale e di controllare sempre quale interprete stai usando.