DEV Community: Navdeep Rana

Scale Django on Seenode: Production Architecture That Actually Works

Navdeep Rana — Sun, 16 Nov 2025 13:08:36 +0000

Advanced scaling patterns for Django apps - from 100 to 100K requests/day

Last year I pushed 18 app versions with staging endpoints hardcoded into production. Residents across the UK couldn't unlock their hotel rooms via NFC. My PM couldn't log in. That was a frontend disaster, but it taught me something: deployment F-ups scale with complexity.

Django backend scaling is the same energy - you can't just throw more Gunicorn workers at it and pray. I learned this the hard way when a payments API I built started choking at 2,000 req/min. Tea break interrupted at 11am by a Slack ping: "Checkout timing out, users complaining." I ssh'd in, watched workers dying one by one, and realized our monolith was the problem.

This article covers what actually worked when I migrated that payments system to Seenode and scaled it to 50K+ requests/day without melting down. No theory, just the architecture patterns that kept me sleeping through the night.

You'll learn:

Why splitting web/worker services matters (and how to do it on Seenode)
Database connection pooling that actually prevents "too many connections" errors
Redis caching patterns worth implementing
Real cost considerations when scaling

Prerequisites:

Django app deployed on Seenode (see my production deployment guide)
Basic understanding of Django, PostgreSQL, Celery
Seenode account (sign up at cloud.seenode.com with a 7-day free trial)

Read time: 10 minutes

Level: Advanced (assumes you've deployed Django before)

Why Monoliths Break at Scale

Most Django apps start simple: one Gunicorn process handling HTTP requests and background tasks via @shared_task decorators. This works great until it doesn't.

The breaking point? When a slow task (PDF generation, sending emails) ties up a worker and your API requests start queuing. Or when 20 Gunicorn workers x 5 DB connections hits PostgreSQL's 100-connection limit. I've debugged both, multiple times.

The fix isn't bigger servers. It's splitting web and worker services so they scale independently. Seenode makes this easy—same Git repo, different start commands.

The Multi-Service Architecture

Here's how I structure Django apps on Seenode—three services, one Git repo:

1. Web Service (Gunicorn) - handles HTTP only, scales horizontally

2. Worker Service (Celery) - background jobs, scales for throughput

3. Scheduler Service (Celery Beat) - cron jobs, runs once

Plus PostgreSQL (managed by Seenode) and Redis (external provider required).

Each service uses the same codebase but different start commands. Seenode's dashboard lets you configure all three pointing to the same GitHub repo—just change the startup script.

Service 1: Web Service (Gunicorn)

Seenode web service configuration showing Gunicorn start command with workers and threads. The $PORT variable is automatically provided by Seenode.

Your Seenode web service start command:

gunicorn config.wsgi:application --bind 0.0.0.0:$PORT --workers 4 --threads 2 --timeout 30 --max-requests 1000 --max-requests-jitter 100

Key settings explained:

--workers 4 - Use (2 x CPU) + 1. More workers != better performance.

--threads 2 - Handles concurrent DB queries without exploding connection count.

--max-requests 1000 - Restarts workers to prevent memory leaks. Learned this after watching memory climb to 95% over 3 days.

--timeout 30 - Kills hung requests. Saved me when a payment provider's API started timing out.

On a properly configured instance, this handles 2,000 req/min with p95 response time around 180ms.

I tried running 8 workers on a smaller instance once. Thought more workers = better performance. Nope. Hit OOM errors within 2 hours. Turns out the formula (2 x CPU) + 1 exists for a reason.

Set these environment variables in Seenode's dashboard:

GUNICORN_WORKERS=4
GUNICORN_THREADS=2

Service 2: Celery Workers (Background Jobs)

Seenode worker service start command:

celery -A config worker --loglevel=info --concurrency=4 --max-tasks-per-child=1000 --time-limit=300

Celery config (config/celery.py):

import os
from celery import Celery

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'config.settings')
app = Celery('myproject')

app.config_from_object('django.conf:settings', namespace='CELERY')
app.autodiscover_tasks()

app.conf.update(
    broker_url=os.environ.get('REDIS_URL', 'redis://localhost:6379/0'),
    result_backend=os.environ.get('REDIS_URL'),
    task_serializer='json',
    task_time_limit=300,  # 5 min hard limit (prevent stuck tasks)
    task_acks_late=True,  # Only ack after completion
    worker_prefetch_multiplier=1,  # One task at a time for long operations
    result_expires=3600,  # Results expire after 1 hour
)

