Django REST Framework API Deployment and Production Best Practices: Environment Variables, Security, Logging, and Server Configuration

Introduction

Developing an API locally is only the first step in building a professional Django application. Before making an API available to real users, developers must prepare the application for a production environment.

Production deployment involves configuring environment variables, securing sensitive information, setting up database connections, handling errors, configuring logging, and serving the application through an appropriate production server.

In this module, you will learn how to prepare a Django REST Framework API for deployment and understand the security and configuration practices that help maintain a reliable application.

What You Will Learn

• The difference between development and production environments.

• How to configure environment variables.

• How to protect Django's secret key and database credentials.

• How to configure Django production security settings.

• How to prepare static files and database connections.

• How to configure application logging.

• How to run Django's deployment checks.

• How to understand WSGI and ASGI deployment.

• How to prepare a Django REST API for production.

1. Understanding Development and Production Environments

A development environment is used while building and debugging an application. A production environment is where the application serves actual users and real business requests.

Development	Production
Debugging is enabled when needed	Debugging must be disabled
Local development database may be used	A properly managed database is configured
Development server is commonly used	A production-capable server is used
Detailed error pages help debugging	Errors must not expose sensitive information
Test credentials may be used	Secrets must be protected

For example, a developer may run an API locally using:

python manage.py runserver

This is useful during development, but Django's built-in development server is not intended for production use.

A production deployment typically uses a production-capable WSGI or ASGI server, often behind a reverse proxy or managed hosting platform.

2. Understanding Environment Variables

Environment variables store configuration values outside the application's source code.

Examples include:

• Django secret key.

• Database credentials.

• Debug mode.

• Allowed hostnames.

• External service credentials.

Keeping sensitive values out of source code reduces the risk of accidentally exposing them through a public repository.

Example: Reading Environment Variables

In settings.py, import Python's os module:

import os

SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "")

DEBUG = (
    os.environ.get("DJANGO_DEBUG", "False").lower()
    == "true"
)

ALLOWED_HOSTS = [
    host.strip()
    for host in os.environ.get(
        "DJANGO_ALLOWED_HOSTS", ""
    ).split(",")
    if host.strip()
]

This configuration reads values from the environment instead of hardcoding them.

Important: The empty defaults are intentional here. In production, a missing secret key or empty ALLOWED_HOSTS should cause deployment validation to fail rather than silently accepting an insecure configuration.

3. Using a .env File During Development

A .env file is a convenient way to store local configuration values. Django does not automatically load .env files by default; you need an appropriate library or another environment-loading mechanism.

Install python-dotenv:

pip install python-dotenv

A local .env file might contain:

DJANGO_SECRET_KEY=replace-with-a-long-random-secret
DJANGO_DEBUG=True
DJANGO_ALLOWED_HOSTS=127.0.0.1,localhost

Load it near the beginning of settings.py:

import os
from dotenv import load_dotenv

load_dotenv(BASE_DIR / ".env")

Make sure BASE_DIR is defined before this code executes. In a standard Django project, it is commonly defined near the top of settings.py.

Protecting the .env File

Add the following entry to .gitignore:

.env

Do not commit actual production credentials to a public or shared repository.

For production, use your hosting provider's environment configuration or a dedicated secrets manager. If a secret is exposed, rotate it rather than relying only on deleting it from the source file.

4. Configuring Production Security Settings

Django provides several settings that help protect a production application.

Important Settings

DEBUG = False

ALLOWED_HOSTS = [
    "api.example.com",
    "example.com",
]

Replace these example hostnames with the actual hostnames serving your application.

DEBUG = False prevents Django from showing detailed debug pages to users when an unhandled error occurs.

ALLOWED_HOSTS restricts which hostnames Django accepts in incoming HTTP requests.

Avoid using ALLOWED_HOSTS = ["*"] as a shortcut for production configuration.

HTTPS and Secure Cookies

When HTTPS is correctly configured at the application server or reverse proxy, secure cookie settings can help protect session and CSRF cookies.

CSRF_COOKIE_SECURE = True
SESSION_COOKIE_SECURE = True

Django also supports HTTPS-related settings such as SECURE_SSL_REDIRECT and HTTP Strict Transport Security (HSTS).

Enable them only after confirming that HTTPS works correctly and that any reverse proxy forwards request security information properly. Misconfiguration can cause redirect loops or make the application inaccessible.

Security principle: Do not copy production security settings blindly. Understand your hosting architecture and test them before deployment.

5. Configuring a Production Database

Django supports several database backends, including SQLite and PostgreSQL.

