# How to Deploy a Django App on Render

> Deploy a Django app on Render step by step with PostgreSQL, static files, migrations, and env vars. Plus the limitations developers hit in production.
- **Author**: omkar-anbhule
- **Published**: 2026-05-18
- **Modified**: 2026-05-18
- **Category**: Deployment Guides
- **URL**: https://kuberns.com/blogs/deploy-django-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

![What you need before deploying Django on Render](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/what-you-need-before-deploying-django-on-render.png)

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:

```bash
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

![Step by step guide to deploy Django on Render](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/step-by-step-to-deploy-django-on-render.png)

### 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:

```python
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](https://kuberns.com/blogs/render-pricing/).

### 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:

```bash
#!/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:

```bash
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:

| Key | Value |
|---|---|
| `SECRET_KEY` | Your Django secret key |
| `DATABASE_URL` | Internal Database URL from your PostgreSQL service |
| `PYTHON_VERSION` | `3.11.0` (or whichever version your project uses) |

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](https://kuberns.com/blogs/deploy-python-app-on-render/).

## What Breaks When You Deploy Django on Render

![What breaks when you deploy Django on Render](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/what-breaks-when-you-deploy-django-on-render.png)

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](https://kuberns.com/blogs/how-to-deploy-on-render/).

## Is Render Good for Django in Production

![Is Render good for Django in production](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/is-render-good-for-django.png)

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

![Deploy your Django app without manual setup on Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-home-page-new.png)

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.

[![Deploy on Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/deploy-on-kuberns-bannner6.png)](https://dashboard.kuberns.com)

## 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](https://dashboard.kuberns.com) and skip straight to shipping.

## Frequently Asked Questions

**Can I deploy Django on Render for free?**

Yes. Render offers a free tier for both web services and PostgreSQL. Free web services sleep after 15 minutes of inactivity and free PostgreSQL instances expire after 90 days. The free tier works for testing but is not suitable for production apps.

**Does Render support Django with PostgreSQL?**

Yes. You create a PostgreSQL instance on Render, copy the internal database URL, configure it in `settings.py` using `dj-database-url`, and run migrations through a build script.

**Why is my Django app slow on Render?**

If you are on the free tier, your service sleeps after 15 minutes idle. The next request triggers a cold start that takes 30 seconds or more for Django apps. Upgrading to a paid plan disables the sleep behavior.

**Why did my Render free database stop working?**

Render free PostgreSQL databases expire after 90 days. Once expired, the database is deleted permanently. Upgrade to a paid plan or migrate your data before the 90-day limit.

**Can Render handle media file uploads for Django?**

Not with the default setup. Render's container filesystem is ephemeral and files are deleted on every redeploy. You need to configure Django to use external object storage (S3 or R2) for persistent media uploads.

**What is the best Render alternative for Django deployment?**

Kuberns is a strong alternative. Its Agentic AI engine detects your Django project automatically, provisions PostgreSQL, handles static files and migrations, and manages SSL and process configuration without any manual setup.

---
- [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/)
- [All articles](https://kuberns.com/blogs/)