For Django

Django hosting,
done properly

Real VMs for Gunicorn or Uvicorn, S3-compatible storage for media, global CDN with zero egress fees. The classic Django deployment — wired up the way you'd wire it yourself, but quicker.

Start your trial Read the deploy guide

# settings.py

DEFAULT_FILE_STORAGE = 'storages.backends.s3.S3Storage'

STATICFILES_STORAGE = 'storages.backends.s3.S3Storage'

AWS_S3_ENDPOINT_URL = 'https://storage.edge.run'

AWS_STORAGE_BUCKET_NAME = 'media'

# Provision the VM

$ edge compute create \

--image ubuntu-24-04 --plan small \

--script ./bootstrap-django.sh

# CDN out front

$ edge cdn create app.example.com \

--origin https://<vm-ip>

Why Django teams pick Edge

PaaS-style simplicity, VPS-style price, no proprietary buildpacks.

Gunicorn / Uvicorn on real VMs

Run any WSGI or ASGI server (Gunicorn, Uvicorn, Granian, Daphne) on a sized-to-fit VM. Predictable RAM and CPU.

S3 storage backend

Wire `django-storages` to Edge Storage and use it as the default for `MEDIA_ROOT` and `STATIC_ROOT`. Works exactly like AWS S3.

PostgreSQL on the same network

Run Postgres on the same VM, a separate VM, or your existing managed provider. Low-latency, no egress fees between Edge resources.

On-the-fly image transforms

Skip the `sorl-thumbnail` queues — generate responsive variants from a URL via Edge Image Optimization.

Global CDN, zero egress

Front collected static and media files through the CDN. Massive cache hit rates on the things your users actually load.

Agentic deployments

Tell the Edge agent to deploy your Django app to a domain — it provisions the VM, sets up DNS and adds the CDN.

Reference architecture

How Django maps to Edge

Standard WSGI/ASGI on a VM, media in object storage, CDN out front.

Compute

Runs Gunicorn (WSGI) or Uvicorn (ASGI) behind Nginx/Caddy

Storage

Backs `django-storages` for `STATICFILES_STORAGE` and `DEFAULT_FILE_STORAGE`

CDN

Caches `/static/` and `/media/` URLs globally

Image Optimization

On-the-fly thumbnails, AVIF/WebP, smart cropping

DNS

Anycast DNS for the apex, www and admin subdomains

# /etc/systemd/system/django.service

[Service]

WorkingDirectory=/srv/app

ExecStart=/srv/app/.venv/bin/gunicorn \

myproject.wsgi:application \

--workers 4 --bind 127.0.0.1:8000

Restart=always

[Install]

WantedBy=multi-user.target

Common questions

WSGI or ASGI?

Either. Gunicorn for classic Django, Uvicorn or Daphne for ASGI/Channels. Both run as standard Python processes on an Edge VM behind a reverse proxy.

Where does Postgres go?

For small to medium loads, run it on the same VM. For larger loads, give it its own VM (private network keeps the latency low) — or point Django at your existing managed Postgres provider.

How do I deploy?

Standard `git pull` + `pip install` + `manage.py migrate` + `manage.py collectstatic` + restart. Wrap it in a CI step or systemd path unit.

How does this compare to PaaS like Heroku?

Cheaper, faster (real CPU and disk), and you keep control of the full Python environment. The trade-off is one bootstrap script — and we provide a sensible starter.

By Stack