Django Guide
Learn how to deploy and configure Django applications with Atlas.
Django Deployment Guide#
This guide explains how to prepare your Django project for deployment using Atlas. Atlas currently supports deploying Django applications to Render and Vercel.
Atlas automatically performs strict pre-deployment static analysis on your Django project to ensure it is configured securely and correctly for production. If your project fails any of these checks, Atlas will block the deployment and provide actionable feedback.
Follow this checklist to ensure your Django project is Atlas-ready.
1. Directory Structure & manage.py#
Atlas determines that your project is a Django application by looking for a manage.py file in your repository.
- Your
manage.pymust be checked into version control. - If your
manage.pyis inside a subdirectory, Atlas will automatically detect it and configure the provider's Root Directory settings accordingly.
2. Requirements File (requirements.txt)#
Your project must include a requirements.txt file listing all dependencies.
- Important (Windows Users): If you generate this file in PowerShell using
pip freeze > requirements.txt, ensure it is saved with UTF-8 encoding. Older versions of PowerShell default to UTF-16, which will cause deployment failures on Linux-based providers like Vercel and Render. Usepip freeze | Out-File -Encoding utf8 requirements.txtinstead.
3. Web Servers & Middleware#
You must include a production-ready web server in your requirements.txt:
- WSGI: Install
gunicorn. - ASGI: Install
uvicorn.
Static Files (STATIC_ROOT)#
Regardless of the provider you choose, you must configure STATIC_ROOT in your settings.py so that the collectstatic command knows where to build your static assets.
WhiteNoise (Render Only)#
- For Render: You must install and configure
whitenoiseto serve static files.WhiteNoiseMiddlewaremust be added to yourMIDDLEWAREarray insettings.py. - For Vercel: Vercel natively serves static files via its Edge CDN, so WhiteNoise is automatically skipped and not required.
4. Environment Variables#
Hardcoded secrets are a security risk and are strictly blocked by Atlas.
- SECRET_KEY: Must be fetched from the environment. Hardcoded strings are rejected.
- DEBUG: Must be strictly controlled by the environment to prevent leaking stack traces in production.
5. Security Settings (ALLOWED_HOSTS)#
Django will block incoming traffic with a 400 Bad Request unless the domain is explicitly allowed. Atlas verifies that you are reading the correct environment variables for your chosen provider.
- For Render: Ensure you have
os.environ.get('RENDER_EXTERNAL_HOSTNAME')in yourALLOWED_HOSTS. - For Vercel: Ensure you have
os.environ.get('VERCEL_URL')in yourALLOWED_HOSTS.
Example to support both:
6. Databases#
Platform-as-a-Service providers use ephemeral filesystems. If you write to a local db.sqlite3 file in production, your database will be wiped clean every time the server restarts or deploys.
- If your Django project relies on a database (i.e. you have apps in
INSTALLED_APPSthat require a database), you must configure PostgreSQL (or another remote database engine). - Atlas enforces this by requiring
dj-database-urlin your settings. - Example:
(Note: If your project does not use a database at all, Atlas will intelligently detect this by analyzing INSTALLED_APPS and skip the database requirement).
7. Health Checks (urls.py)#
Atlas performs automated health checks on your application immediately after deploying to ensure it booted correctly.
- Your project must have a root URL pattern (e.g.,
path('', views.home)) configured in your primaryurls.py. - If it doesn't, the deployment health check will hit a
404 Not Foundand Atlas will rollback the deployment.
8. Build Scripts#
- For Render: Atlas requires a
build.shscript in the root of your project to tell Render how to build your app. It should contain: - For Vercel: Vercel utilizes zero-configuration deployments. It will automatically detect
manage.py, runpip install, and executecollectstaticnatively. Nobuild.shis required.