---
title: "Checklista för driftsättning"
version: 5.2
locale: sv
source: https://docs.djangoproject.com/sv/5.2/howto/deployment/checklist/
canonical: https://djangodocs.dev/sv/5.2/howto/deployment/checklist/
---
# Checklista för driftsättning

Internet är en fientlig miljö. Innan du distribuerar ditt Django-projekt bör du ta dig tid att se över dina inställningar, med tanke på säkerhet, prestanda och drift.

Django innehåller många [säkerhetsfunktioner](/sv/5.2/topics/security/). Vissa är inbyggda och alltid aktiverade. Andra är valfria eftersom de inte alltid är lämpliga eller för att de är obekväma för utveckling. Att till exempel tvinga fram HTTPS kanske inte är lämpligt för alla webbplatser, och det är opraktiskt för lokal utveckling.

Prestandaoptimeringar är en annan kategori av kompromisser med bekvämlighet. Cachelagring är till exempel användbart i produktion, men mindre användbart för lokal utveckling. Behoven av felrapportering skiljer sig också mycket åt.

Följande checklista innehåller inställningar som:

- måste vara korrekt inställd för att Django ska kunna tillhandahålla den förväntade säkerhetsnivån;
- förväntas vara olika i varje miljö;
- aktivera valfria säkerhetsfunktioner;
- möjliggöra prestandaoptimeringar;
- tillhandahålla felrapportering.

Många av dessa inställningar är känsliga och bör behandlas konfidentiellt. Om du släpper källkoden för ditt projekt är det vanligt att du publicerar lämpliga inställningar för utveckling och använder en privat inställningsmodul för produktion.

## Kör `manage.py check --deploy`