Example task:

# myapp/tasks.py
from celery import shared_task
from django.core.mail import send_mail

@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def send_welcome_email(self, user_id):
    try:
        from myapp.models import User
        user = User.objects.get(id=user_id)
        send_mail(
            subject='Welcome!',
            message=f'Hi {user.first_name}!',
            from_email='noreply@myapp.com',
            recipient_list=[user.email],
        )
        return {'status': 'sent'}
    except Exception as exc:
        raise self.retry(exc=exc)

Call from views:

# Queue background task (returns immediately)
send_welcome_email.delay(user.id)

I started with --concurrency=4. When queue backed up during Black Friday, scaled to 5 worker instances via Seenode's dashboard. Took 30 seconds, queue cleared in 2 minutes.

Service 3: Celery Beat (Scheduler)

Run periodic tasks on a schedule. Start command:

celery -A config beat --loglevel=info --scheduler django_celery_beat.schedulers:DatabaseScheduler

Install django-celery-beat, add to INSTALLED_APPS, run migrations. Define schedules:

# config/celery.py
from celery.schedules import crontab

app.conf.beat_schedule = {
    'cleanup-sessions-daily': {
        'task': 'myapp.tasks.cleanup_old_sessions',
        'schedule': crontab(hour=2, minute=0),  # 2 AM daily
    },
    'check-payment-status': {
        'task': 'myapp.tasks.check_payment_status',
        'schedule': 300.0,  # Every 5 min
    },
}

Or manage via Django admin—no code deployments needed to change schedules.

Critical: Run ONLY ONE Beat instance. Multiple schedulers = duplicate tasks.

Horizontal Scaling & Database Connection Pooling

Seenode automatically handles load balancing and scaling. But your app needs to be stateless—no file uploads on local disk, no in-memory sessions.

Redis Sessions (Required for Multi-Instance)

# settings.py
# pip install django-redis

CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': os.environ.get('REDIS_URL', 'redis://127.0.0.1:6379/1'),
        'OPTIONS': {
            'CLIENT_CLASS': 'django_redis.client.DefaultClient',
            'CONNECTION_POOL_KWARGS': {'max_connections': 50},
        },
        'KEY_PREFIX': 'myapp',
        'TIMEOUT': 300,
    }
}

SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
SESSION_CACHE_ALIAS = 'default'

Set REDIS_URL in Seenode environment variables. You'll need to use an external Redis provider (Seenode does not offer managed Redis).

Media Files on S3

File uploads disappear when you scale or redeploy. Use S3:

# pip install django-storages boto3
INSTALLED_APPS += ['storages']
DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'

AWS_ACCESS_KEY_ID = os.environ.get('AWS_ACCESS_KEY_ID')
AWS_SECRET_ACCESS_KEY = os.environ.get('AWS_SECRET_ACCESS_KEY')
AWS_STORAGE_BUCKET_NAME = os.environ.get('AWS_STORAGE_BUCKET_NAME')

Database Connection Pooling (Critical)

With multiple instances, connections explode:

Example: 3 web instances x 4 workers x 5 connections = 60. Add 2 Celery services and you hit PostgreSQL's 100-connection limit. This is the math that breaks things.

I once spent a Saturday debugging "too many connections" errors. Math was simple: 6 services x 5 connections = 30, but max_connections was set to 20. Increased to 50, problem solved.

Enable connection pooling:

# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'CONN_MAX_AGE': 600,  # Keep connections alive 10 minutes
        'OPTIONS': {
            'connect_timeout': 10,
            'options': '-c statement_timeout=30000',
        },
    }
}

# For Celery workers, close connections immediately
if os.environ.get('CELERY_WORKER'):
    DATABASES['default']['CONN_MAX_AGE'] = 0

Check Seenode's PostgreSQL docs for PgBouncer if needed for higher connection counts.

Caching: The Cheap Performance Win

Database queries kill performance. Caching is the easiest fix.

View-Level Caching

from django.views.decorators.cache import cache_page

@cache_page(300)  # 5 minutes
def product_list(request):
    products = Product.objects.filter(active=True)
    return render(request, 'products/list.html', {'products': products})

Query-Level Caching

from django.core.cache import cache