For production applications with multiple users and concurrent requests, a managed database such as PostgreSQL is often a suitable choice.

A PostgreSQL configuration can use environment variables:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ.get("DB_NAME"),
        "USER": os.environ.get("DB_USER"),
        "PASSWORD": os.environ.get("DB_PASSWORD"),
        "HOST": os.environ.get("DB_HOST"),
        "PORT": os.environ.get("DB_PORT", "5432"),
    }
}

Install the PostgreSQL driver supported by your deployment environment, such as:

pip install "psycopg[binary]"

The database name, user, password, host, and port must match the credentials supplied by your database provider.

Never assume that a database configured for your local machine will automatically be available on the production server.

Applying Database Migrations

Before deploying model changes, run:

python manage.py makemigrations
python manage.py migrate

makemigrations generates migration files from model changes. migrate applies the migrations to the configured database.

In a deployment workflow, migration files should generally be created and reviewed during development, committed to version control, and applied to the production database during a controlled release.

Always maintain a suitable backup and rollback plan before making production database changes.

6. Managing Dependencies

A Django project relies on packages such as Django REST Framework, database drivers, and other third-party libraries.

Record the project's installed dependencies:

pip freeze > requirements.txt

On a fresh deployment environment, install them with:

pip install -r requirements.txt

For larger or long-lived projects, use a deliberate dependency-management process with tested and pinned versions. Avoid upgrading every package during a production release without checking compatibility.

7. Preparing Static Files

Django's collectstatic command collects static files into the directory configured by STATIC_ROOT.

Example settings:

STATIC_URL = "static/"
STATIC_ROOT = BASE_DIR / "staticfiles"

Collect static files using:

python manage.py collectstatic

The production web server, hosting platform, or configured static-file storage service must then serve the collected files.

Note: Django REST Framework APIs that return JSON may not need many static assets. However, the Django admin interface and browsable API can use CSS, JavaScript, and image files.

Static files are different from user-uploaded media files. Uploaded media requires its own storage, access-control, and backup strategy.

8. Configuring Logging

Logging records information about application activity, warnings, errors, and failures.

Good logging helps developers diagnose problems without exposing sensitive information to users.

Example configuration:

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
        },
    },
    "root": {
        "handlers": ["console"],
        "level": "INFO",
    },
}

This basic configuration sends log messages at the INFO level and above to the console.

For example, a view can log an operational message:

import logging
from rest_framework.response import Response
from rest_framework.views import APIView

logger = logging.getLogger(__name__)


class HealthCheckView(APIView):

    def get(self, request):
        logger.info("Health check endpoint accessed")

        return Response({
            "status": "ok"
        })

In production, logs can be collected by the hosting platform or a centralized logging service.

Never log passwords, authentication tokens, secret keys, or sensitive personal information.

9. Running Django Deployment Checks

Django provides a built-in command to identify common deployment configuration problems.

Run:

python manage.py check --deploy

This command checks the project against several deployment-related recommendations.

It may report issues involving:

• Debug mode.

• Secret-key configuration.

• Allowed hosts.

• Cookie security.

• HTTPS-related settings.

• Other deployment configuration concerns.

Resolve the relevant warnings based on your application's architecture.

Passing the deployment check does not guarantee that the entire deployment is secure. Database access, network configuration, permissions, dependencies, backups, and API-specific authorization still need review.

10. Understanding WSGI and ASGI

Django supports two common application interfaces.

WSGI (Web Server Gateway Interface) is widely used for synchronous Python web applications.

ASGI (Asynchronous Server Gateway Interface) supports asynchronous applications and can handle asynchronous protocols such as WebSockets when the application stack supports them.

Django projects typically include an asgi.py file and a wsgi.py file.

Example WSGI application path:

myproject.wsgi:application

Example ASGI application path:

myproject.asgi:application

The actual path depends on your Django project package name.

A production server such as Gunicorn can serve a WSGI application. ASGI applications can be served using an ASGI server such as Uvicorn or Daphne.

Choose the server and interface that fit your application and hosting environment. Merely using ASGI does not automatically make synchronous code faster.

11. Preparing the REST API for Production

Before deployment, review these areas.

Authentication

Choose an authentication mechanism appropriate for your API, such as session authentication, token authentication, or an OAuth-based approach where required.

Permissions

Configure permissions so users can access only the resources and actions they are authorized to use.

Throttling

DRF throttling can help limit request rates for selected users or endpoints. It is not a complete defense against denial-of-service attacks and should be combined with infrastructure-level protections where necessary.

Error Handling

Return appropriate HTTP status codes and clear, non-sensitive error responses.

API Documentation

