How to Deploy a Django App on Render

You can deploy a Django app on Render in about 15 minutes if your project is on GitHub. The process involves creating a PostgreSQL database, configuring your Django settings for production, writing a build script, and connecting your repo to a Render web service.

This guide walks through every step. It also covers the limitations you will hit once you are live, so you can decide early whether Render is the right platform for your project.

What You Need Before Deploying Django on Render

Before you start, make sure you have the following in place.

Your Django project needs to be on GitHub. Render connects directly to your repository and redeploys automatically on every push, so GitHub access is required.

Your requirements.txt needs to include four packages that Render’s production environment depends on:

• gunicorn as the production WSGI server (Django’s built-in development server is not suitable for production)
• psycopg2-binary as the PostgreSQL adapter
• dj-database-url to parse the database connection string from an environment variable
• whitenoise to serve static files without a separate CDN or Nginx config

If any of these are missing, install them and update your requirements file before deploying:

pip install gunicorn psycopg2-binary dj-database-url whitenoise
pip freeze > requirements.txt

You also need a free Render account. Sign up at render.com and connect it to your GitHub account during onboarding.

How to Deploy Django on Render: Full Setup

How Does Render Work for Django Apps

Render runs Django as a web service, which is a container that runs your application process. Your database runs as a separate PostgreSQL service. The two are connected via an environment variable that holds the database connection string.

When you push to GitHub, Render pulls the latest code, runs your build script (installing packages, collecting static files, running migrations), and starts the new version of your app. If the build fails, Render keeps the previous version running.

Static files are served by WhiteNoise directly from your Django process. This removes the need for a separate static file server or CDN for basic setups.

How to Set Up PostgreSQL and Configure Django Settings for Render

Start by creating the PostgreSQL database on Render before creating the web service. You will need the database URL when configuring the web service environment variables.

In your Render dashboard, click New and select PostgreSQL. Give the instance a name and select the free plan if you are testing. Click Create Database and wait for the status to show Available.

Once the database is ready, scroll down on the database page and copy the Internal Database URL. This is the URL your web service will use to connect to the database within Render’s network.

Now update your Django settings.py for production:

import dj_database_url
import os

SECRET_KEY = os.environ.get('SECRET_KEY')

DEBUG = False

ALLOWED_HOSTS = ['your-app-name.onrender.com']

DATABASES = {
    'default': dj_database_url.config(
        default=os.environ.get('DATABASE_URL'),
        conn_max_age=600,
        ssl_require=True
    )
}

STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware',
    # ... rest of your middleware
]

One thing to know before you proceed: Render’s free PostgreSQL plan expires after 90 days. Render’s own documentation states “do not use free instances for production.” When the free database expires, it is deleted along with all your data. If you are building anything real, budget for the paid PostgreSQL plan from the start.

**_

For context on what Render’s paid plans cost and where the pricing jumps, see Render pricing explained.
_**

How to Create a Build Script for Render

Render runs a build script once per deployment to prepare your app. Create a file called build.sh in your project root:

#!/usr/bin/env bash

set -o errexit

pip install -r requirements.txt
python manage.py collectstatic --no-input
python manage.py migrate

Make the script executable:

chmod a+x build.sh

Commit both the build.sh file and your updated settings.py to GitHub before creating the web service on Render.

How to Connect GitHub and Deploy on Render

In your Render dashboard, click New and select Web Service. Connect your GitHub account if you have not already and select your Django repository.

Configure the service with these settings:

• Environment: Python
• Build Command: ./build.sh
• Start Command: gunicorn your_project_name.wsgi:application

Replace your_project_name with the name of the Django project directory that contains your wsgi.py file.

Under Environment Variables, add the following:

Click Create Web Service. Render will pull your code, run the build script, and start the app. The first deploy typically takes two to three minutes.

Once the deploy completes, your app is available at https://your-app-name.onrender.com.

**_

If you are working with Python frameworks beyond Django and want to see how Render handles Flask and FastAPI deployments, see how to deploy a Python app on Render.
_**