def get_popular_products(limit=10):
    cache_key = f'popular_products_{limit}'
    products = cache.get(cache_key)

    if products is None:
        products = Product.objects.filter(active=True).annotate(
            order_count=Count('orders')
        ).order_by('-order_count')[:limit]
        cache.set(cache_key, products, 600)  # 10 min

    return products

Cache Invalidation

First time I implemented caching, I forgot to invalidate on updates. Users saw prices from 3 days ago. Customer support got hammered. The fix? One cache.delete() call. Cost of mistake: $2,000 in lost sales. Cost of fix: 2 lines of code.

# myapp/models.py
from django.db.models.signals import post_save, post_delete
from django.dispatch import receiver
from django.core.cache import cache

@receiver([post_save, post_delete], sender=Product)
def invalidate_product_cache(sender, instance, **kwargs):
    cache.delete(f'product_{instance.id}')
    cache.delete('popular_products_10')

Performance Monitoring

Seenode has built-in metrics, but you need to know what broke.

Django Debug Toolbar (Dev Only)

# settings.py
if DEBUG:
    INSTALLED_APPS += ['debug_toolbar']
    MIDDLEWARE += ['debug_toolbar.middleware.DebugToolbarMiddleware']

Shows SQL queries, cache hits/misses. Use it to find N+1 query problems.

Seenode Metrics (What to Watch)

CPU >80% sustained = scale up or optimize
Memory >85% = memory leak or need more RAM
Response time p95 >500ms = investigate slow endpoints

I keep the Seenode metrics tab pinned. Saw CPU spike to 95% every day at 2pm. Took a week to realize it was daily report generation. Moved to dedicated worker, CPU dropped to 40%.

Database Optimization

Fix N+1 Queries

# BAD: N+1 query problem
products = Product.objects.filter(active=True)
for product in products:
    print(product.category.name)  # Separate query each time!

# GOOD: Use select_related for foreign keys
products = Product.objects.filter(active=True).select_related('category')

# GOOD: Use prefetch_related for many-to-many
products = Product.objects.filter(active=True).prefetch_related('tags')

Add Database Indexes

Add indexes on frequently queried fields:

class Meta:
    indexes = [
        models.Index(fields=['category', 'active']),
        models.Index(fields=['-created_at']),
    ]

Cost Management

Scaling costs increased faster than expected. What kept costs reasonable:

Start small, scale on metrics - Don't over-provision. I started with 1 web instance on the Basic tier ($3/mo), scaled up when CPU hit 85%. Seenode offers four pricing tiers: Basic ($3/mo, 0.5 GB RAM, 0.2 CPU), Standard ($6/mo, 1 GB RAM, 0.5 CPU), Pro ($12/mo, 2 GB RAM, 1.0 CPU), and Ultra ($24/mo, 4 GB RAM, 2.0 CPU). You can upgrade or downgrade anytime based on your needs.

Optimize before scaling - Profile with Debug Toolbar, fix N+1 queries, add indexes, enable caching. Then scale if needed.

Scale workers independently - Workers are cheaper than web instances. Add worker capacity without scaling entire web service.

Caching ROI - Caching saved ~$100/mo in database costs by reducing query load 60%.

Troubleshooting (The Usual Suspects)

"Too Many Database Connections"

Simple math problem: 6 services x 5 connections = 30, but max_connections was 20. Fix: Increase max_connections or use PgBouncer. For Celery workers, close connections immediately:

DATABASES['default']['CONN_MAX_AGE'] = 0 if os.environ.get('CELERY_WORKER') else 600

Redis Out of Memory

Set TTLs on everything. Celery results don't need to live forever: CELERY_RESULT_EXPIRES = 3600 (1 hour, not 24h).

Celery Queue Backing Up

Workers can't keep up. Add more worker instances or route slow tasks to separate queues:

CELERY_TASK_ROUTES = {
    'myapp.tasks.slow_report': {'queue': 'slow'},
    'myapp.tasks.fast_email': {'queue': 'fast'},
}

Things I Wish I Knew About Scaling on Seenode

Connection pooling isn't optional—learned this at 3am when PostgreSQL started rejecting connections during a sale. You'll hit the limit fast.
Celery workers need separate services, not the web service. Tried running both in one process. Don't.
Redis is cheap insurance ($10/mo saves $100/mo in DB costs). Skip it and you'll pay later.
Profile before scaling—I wasted $200/mo on instances when the fix was a missing index. Debug Toolbar is your friend.
Seenode logs rotate fast. Ship to external storage or lose debugging info when you need it most.
Scaling is automatic but can be addictive. Scale on metrics, not fear. I've over-provisioned more times than I'll admit.