Vissa av de kontroller som beskrivs nedan kan automatiseras med hjälp av alternativet [`check --deploy`](/sv/5.2/ref/django-admin/#cmdoption-check-deploy). Var noga med att köra den mot din produktionsinställningsfil enligt beskrivningen i alternativets dokumentation.

## Byt bort från `manage.py runserver`

Kommandot [`runserver`](/sv/5.2/ref/django-admin/#django-admin-runserver) är inte utformat för en produktionsmiljö. Var noga med att byta till en produktionsklar WSGI- eller ASGI-server. För några vanliga alternativ, se [WSGI-servrar](/sv/5.2/howto/deployment/wsgi/) eller [ASGI-servrar](/sv/5.2/howto/deployment/asgi/).

## Kritiska inställningar

### [`SECRET_KEY`](/sv/5.2/ref/settings/#std-setting-SECRET_KEY)

Den hemliga nyckeln måste vara ett stort slumpmässigt värde och den måste hållas hemlig

Se till att den nyckel som används i produktionen inte används någon annanstans och undvik att lägga den i källkontrollen. Detta minskar antalet vektorer från vilka en angripare kan få tag på nyckeln.

Istället för att hårdkoda den hemliga nyckeln i din inställningsmodul kan du ladda den från en miljövariabel:

```
import os

SECRET_KEY = os.environ["SECRET_KEY"]
```

eller från en fil:

```
with open("/etc/secret_key.txt") as f:
    SECRET_KEY = f.read().strip()
```

Om du roterar hemliga nycklar kan du använda [`SECRET_KEY_FALLBACKS`](/sv/5.2/ref/settings/#std-setting-SECRET_KEY_FALLBACKS):

```
import os

SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
    os.environ["OLD_SECRET_KEY"],
]
```

Se till att gamla hemliga nycklar tas bort från `SECRET_KEY_FALLBACKS` i god tid.

### [`DEBUG`](/sv/5.2/ref/settings/#std-setting-DEBUG)

Du får aldrig aktivera debug i produktion

Du utvecklar säkert ditt projekt med [`DEBUG = True`](/sv/5.2/ref/settings/#std-setting-DEBUG), eftersom detta möjliggör praktiska funktioner som fullständiga spårningar i din webbläsare.

För en produktionsmiljö är detta dock en riktigt dålig idé, eftersom det läcker ut massor av information om ditt projekt: utdrag ur källkoden, lokala variabler, inställningar, bibliotek som används osv.

## Miljöspecifika inställningar

### [`ALLOWED_HOSTS`](/sv/5.2/ref/settings/#std-setting-ALLOWED_HOSTS)

När [`DEBUG = False`](/sv/5.2/ref/settings/#std-setting-DEBUG), fungerar inte Django alls utan ett lämpligt värde för [`ALLOWED_HOSTS`](/sv/5.2/ref/settings/#std-setting-ALLOWED_HOSTS).

Denna inställning krävs för att skydda din webbplats mot vissa CSRF-attacker. Om du använder ett jokertecken måste du utföra en egen validering av HTTP-headern `Host` eller på annat sätt säkerställa att du inte är sårbar för denna typ av attacker.

Du bör också konfigurera webbservern som sitter framför Django för att validera värden. Den bör svara med en statisk felsida eller ignorera förfrågningar om felaktiga värdar istället för att vidarebefordra förfrågan till Django. På så sätt undviker du falska fel i dina Django-loggar (eller e-postmeddelanden om du har felrapportering konfigurerad på det sättet). På nginx kan du till exempel ställa in en standardserver för att returnera ”444 No Response” på en okänd värd:

```nginx
server {
    listen 80 default_server;
    return 444;
}
```

### [`CACHES`](/sv/5.2/ref/settings/#std-setting-CACHES)

Om du använder en cache kan anslutningsparametrarna vara olika i utveckling och i produktion. Django använder som standard [lokal minnescachning](/sv/5.2/topics/cache/#local-memory-caching) per process, vilket kanske inte är önskvärt.

Cacheservrar har ofta svag autentisering. Se till att de bara accepterar anslutningar från dina applikationsservrar.

### [`DATABASES`](/sv/5.2/ref/settings/#std-setting-DATABASES)

Parametrarna för databasanslutningen är förmodligen olika i utvecklings- och produktionsfasen.

Databaslösenord är mycket känsliga. Du bör skydda dem på exakt samma sätt som [`SECRET_KEY`](/sv/5.2/ref/settings/#std-setting-SECRET_KEY).

För maximal säkerhet bör du se till att databasservrarna endast accepterar anslutningar från dina applikationsservrar.

Om du inte har skapat säkerhetskopior för din databas ska du göra det nu!

### [`EMAIL_BACKEND`](/sv/5.2/ref/settings/#std-setting-EMAIL_BACKEND) och relaterade inställningar

Om din webbplats skickar e-post måste dessa värden vara korrekt inställda.

Som standard skickar Django e-post från [webmaster@localhost](mailto:webmaster@localhost) och [root@localhost](mailto:root@localhost). Vissa e-postleverantörer avvisar dock e-post från dessa adresser. Om du vill använda andra avsändaradresser ändrar du inställningarna [`DEFAULT_FROM_EMAIL`](/sv/5.2/ref/settings/#std-setting-DEFAULT_FROM_EMAIL) och [`SERVER_EMAIL`](/sv/5.2/ref/settings/#std-setting-SERVER_EMAIL).

### [`STATIC_ROOT`](/sv/5.2/ref/settings/#std-setting-STATIC_ROOT) och [`STATIC_URL`](/sv/5.2/ref/settings/#std-setting-STATIC_URL)

Statiska filer serveras automatiskt av utvecklingsservern. I produktion måste du definiera en [`STATIC_ROOT`](/sv/5.2/ref/settings/#std-setting-STATIC_ROOT)-katalog där [`collectstatic`](/sv/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) kommer att kopiera dem.

Se [Hur man hanterar statiska filer (t.ex. bilder, JavaScript, CSS)](/sv/5.2/howto/static-files/) för mer information.

### [`MEDIA_ROOT`](/sv/5.2/ref/settings/#std-setting-MEDIA_ROOT) och [`MEDIA_URL`](/sv/5.2/ref/settings/#std-setting-MEDIA_URL)

Mediefiler laddas upp av dina användare. De är inte pålitliga! Se till att din webbserver aldrig försöker tolka dem. Om en användare t.ex. laddar upp en `.php`-fil ska webbservern inte köra den.

Nu är det ett bra tillfälle att kontrollera din backup-strategi för dessa filer.

## HTTPS

Alla webbplatser som tillåter användare att logga in bör tillämpa HTTPS på hela webbplatsen för att undvika att skicka access-tokens i klartext. I Django inkluderar access tokens inloggning/lösenord, sessionscookien och lösenordsåterställningstoken (du kan inte göra mycket för att skydda lösenordsåterställningstoken om du skickar dem via e-post)

Att skydda känsliga områden som användarkontot eller administratören är inte tillräckligt, eftersom samma sessionskaka används för HTTP och HTTPS. Din webbserver måste omdirigera all HTTP-trafik till HTTPS och endast överföra HTTPS-förfrågningar till Django.

När du har ställt in HTTPS aktiverar du följande inställningar.

### [`CSRF_COOKIE_SECURE`](/sv/5.2/ref/settings/#std-setting-CSRF_COOKIE_SECURE)

Ställ in detta på `True` för att undvika att CSRF-cookien oavsiktligt överförs via HTTP.

### [`SESSION_COOKIE_SECURE`](/sv/5.2/ref/settings/#std-setting-SESSION_COOKIE_SECURE)

Ställ in detta på `True` för att undvika att sessionscookien oavsiktligt överförs via HTTP.

## Optimering av prestanda

Inställning [`DEBUG = False`](/sv/5.2/ref/settings/#std-setting-DEBUG) inaktiverar flera funktioner som bara är användbara under utveckling. Dessutom kan du justera följande inställningar.

### Sessioner

Överväg att använda [cachade sessioner](/sv/5.2/topics/http/sessions/#cached-sessions-backend) för att förbättra prestandan.

Om du använder databaserade sessioner bör du regelbundet [rensa gamla sessioner](/sv/5.2/topics/http/sessions/#clearing-the-session-store) för att undvika att onödiga data lagras.

### [`CONN_MAX_AGE`](/sv/5.2/ref/settings/#std-setting-CONN_MAX_AGE)

Om du aktiverar [persistent database connections](/sv/5.2/ref/databases/#persistent-database-connections) kan det resultera i en trevlig hastighetshöjning när anslutningen till databasen står för en betydande del av bearbetningstiden för begäran.

Detta är till stor hjälp på virtualiserade värdar med begränsad nätverksprestanda.

### [`TEMPLATES`](/sv/5.2/ref/settings/#std-setting-TEMPLATES)

Om du aktiverar den cachade mallladdaren förbättras prestandan ofta drastiskt, eftersom du slipper kompilera varje mall varje gång den ska renderas. När [`DEBUG = False`](/sv/5.2/ref/settings/#std-setting-DEBUG), aktiveras den cachade mallladdaren automatiskt. Se [`django.template.loaders.cached.Loader`](/sv/5.2/ref/templates/api/#django.template.loaders.cached.Loader) för mer information.

## Felrapportering

När du väl skickar din kod till produktion är den förhoppningsvis robust, men du kan inte utesluta oväntade fel. Tack och lov kan Django fånga upp fel och meddela dig om detta.

### [`LOGGING`](/sv/5.2/ref/settings/#std-setting-LOGGING)

Se över din loggningskonfiguration innan du sätter din webbplats i produktion och kontrollera att den fungerar som förväntat så snart du har fått lite trafik.

Se [Loggning](/sv/5.2/topics/logging/) för mer information om loggning.

### [`ADMINS`](/sv/5.2/ref/settings/#std-setting-ADMINS) och [`MANAGERS`](/sv/5.2/ref/settings/#std-setting-MANAGERS)

[`ADMINS`](/sv/5.2/ref/settings/#std-setting-ADMINS) kommer att meddelas om 500 fel via e-post.

[`MANAGERS`](/sv/5.2/ref/settings/#std-setting-MANAGERS) kommer att meddelas om 404-fel. [`IGNORABLE_404_URLS`](/sv/5.2/ref/settings/#std-setting-IGNORABLE_404_URLS) kan hjälpa till att filtrera bort felaktiga rapporter.

Se [Hur man hanterar felrapportering](/sv/5.2/howto/error-reporting/) för mer information om felrapportering via e-post.

> **Felrapportering via e-post skalar inte särskilt bra**
>
> Överväg att använda ett felövervakningssystem som [Sentry](https://docs.sentry.io/) innan din inkorg översvämmas av rapporter. Sentry kan också samla ihop loggar.

### Anpassa standardvyerna för fel

Django innehåller standardvyer och mallar för flera HTTP-felkoder. Du kanske vill åsidosätta standardmallarna genom att skapa följande mallar i din rotmallkatalog: `404.html`, `500.html`, `403.html` och `400.html`. De [standardfelvyer](/sv/5.2/ref/views/#error-views) som använder dessa mallar bör räcka för 99% of webbapplikationer, men du kan [anpassa dem](/sv/5.2/topics/http/views/#customizing-error-views) också.