Deployment

How to Deploy a Django App on ComputeSphere

P
By Peter Ekhator

Django runs a large share of the web's production apps, but shipping one still means Gunicorn, static files, a WSGI server, a process manager, and a server you have to keep patched. ComputeSphere runs your Django app as a container on a fixed per-spherelet price, so you can take it to production without standing up — or babysitting — any of that.

This guide takes a Django project to a live HTTPS URL, then covers environment variables, migrations, a custom domain, and autoscaling.

Prefer to start from a working app? Clone the ComputeSphere Django example and follow along.

Before you start

  • A Django project that runs locally
  • Docker installed locally
  • A free ComputeSphere account — the trial runs 14 days, no card required

Install the csph CLI

brew install computesphere/tap/csph
# or
npm install -g @computesphere/csph

Then sign in:

csph auth login

Get Django production-ready

Add Gunicorn to requirements.txt, and read your host and secret settings from the environment instead of hardcoding them:

import os

DEBUG = os.environ.get("DEBUG", "False") == "True"
SECRET_KEY = os.environ["SECRET_KEY"]
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "").split(",")

Containerize your app

This Dockerfile collects static files at build time and serves the app with Gunicorn. The entrypoint runs migrations once, then starts the server:

FROM python:3.12-slim
WORKDIR /app
ENV PYTHONUNBUFFERED=1
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
RUN python manage.py collectstatic --noinput
EXPOSE 8000
CMD ["sh", "-c", "python manage.py migrate --noinput && gunicorn myproject.wsgi:application --bind 0.0.0.0:8000"]

Replace myproject with your project's package name.

Deploy

From your project directory:

csph deploy

ComputeSphere builds the image, runs it on a spherelet, terminates TLS, and returns a public URL. Set the service port to 8000 — the port Gunicorn binds — and ComputeSphere routes public traffic to it:

https://violet-heron.computesphere.app

Set environment variables

Keep SECRET_KEY, database credentials, and host settings out of your image:

csph services set-env DEBUG=False ALLOWED_HOSTS=violet-heron.computesphere.app
csph services set-secret SECRET_KEY=your-secret-key DATABASE_URL=postgres://user:pass@host:5432/db

Point DATABASE_URL at the database you already run. Add each custom domain you serve from to ALLOWED_HOSTS.

Add a custom domain

Open Console → Domains, add your hostname, and create the CNAME it shows pointing to your service URL:

Type    Name    Value
CNAME   app     violet-heron.computesphere.app

ComputeSphere issues and auto-renews the SSL certificate. Remember to add the new hostname to ALLOWED_HOSTS.

Scale with spherelets

A spherelet is your unit of compute, and you pay a fixed price per spherelet. Tune Gunicorn workers inside each spherelet, run as many spherelets as you need, and turn on autoscaling with a minimum, a maximum, and a target CPU. There are no per-seat fees and no surprise bandwidth charges, so scaling up stays predictable.

Wrap-up

A Django project reaches production on ComputeSphere in one command: read settings from the environment, containerize with Gunicorn, and run csph deploy. You get HTTPS, migrations, custom domains, and autoscaling — no Kubernetes and no DevOps team.

Ready to ship? Start your free trial or book a 15-minute demo.

Predictable cloud, from your first push.

Fixed price per spherelet, flat plan per team — ship without DevOps or surprise bills.

Start free trial

14-day free trial

Share this article

Ship your next service on ComputeSphere

Predictable per-spherelet pricing, a flat plan per team, and managed primitives built in — no DevOps, no surprise bills.

Deploy your first spherelet in minutes.

Connect a repo or start from a template — live URL, SSL, and zero DevOps, on predictable per-spherelet pricing. 14-day free trial.