Conclusion

Scaling Django on Seenode isn't about manual scaling controls. It's architecture: split services (web/worker/beat), cache aggressively, fix N+1 queries, enable connection pooling.

This multi-service pattern works. I've used it to scale from 2K to 50K+ requests/day without melting down. It's boring, proven, and lets you sleep.

If you're ssh'd into production restarting Gunicorn manually, this is your escape route.

Questions? Drop them in comments. I actually respond.

Related:

Next: Django REST API deployment with JWT and rate limiting. Publishing next week.

Advanced Django Deployment on Seenode: Production-Ready Strategies for 2025

Navdeep Rana — Sat, 15 Nov 2025 08:26:42 +0000

I’m Navdeep. I’ve been deploying Django apps since 2014, back when we ssh’d into bare-metal boxes and ran git pull by hand (yes, really). Last month I migrated a client’s analytics tool to Seenode and hit the greatest hits of prod pain: connection pools melting down, static files mysteriously 404ing, and a DEBUG=True scare at 2 a.m. If you’ve ever whispered “just one last manual migration” before pushing to prod, consider this an intervention.

What follows is the messy, opinionated playbook I’ve been carving out for years—the same advice I end up whiteboarding for mentees after we spend three hours chasing a missing comma in WhiteNoiseMiddleware. Screenshots come straight from my live Seenode project so you can copy the setup without guessing, and I’ve left in the false starts (because that’s what real deployments look like).

Zero-patience TL;DR

Harden settings.py, enable conn pooling, and treat env vars like explosives.
Split web/worker/scheduler services; autoscale workers instead of overloading Gunicorn.
Automate deploys via Seenode’s API so every push ships with guardrails.

I kicked this migration off on Seenode’s 7-day free trial, started the web service on the Basic tier (~$3/mo), and only stepped up through Standard/Pro to Ultra (~$24/mo) when metrics proved we needed the headroom. Managed PostgreSQL mirrored that journey: the entry-level tier handled smoke tests, mid-tier covered beta, and Tier 4 (~$20/mo) became home once analytics jobs started hammering the cluster. Every database tier ships with 14 days of metrics plus both private and public connection hostnames, so I kept workers on the private network while BI tools hit the public endpoint.

Why Production Deployment is Different

The Seenode docs get you live in five minutes, which is perfect for demos. Production? That’s where the sharp edges live:

Security hardening: Protecting against common vulnerabilities
Performance optimization: Handling real traffic efficiently
Reliability: Ensuring your app stays online during deployments
Monitoring: Knowing what's happening when things go wrong
Scalability: Preparing for growth from day one

Seenode’s Git-based workflow takes care of the boring bits, but you still have to dial in Django itself. I’m allergic to slow builds or sluggish endpoints—if something feels laggy, I rebuild it. Everything below comes from the live project you’ll see in the screenshots, warts and all.

Production-Ready Settings Configuration

I usually harden settings.py before touching anything else. If that file is sloppy, everything downstream is shaky—security, performance, even observability.

Security First: Environment Variables

# settings.py
import os
import dj_database_url
from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent

# SECURITY: Never commit SECRET_KEY to version control
# Seenode lets you manage these values in the dashboard’s Environment tab
SECRET_KEY = os.environ.get('SECRET_KEY')
if not SECRET_KEY:
    raise ValueError("SECRET_KEY environment variable is required in production")

# DEBUG: Always False in production
# Using .lower() handles various formats: "false", "False", "FALSE"
DEBUG = os.environ.get('DEBUG', 'False').lower() == 'true'

# ALLOWED_HOSTS: Prevents HTTP Host header attacks
# Format in Seenode env vars: "yourdomain.com,www.yourdomain.com,api.yourdomain.com"
ALLOWED_HOSTS = [
    host.strip() 
    for host in os.environ.get('ALLOWED_HOSTS', '').split(',') 
    if host.strip()
]

# If ALLOWED_HOSTS is empty, add a fallback for the generated *.seenode.app host
if not ALLOWED_HOSTS and not DEBUG:
    # You'll want to set this explicitly in production
    ALLOWED_HOSTS = ['*']  # Temporary - set your actual domain!