What Breaks When You Deploy Django on Render

The deployment process works. What follows is what happens after you go live.

Why Does the Free Tier Put Your Django App to Sleep

Render’s free web services spin down after 15 minutes of inactivity. When the next request arrives, Render restarts the container from scratch. For Django apps with database connection setup and app initialization, this cold start takes 30 seconds or more.

For any app with real users, a 30-second load time on the first request is not acceptable. The only way to avoid it on Render is to upgrade to a paid plan, which starts at $7 per month per service.

Why Does Render Free PostgreSQL Expire After 90 Days

Render’s free PostgreSQL instances are explicitly not intended for production use. After 90 days, the database and all its data are deleted permanently. You either need to upgrade to a paid PostgreSQL plan before the deadline or migrate your data to a new database manually.

This is a significant hidden cost for anyone who starts on the free tier without reading the fine print.

Why Media Uploads Break on Render

Render web services use an ephemeral container filesystem. Any file written to the local filesystem during runtime, including user-uploaded images, documents, or attachments, is lost when the container restarts or redeploys.

Django’s default MEDIA_ROOT setup writes files to the local filesystem, which means every redeploy silently deletes all uploaded files. To handle media uploads on Render, you need to configure Django to write directly to an external object storage service like AWS S3 or Cloudflare R2 and update DEFAULT_FILE_STORAGE accordingly. This adds setup complexity that is not part of the basic deploy guide.

Why Django Migrations on Render Need Manual Attention

The build.sh script runs python manage.py migrate on every deploy. If the migration step fails mid-deploy, the database schema can end up in an inconsistent state where some migrations applied and others did not.

Render does not provide a way to run one-off commands interactively on a running service without using a paid plan’s shell access feature. Debugging a failed migration on the free tier means checking logs and potentially running migrations manually via the Render dashboard’s one-off jobs feature, which requires a paid plan.

**_

For a full picture of what Render supports across different service types beyond Django, see how to deploy on Render.
_**

Is Render Good for Django in Production

Render works well for side projects, portfolio apps, and internal tools where occasional downtime and a 90-day database limit are acceptable trade-offs for a low-cost setup.

For production Django apps serving real users, Render becomes more demanding. You need to pay for a web service plan to avoid cold starts, pay for a PostgreSQL plan to avoid the 90-day expiry, configure external object storage to handle media uploads, and manage migrations carefully to avoid inconsistent database states.

None of this is impossible. But by the time you have added all the pieces a real Django app needs, you are managing a non-trivial amount of infrastructure configuration that has nothing to do with your application.

Deploy Your Django App Without the Manual Setup

Kuberns takes a fundamentally different approach to Django deployment. Instead of requiring you to configure every layer manually, Kuberns uses an Agentic AI engine that reads your repository and sets up the entire production environment automatically.

When you connect a Django repo to Kuberns, the Agentic AI detects your framework, Python version, and dependencies without any configuration file. It provisions a managed PostgreSQL database and injects the connection string directly into your environment. It runs collectstatic and migrate in the correct order on every deploy without a build.sh file. It configures Gunicorn, SSL, and port binding automatically.

There is no render.yaml to write. No WhiteNoise setup required. No 90-day database expiry. No cold starts on the free tier. No ephemeral filesystem problem for media uploads because Kuberns provides persistent managed storage.

The Agentic AI removes the entire configuration layer that makes Django deployment on Render time-consuming. You connect your GitHub repo, add your environment variables, and click deploy.

Conclusion

Render is a capable platform and the Django deployment process is well-documented. The guide above gets you live. What it does not solve is what happens at 91 days when your free database expires, what happens when a user uploads a file and redeploys wipes it, or what happens when your app goes to sleep and the next visitor waits 30 seconds for a response.

Kuberns handles every one of those issues by default. If you want Django in production without building the infrastructure layer yourself, deploy your Django app on Kuberns and skip straight to shipping.