Review Swagger or OpenAPI documentation and restrict access if the API details are intended only for internal developers.

Database and Backups

Confirm that the production database is reachable, migrations are applied, backups are scheduled, and recovery procedures are tested.

12. Deployment Checklist

Before releasing your API, verify the following:

• DEBUG is set to False.

• A strong secret key is supplied securely.

• ALLOWED_HOSTS contains the correct hostnames.

• Production database credentials are configured.

• Dependencies are installed and compatible.

• Database migrations have been reviewed and applied.

• Static files are collected and served correctly.

• HTTPS is configured and tested.

• Authentication and permissions have been tested.

• Logs do not expose sensitive information.

• API tests pass.

• Database backups and recovery procedures are ready.

• python manage.py check --deploy has been reviewed.

• The application is served using a production-capable server.

Frequently Asked Questions (FAQs)

Q1. Why should DEBUG be disabled in production?

Debug pages can expose internal application details, file paths, settings information, and diagnostic data. Production applications should not reveal these details to users.

Q2. What is an environment variable?

An environment variable is a configuration value supplied to a running process from its environment rather than being hardcoded in application source code.

Q3. Is a .env file secure by itself?

No. A .env file is only a way to store configuration. It must be protected from unauthorized access and excluded from version control. Production secrets should be stored using secure hosting configuration or a secrets manager.

Q4. What does ALLOWED_HOSTS do?

It specifies the hostnames Django accepts when validating incoming requests.

Q5. What is the purpose of collectstatic?

It collects static files from configured locations into the directory specified by STATIC_ROOT, ready for production static-file serving.

Q6. Why is logging important?

Logging helps developers investigate errors, understand application behavior, and monitor production issues.

Q7. What is the difference between WSGI and ASGI?

WSGI is commonly used for synchronous web applications. ASGI supports asynchronous applications and additional asynchronous protocols when the rest of the application stack supports them.

Q8. Does passing check --deploy mean the API is completely secure?

No. The command detects selected configuration issues. Complete security also requires code review, permission testing, infrastructure security, dependency management, and operational monitoring.

Interview Questions and Answers

1. What is production deployment in Django?

Production deployment is the process of configuring and running a Django application in an environment that serves real users reliably and securely.

2. Why should secrets be stored outside source code?

Separating secrets from source code reduces the risk of accidental disclosure through repositories, logs, or shared files.

3. What is the purpose of DEBUG = False?

It disables detailed debug error pages that could expose internal application information.

4. What is the difference between static files and media files?

Static files are application assets such as CSS, JavaScript, and icons. Media files are user-uploaded content, such as profile images and documents.

5. What does python manage.py check --deploy do?

It runs Django's deployment-focused system checks to identify selected security and configuration problems.

6. Why are database backups important?

Backups allow an organization to recover data after accidental deletion, corruption, or certain infrastructure failures.

7. What is the role of a production application server?

It runs the Django application and handles requests using an appropriate WSGI or ASGI interface.

8. Why should API permissions be reviewed before deployment?

Incorrect permissions can allow users to access or modify data they should not be able to access.

9. What is throttling in Django REST Framework?

Throttling limits how frequently requests are allowed under configured policies. It can help manage usage but is not a complete security or denial-of-service solution.

10. Why should production logs avoid sensitive data?

Logs may be stored or viewed by multiple systems and personnel. Sensitive information in logs can create unnecessary security and privacy risks.

Practical Assignment

Prepare a Django REST Framework Product API for a production-style deployment.

Requirements:

1. Configure the secret key using an environment variable.

2. Disable debug mode in the production configuration.

3. Configure valid production hostnames.

4. Configure a PostgreSQL database using environment variables.

5. Record and install dependencies using requirements.txt.

6. Configure static files and understand how production media storage differs.

7. Add basic application logging.

8. Verify that API authentication and permissions work correctly.

9. Run the automated test suite.

10. Run python manage.py check --deploy and resolve applicable issues.

11. Document your deployment process and backup strategy.

12. Select a suitable WSGI or ASGI server for your application.

Expected Result: A Django REST Framework project with production-oriented configuration, protected secrets, validated API permissions, logging, and a documented deployment checklist.

Conclusion

In this module, you learned how to prepare Django REST Framework APIs for production by managing environment variables, configuring security settings, preparing databases and static files, setting up logging, and running deployment checks.

A successful deployment is not just about making an API accessible online. It also requires reliable configuration, secure access control, database protection, monitoring, and a tested recovery strategy.

In Module 29, you will learn about Django REST Framework Performance Optimization and Caching, including query optimization, database indexing, caching strategies, and improving API response times.