I’ve personally watched a production app fall over because someone left ALLOWED_HOSTS empty. Set it explicitly and fail loudly if it’s missing.

Database Configuration with Connection Pooling

The default dj-database-url configuration works, but production apps need connection pooling to handle concurrent requests efficiently:

# Database configuration optimized for production
DATABASES = {
    'default': dj_database_url.config(
        conn_max_age=600,  # Keep connections alive for 10 minutes
        conn_health_checks=True,  # Verify connections before use
        ssl_require=True,  # Force SSL for security
    )
}

# Connection pool settings (if using PostgreSQL)
# These prevent "too many connections" errors under load
if 'postgres' in DATABASES['default']['ENGINE']:
    DATABASES['default']['OPTIONS'] = {
        'connect_timeout': 10,
        'options': '-c statement_timeout=30000',  # 30 second query timeout
    }

On the analytics project I mentioned, median response time dropped from ~340 ms to 180 ms after enabling conn_max_age=600. Not a lab-grade benchmark, but enough proof for the product team to stop blaming PostgreSQL.

Static Files: WhiteNoise Configuration

WhiteNoise is excellent for serving static files, but the default configuration isn't optimized for production:

# Static files configuration
STATIC_URL = '/static/'
STATIC_ROOT = BASE_DIR / 'staticfiles'

# WhiteNoise configuration for production
# Add this to MIDDLEWARE (before SecurityMiddleware if present)
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware',  # Add this
    # ... other middleware
]

# WhiteNoise storage with compression
STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

# Cache static files for 1 year (browsers will cache)
WHITENOISE_MAX_AGE = 31536000  # 1 year in seconds

Pro tip: The CompressedManifestStaticFilesStorage automatically gzips your static files, reducing bandwidth by 60-80%. This is especially important for JavaScript bundles and CSS files.

UPDATE (credit to Priya from our platform team): My earlier draft recommended ManifestStaticFilesStorage alone. She pointed out it breaks cache busting when you deploy frequently. Swapping to CompressedManifestStaticFilesStorage solved the stale asset issue instantly, so now it’s the default in every project I touch.

Security Headers and CORS

For APIs or apps with separate frontends, you'll need CORS configuration:

# Install: pip install django-cors-headers

INSTALLED_APPS = [
    # ... other apps
    'corsheaders',
]

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'corsheaders.middleware.CorsMiddleware',  # Should be near the top
    # ... other middleware
]

# CORS configuration for production
CORS_ALLOWED_ORIGINS = [
    origin.strip() 
    for origin in os.environ.get('CORS_ALLOWED_ORIGINS', '').split(',')
    if origin.strip()
]

# Security headers
SECURE_BROWSER_XSS_FILTER = True
SECURE_CONTENT_TYPE_NOSNIFF = True
X_FRAME_OPTIONS = 'DENY'  # Prevent clickjacking

# If you're using HTTPS (which Seenode provides automatically)
if not DEBUG:
    SECURE_SSL_REDIRECT = True
    SESSION_COOKIE_SECURE = True
    CSRF_COOKIE_SECURE = True

Service-to-Service Secrets and Rotation

Environment variables are a good start, but production organizations need stronger guardrails:

Scoped secrets: Configure environment variables per service when possible. Keep worker-only credentials out of the public web container.
Rotation playbook: Add SECRET_KEY_V2, deploy, verify, then remove SECRET_KEY_V1. Document the process so any engineer can rotate in minutes.
Least privilege databases: Create a separate PostgreSQL user for Celery or analytics jobs with read-only grants, and point DATABASE_URL to that user from each service.
CI pipelines: If you deploy via GitHub Actions, reference repository secrets and pass them as workflow inputs. Never echo secrets in logs.

This layered approach prevents the all-too-common scenario where someone inadvertently leaks production credentials during debugging or screen sharing.

Personal scar: Last year a teammate dumped os.environ while debugging and our DATABASE_URL ended up in plain text in the logs. We spent four hours rotating everything. Now we have this playbook, and I quiz people on it during their first week.

Gunicorn Configuration for Production

The basic Gunicorn command works, but production deployments need proper worker configuration. Create a gunicorn_config.py:

# gunicorn_config.py
import multiprocessing
import os

# Server socket
# IMPORTANT: Configure this port in the Seenode dashboard (there is no default port)
# The load balancer proxies from ports 80/443 to your configured container port
bind = "0.0.0.0:80"  # Set this to match the port you configure in Seenode dashboard
backlog = 2048

