Environment Variables and Settings Reference for Production

Gestor de Tareas Django stores its entire configuration in mi_proyecto/settings.py. The file ships with development-friendly defaults — DEBUG = True, a hardcoded SECRET_KEY, and ALLOWED_HOSTS = ['*'] — that are intentionally unsafe for production. Importantly, the default settings.py does not read from environment variables at all; it uses hard-coded values. The recommended approach for production is to modify settings.py to read sensitive values from the environment at runtime, keeping secrets out of source code and making it easy to use different values across development, staging, and production.

Recommended Pattern

Add the following overrides at the top of settings.py (after the existing imports) so that each critical value is read from the environment when present and falls back to the hard-coded default for local development. This is not what the file currently does — it is what you should add before going to production.

# settings.py — add these lines after "from pathlib import Path"
import os

SECRET_KEY = os.environ.get(
    'SECRET_KEY',
    'django-insecure-@hc_xr=e4$pg=)=)va7v6=2gdd%q5i#@i8wgay_9hig@_-n$wb'
)
DEBUG = os.environ.get('DEBUG', 'False') == 'True'
ALLOWED_HOSTS = os.environ.get('ALLOWED_HOSTS', '127.0.0.1').split(',')

Once these lines are in place, you can inject values through shell exports, a systemd EnvironmentFile, or the environment variable panel of your PaaS (such as Render). See the Production Deployment guide for concrete examples.

Settings Reference

The following settings are present in mi_proyecto/settings.py. Each entry shows the exact default value as committed in the repository, the expected type, and how the setting affects the running application.

SECRET_KEY

string

required

Django’s cryptographic signing key. Used to sign cookies, CSRF tokens, session data, and password-reset links. The repository contains the following hard-coded development placeholder, which must be replaced before going live:

django-insecure-@hc_xr=e4$pg=)=)va7v6=2gdd%q5i#@i8wgay_9hig@_-n$wb

Generate a secure replacement with:

python -c "import secrets; print(secrets.token_urlsafe(50))"

Never commit a real secret key to version control.

DEBUG

boolean

default:"True"

Controls Django’s debug mode. When True, Django renders detailed error pages with full stack traces and local variable values — invaluable during development but a significant information leak in production. The repository default is True. This must be set to False in all non-development environments.

ALLOWED_HOSTS

list

default:"['*']"

A list of hostnames or IP addresses that Django will serve. The repository default ['*'] accepts requests from any host, which is convenient locally but disables Django’s host-header validation in production. In production, set this to the exact domain(s) your application runs on, for example ['yourdomain.com', 'www.yourdomain.com'].

DATABASES.ENGINE

string

default:"django.db.backends.sqlite3"

The database backend Django uses to persist data. The default is SQLite, which requires no additional installation and stores all data in a single file on disk. For production deployments that serve more than one concurrent user, switch to django.db.backends.postgresql. See Switching to PostgreSQL below.

DATABASES.NAME

string

default:"BASE_DIR / 'db.sqlite3'"

The database identifier. For SQLite this is the filesystem path to the .db file; for PostgreSQL it is the name of the database. The repository default resolves to db.sqlite3 in the project root directory.

LANGUAGE_CODE

string

default:"es-es"

The default language for Django’s built-in translations (admin interface, form error messages, etc.). Set to 'es-es' (Spanish — Spain) in the repository. Change this to a different BCP 47 tag if you need a different locale.

TIME_ZONE

string

default:"Europe/Madrid"

The default time zone used when storing and displaying datetime values. Corresponds to the IANA time zone database name. Set to 'Europe/Madrid' in the repository. USE_TZ = True is also enabled, which means Django stores all datetimes in UTC internally and converts to TIME_ZONE for display.

The URL name (not path) that Django redirects unauthenticated users to when they try to access a protected view. Corresponds to the login named URL pattern in the project’s URL configuration.

The URL path Django redirects users to after a successful login when no explicit next parameter is present in the request. Defaults to /tareas/, the main task list view.

LOGOUT_REDIRECT_URL

string

default:"/"

The URL path Django redirects users to immediately after they log out. Defaults to /, the application root.

STATIC_URL

string

default:"static/"

The URL prefix under which static files are served. With the default value, a file at tareas/static/tareas/style.css is reachable at /static/tareas/style.css. This is the URL Nginx should match in its location /static/ block.

STATIC_ROOT

string

default:"BASE_DIR / 'staticfiles'"

The absolute filesystem path that python manage.py collectstatic writes all static files into. Resolves to staticfiles/ inside the project root. Nginx (or your PaaS) must be configured to serve files from this directory directly. Add staticfiles/ to .gitignore so the collected files are not committed to version control.

DEFAULT_AUTO_FIELD

string

default:"django.db.models.BigAutoField"

The default primary key field type used for models that do not explicitly define a primary key. Set to BigAutoField, which uses a 64-bit integer — the Django 3.2+ recommended default. This matches the repository setting and requires no change for production.

Switching to PostgreSQL

SQLite is perfectly adequate for development and single-user production deployments. For any scenario where multiple users may write to the database at the same time — or where you need transactional reliability at scale — PostgreSQL is the recommended backend. Render and most other PaaS providers offer managed PostgreSQL add-ons that are straightforward to attach to a Django application.

Replace the DATABASES block in settings.py with the following configuration. Each value is read from the environment so the same settings.py can be used across all environments without modification.

# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': os.environ.get('DB_NAME', 'gestor_tareas'),
        'USER': os.environ.get('DB_USER', 'postgres'),
        'PASSWORD': os.environ.get('DB_PASSWORD', ''),
        'HOST': os.environ.get('DB_HOST', 'localhost'),
        'PORT': os.environ.get('DB_PORT', '5432'),
    }
}

The corresponding environment variables are:

Variable	Description	Default
`DB_NAME`	Name of the PostgreSQL database	`gestor_tareas`
`DB_USER`	PostgreSQL role / username	`postgres`
`DB_PASSWORD`	Password for the PostgreSQL role	(empty)
`DB_HOST`	Hostname or IP of the PostgreSQL server	`localhost`
`DB_PORT`	TCP port the PostgreSQL server listens on	`5432`

psycopg2-binary is not currently listed in requirements.txt. To use PostgreSQL, you must add it as an optional dependency and reinstall:

psycopg2-binary>=2.9

pip install -r requirements.txt
python manage.py migrate

Getting Started

Core Features

Reference

Deployment

Environment Variables and Settings Reference for Production

Recommended Pattern

Settings Reference

Switching to PostgreSQL

Build docs developers (and LLMs) love

Getting Started

Core Features

Reference

Deployment

Documentation Index

​Recommended Pattern

​Settings Reference

​Switching to PostgreSQL

Build docs developers (and LLMs) love

Recommended Pattern

Settings Reference

Switching to PostgreSQL