Welcome to Elastic Beanstalk without the drama

If your Django app is still living its best life on localhost it is time to move it to AWS Elastic Beanstalk and stop pretending that port 8000 is production. This guide walks through the real tasks you will do to deploy Django on Elastic Beanstalk using EB CLI and Gunicorn while keeping secrets out of your repo and rollbacks sane.

Prepare your Django project for production

Production means a few boring but vital changes. Make sure DEBUG is false, move sensitive keys into environment variables, and keep database settings flexible so you can point to RDS later if you want to be fancy. No hard coded credentials, no exceptions.

• Set DJANGO_SETTINGS_MODULE to a clean production settings module.
• Use environment variables for SECRET_KEY and database credentials.
• Consider AWS SSM Parameter Store for secrets if you like slightly more security and extra setup work.

Dependencies and WSGI setup

Create a virtual environment and freeze dependencies so Elastic Beanstalk can reproduce your Python environment. Gunicorn is the usual WSGI server here because it behaves and shuts down when asked to.

python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
pip freeze > requirements.txt

Ensure your project exposes a WSGI callable, usually in myproject/wsgi.py. Elastic Beanstalk will rely on that when starting Gunicorn.

Static files and collectstatic

If your instance is serving static files you will need to run collectstatic before packaging. Run this locally or let the deployment run it automatically but do not forget it. Example command that will not cause tears:

python manage.py collectstatic --noinput

If you plan to use S3 for static hosting that is a better long term option for scale and peace of mind.

Procfile and platform tweaks

Beanstalk looks for a Procfile to know how to run your app. Put a Procfile in the project root with the web command. The exact text should be web: gunicorn myproject.wsgi so Elastic Beanstalk fires up Gunicorn with your WSGI app. You can also add .ebextensions for platform configuration and environment variables if you like infrastructure as code.

Initialize and create an environment with EB CLI

The EB CLI is your friend even when it s grumpy. Initialize the project with eb init and choose the Python platform, then create an environment with eb create. Typical commands you will use are:

eb init -p python3 my-app
eb create my-app-env

Keep configuration files like Procfile and .ebextensions in the repo root so deployments are reproducible and humans can stop guessing what happened.

Deploy, monitor, and recover

Deploy with eb deploy and fetch logs with eb logs when something inevitably misbehaves. Use health checks in the Elastic Beanstalk console and CloudWatch logs for deeper digging. They do not replace reading the logs but they will save you from yelling at your terminal for 20 minutes.

• Deploy command to push a new release is eb deploy.
• Use eb logs to gather instance logs for debugging.
• Watch health checks and CloudWatch metrics to spot slow responses or failing instances.

Rollback and release strategy

Keep deployments small and frequent so rollbacks do not feel like theatrical tragedies. Elastic Beanstalk can swap environments or let you deploy a previous version. Test migrations locally or in a staging environment before you run them on production so databases do not get surprised.

Quick security tips

• Never put secrets in your repo. Ever.
• Use environment variables for runtime secrets and AWS SSM for extra protection.
• Limit instance permissions with IAM roles following least privilege.

Final words for sleep deprived deployers

Deploying Django to AWS Elastic Beanstalk is mostly procedural. Prepare settings, pin dependencies, configure WSGI with Gunicorn, use a Procfile, and let EB CLI do the heavy lifting. Monitor logs and health checks and keep releases bite sized so you can recover without dramatic emails to the team. Now go deploy and try not to break production on day one.