# Worker processes
# Formula: (2 x CPU cores) + 1
workers = int(os.environ.get('GUNICORN_WORKERS', multiprocessing.cpu_count() * 2 + 1))
worker_class = 'sync'  # Use 'gevent' or 'uvicorn.workers.UvicornWorker' for async
worker_connections = 1000
timeout = 30  # 30 seconds - adjust based on your longest request
keepalive = 2

# Logging
accesslog = '-'  # Log to stdout (Seenode captures this)
errorlog = '-'   # Log to stderr
loglevel = 'info'
access_log_format = '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s" %(D)s'

# Process naming
proc_name = 'django_app'

# Server mechanics
daemon = False
pidfile = None
umask = 0
user = None
group = None
tmp_upload_dir = None

# Graceful timeout for worker restarts
graceful_timeout = 30

Point your Seenode start command at that config:

gunicorn your_project.wsgi:application --config gunicorn_config.py

Too few workers and your app chokes on concurrent requests; too many and you’ll OOM the box. I once “optimized” by setting workers to cpu_count() * 4 and spent the next day chasing memory leaks. More isn’t better—start with (2 * cores) + 1, watch metrics, then adjust.

Advanced Build Script

The basic build.sh works, but here's a production-ready version with error handling:

#!/usr/bin/env bash
set -o errexit  # Exit on any error
set -o nounset  # Exit on undefined variables
set -o pipefail # Exit on pipe failures

echo "Starting build process..."

# Install dependencies
echo "Installing Python dependencies..."
pip install --upgrade pip
pip install -r requirements.txt

# Run database migrations
echo "Running database migrations..."
python manage.py migrate --no-input

# Collect static files
echo "Collecting static files..."
python manage.py collectstatic --no-input --clear

# Verify critical environment variables
if [ -z "$SECRET_KEY" ]; then
    echo "ERROR: SECRET_KEY not set"
    exit 1
fi

echo "Build completed successfully!"

Key improvements:

--clear flag removes old static files before collecting new ones
Error checking prevents silent failures
Verbose output helps debug deployment issues

I’m notoriously impatient with repetitive toil. I once spent five hours writing automation just to reclaim a 30-minute weekly deployment chore, and I’d do it again. If a build step slows me down, I script it, commit it, and move on—that mindset is baked into this build.sh.

Successful Seenode build pipeline: dependency install, migrations, collectstatic, and verification.

Environment Variables Setup in Seenode

In the Seenode dashboard, configure these environment variables:

Required:

SECRET_KEY=your-super-secret-key-here-generate-with-openssl-rand-hex-32
DEBUG=False
ALLOWED_HOSTS=yourdomain.com,www.yourdomain.com
DATABASE_URL=postgresql://user:pass@host:5432/dbname

Recommended for production:

GUNICORN_WORKERS=4
CORS_ALLOWED_ORIGINS=https://yourfrontend.com,https://www.yourfrontend.com

Security tip: Generate a strong SECRET_KEY using:

python -c "import secrets; print(secrets.token_urlsafe(50))"

The niceties matter: custom domains were just a CNAME away, automatic HTTPS/HTTP/2 (plus WebSocket support) meant I never touched Certbot, and the runtime log stream + env-var editor in the dashboard saved me from emergency redeploys. On the one weekend when I did need help, 24/7 support actually responded inside an hour.

Triggering Deployments from CI

Seenode’s docs include end-to-end guides for GitHub Actions and GitLab CI/CD. Follow those workflows to:

Store your SEENODE_API_TOKEN as an encrypted secret
Call the official deployment action once tests pass
Monitor the deployment from the dashboard’s Deployments tab

That approach keeps your pipeline supported and avoids guessing undocumented API endpoints.

Multi-Service Architecture on Seenode

Most production Django apps rely on more than a single web process. Seenode issues both public URLs and internal hostnames (see the port configuration guide’s http://web-abcdefgh-service example), so services can talk over the private network without extra wiring.

Web, Worker, and Scheduler Split

Spin up three services from the same repository:

Web: Runs Gunicorn and exposes port 80.
Worker: Runs Celery/RQ with celery -A your_project worker -l info and no public port.
Scheduler: Runs celery -A your_project beat or python manage.py crontab run.

All of them share the same managed PostgreSQL database plus whatever Redis provider you configure, but only the web service is accessible publicly.

Background Jobs with Celery on Seenode

# Start command for worker service
celery -A your_project worker --loglevel=info --autoscale=8,2

# Start command for scheduler service
celery -A your_project beat --loglevel=info

Tune autoscale parameters to match Seenode’s CPU allocation, and remember to set CELERY_BROKER_URL/CELERY_RESULT_BACKEND in the worker’s environment variables.

~I tried running the workers inside the web service to “save resources.”~ Don’t do that. Separate services keep crashes isolated and make it easier to scale the noisy neighbors independently.

Database Optimization for Analytics

If analytics queries pile up, consider optimizing your database strategy. Depending on your database provider's capabilities, you might:

Use database connection pooling to handle concurrent read queries efficiently
Optimize queries with proper indexing and select_related/prefetch_related
Consider separating read-heavy workloads if your database provider supports read replicas or similar features
Use caching layers (Redis, Memcached) to reduce database load for frequently accessed data

Always check your database provider's documentation for supported scaling and replication options.

Shared Media and CDN Layer

Use django-storages with an S3-compatible provider (Wasabi, Backblaze, or Cloudflare R2). Point MEDIA_URL at a CDN (Cloudflare or Fastly) so static assets never touch your dynos, and configure cache invalidation via webhook when you deploy.

Whenever I onboard a junior developer, this is the architecture diagram we whiteboard first. Once they see how the pieces talk inside Seenode’s private network, everything else—logs, metrics, secret rotation—suddenly clicks. Sharing those “aha!” moments is honestly my favorite part of the job.

Troubleshooting Common Production Issues

Issue 1: 502 Bad Gateway

Symptom: Your app shows "502 Bad Gateway" after deployment.

Cause: Port binding mismatch. Your application must listen on the port you configured in the Seenode dashboard. The load balancer proxies from ports 80/443 to your configured container port.

Solution:

Check your Gunicorn bind address matches the port you set in Seenode dashboard (e.g., bind = "0.0.0.0:80" if you configured port 80)
Verify the Port field in Seenode dashboard is set to match your application's bind port (not left empty - there is no default)
Check logs: gunicorn should show "Listening at: http://0.0.0.0:[YOUR_PORT]"

Issue 2: Database Connection Timeouts

Symptom: Intermittent "OperationalError: could not connect to server" errors.

Cause: Too many database connections or connection pool exhaustion.

Solution:

# In settings.py, add connection limits
DATABASES['default']['CONN_MAX_AGE'] = 600  # Reuse connections
DATABASES['default']['OPTIONS'] = {
    'connect_timeout': 10,
}

Also, ensure your worker count doesn't exceed available database connections. If you have 10 workers and each opens 2 connections, you need at least 20 available connections in your PostgreSQL instance.

Issue 3: Static Files Not Loading

Symptom: CSS/JS files return 404 errors.

Cause: Static files weren't collected during build, or WhiteNoise isn't configured correctly.

Solution:

Verify collectstatic runs in build.sh
Check STATIC_ROOT path is correct
Ensure WhiteNoiseMiddleware is in MIDDLEWARE (before other middleware that might handle static files)
Check STATICFILES_STORAGE is set correctly

Issue 4: Memory Issues

Symptom: App crashes or becomes unresponsive under load.

Cause: Too many Gunicorn workers consuming too much memory.

Solution: Calculate optimal worker count based on available memory:

# In gunicorn_config.py
import multiprocessing
import psutil

# Calculate workers based on available memory
# Assume ~100MB per worker (adjust based on your app)
available_memory = psutil.virtual_memory().available / (1024 * 1024)  # MB
memory_per_worker = 100  # MB
max_workers_by_memory = int(available_memory / memory_per_worker)
cpu_workers = multiprocessing.cpu_count() * 2 + 1

workers = min(cpu_workers, max_workers_by_memory)

Issue 5: Secrets Logged Accidentally

Symptom: SECRET_KEY, access tokens, or database URLs show up in logs.

Cause: Debug statements (print(os.environ)) or overly verbose log levels.

Solution:

Add a log filter:

   class SensitiveFilter(logging.Filter):
       def filter(self, record):
           for secret_name in ['SECRET_KEY', 'DATABASE_URL']:
               secret_value = os.environ.get(secret_name)
               if secret_value:
                   record.msg = record.msg.replace(secret_value, '[REDACTED]')
           return True

Attach the filter to every handler in LOGGING.
Rotate the affected credentials immediately if exposure occurred.

Security Checklist for Production

Before going live, verify:

DEBUG = False (check environment variable)
SECRET_KEY is set and strong (50+ characters)
ALLOWED_HOSTS includes your domain (no wildcards in production)
Database uses SSL (ssl_require=True)
CSRF and session cookies are secure (CSRF_COOKIE_SECURE, SESSION_COOKIE_SECURE)
Security headers are configured (X_FRAME_OPTIONS, SECURE_CONTENT_TYPE_NOSNIFF)
CORS is configured (if needed) with specific origins, not *
No sensitive data in logs (filter out passwords, tokens, etc.)
Database credentials are in environment variables, not code
Static files are served securely (WhiteNoise handles this)

Performance Optimization Tips

Enable database query logging in development to find N+1 queries:

   if DEBUG:
       LOGGING = {
           'version': 1,
           'handlers': {
               'console': {
                   'class': 'logging.StreamHandler',
               },
           },
           'loggers': {
               'django.db.backends': {
                   'level': 'DEBUG',
               },
           },
       }

Use select_related and prefetch_related to reduce database queries
Enable database connection pooling (already covered above)
Monitor response times using your platform's monitoring tools and logs
Set appropriate cache headers for API responses that don't change frequently

Anything above ~200 ms median latency makes me twitchy, so I keep the monitoring dashboards and Grafana dashboards pinned. The moment p95 creeps north, we profile queries or drop a cache layer—no “we’ll fix it later” excuses.

Things I Wish Someone Told Me About Seenode + Django

There is no default port. You must configure the port in the Seenode dashboard, and your app must bind to that same port. The load balancer routes from 80/443 to your configured container port.
collectstatic --clear feels optional until stale assets haunt you—run it every time.
Connection pooling (conn_max_age) buys you real latency wins without touching code.
Start with the lowest tier that works for testing, but budget for scaling the moment real traffic enters.
Logs may have retention limits depending on your plan; consider piping them to external storage if you need long-term debugging access.

Zero-Downtime Deployments and Rollbacks

Production outages usually stem from rushed deploys. Build a boring release pipeline:

Pre-flight checks

   python manage.py check --deploy
   python manage.py test --tag=smoke

Run these in CI and fail the build on any error.

Staged rollouts
- Deploy to a staging environment first, validate metrics/logs.
- Use feature flags to gradually expose changes to production.
- Monitor closely after each deployment increment.
Rollback strategy
- Keep a ROLLBACK.md doc with exact commands for reverting to a previous Git SHA.
- Document how to revert migrations (python manage.py migrate app 0010_previous).
- Test your rollback process in staging before you need it in production.
Feature flags
- Use LaunchDarkly, Flagsmith, or an open-source alternative to gradually expose risky changes without redeploying.

Practice these steps during calm periods so they’re muscle memory during incidents.

Whenever I learn a smoother rollback trick, I hop on a call with my mentees and walk them through it step by step. Half the fun of discovering a better deployment dodge is geeking out about it with people who’ll use it next week.

Next Steps

Now that your Django app is production-ready on Seenode, the next challenge is scaling it. In my next article, I'll cover:

Architecture patterns for multi-service Django apps
Database optimization strategies for PostgreSQL on Seenode
Caching strategies to reduce database load
Background worker configuration for async tasks
Performance monitoring and alerting setup

Part 2 drops within the next 24 hours—Git-based scaling deep dive, with workers, read replicas, the works. I’ll link it here as soon as it’s live so you don’t have to hunt for it.

Conclusion

Deploying Django to production on Seenode is straightforward, but production-ready deployments require attention to security, performance, and reliability. The configurations I've shared here are based on real-world deployments and will help you avoid common pitfalls.

If anything here sparks an idea, ping me. I’m the person who can talk for hours about rollout strategies over chai, especially if it means a junior dev can skip the headaches I’ve already collected.

The key takeaway: Don't just make it work—make it work securely, efficiently, and reliably. Your users (and your future self) will thank you.

Ready to deploy? Sign up for Seenode and put these strategies into practice. The Git-based workflow makes iterating on these configurations easy—just push to your repository and watch it deploy automatically.

Have questions or run into issues? Drop a comment below, and I'll help you troubleshoot.

Want to learn more about Django deployment? Check out the Seenode Django documentation or explore Seenode's pricing for your production needs.