Are you a startup founder sweating over how to get your Django app live and handling 100 users without breaking the bank or a researcher curious about real-world deployment trade-offs? You’re not alone. Scaling a web app from scratch to production is a high-stakes puzzle: one wrong move, and your users bounce, your costs skyrocket, or your server crashes mid-demo. I recently tackled this exact challenge, building a Django app, deploying it to an AWS EC2 instance with an RDS database, and optimizing it for 100 concurrent users, all without Docker. Here’s the playbook, plus some insider math on costs and concurrency that’ll make you the hero of your next board meeting.
Step 1: Bootstrapping Your Django App
First, you need a solid foundation. Start locally with Python 3, a virtual environment, and Django installed (pip install django). Spin up a project (django-admin startproject myproject) and an app (python manage.py startapp myapp). Add a simple model—say, an Item with a name and timestamp—then wire up a view to create items and test it at http://127.0.0.1:8000. It’s barebones, but it’s your Minimum Viable Product (MVP).
Pro tip: Keep it lean. Every line of code you write now impacts scaling later.
Step 2: Prepping for the Big Leagues
Production isn’t localhost. Install Gunicorn (pip install gunicorn) for a WSGI server and psycopg2-binary for PostgreSQL. Tweak settings.py: set DEBUG = False, define ALLOWED_HOSTS, and prep static files with STATIC_ROOT. Collect those files (python manage.py collectstatic) and freeze your dependencies (pip freeze > requirements.txt). This is your app, battle-ready.
Step 3: AWS Setup—EC2 and RDS
Now, the cloud. Launch a t2.medium EC2 instance (2 vCPUs, 4 GiB RAM) on Ubuntu 22.04—costing ~$33.87/month On-Demand in US East. Why t2.medium? It’s burstable, meaning it handles traffic spikes for your 100 users without needing a pricier instance upfront. Pair it with an RDS PostgreSQL instance (e.g., db.t3.micro, ~$0.017/hour or $12.41/month Free Tier-eligible). Configure security groups: SSH (22) for you, HTTP (80) for the world, and 5432 for EC2-to-RDS chatter.
Step 4: Deployment—Systemd, Not Docker
Upload your app to EC2 via scp, set up a virtualenv, and install requirements. Connect to RDS by updating settings.py with the endpoint and credentials, then migrate (python manage.py migrate). Here’s where it gets startup-smart: instead of Docker, run Gunicorn as a systemd service. Create /etc/systemd/system/gunicorn.service with 5 workers (–workers 5), binding to a Unix socket. Enable it (sudo systemctl enable gunicorn), and let systemd handle restarts. Top it off with Nginx as a reverse proxy—cheap, fast, and production-grade.
Step 5: Scaling to 100 Users—Workers and Pooling
Here’s the million-dollar question: Can it handle 100 concurrent users? Let’s break it down.
Gunicorn Workers vs. Concurrency
Each worker handles one request at a time. With 5 workers on a t2.medium (2 vCPUs × 2 + 1), you get ~50 requests per second (RPS) if responses take 100 ms. For 100 users, if they request every 2 seconds, that’s 50 RPS—perfect fit. Spike to 100 RPS? You might need faster responses or a t3.large. Test it with ab -n 100 -c 100 and tweak workers based on your app’s load.
Why Database Pooling Matters
Without pooling, 100 users could open 100 RDS connections, crashing a small instance (default limit: ~100–200). Each connection eats ~10 MB, so 100 = 1 GB—goodbye, db.t3.micro. Pooling (e.g., 10–20 connections via PgBouncer or django-db-connection-pool) reuses connections, slashing latency and keeping RDS happy. It’s not optional—it’s your scalability lifeline.
Cost Breakdown
- EC2 t2.medium: ~$33.87/month.
- RDS db.t3.micro: ~$12.41/month (or free tier).
- Total: ~$46.28/month. For 100 users, that’s $0.46/user—pennies for a proof-of-concept that scales.
Why This Matters to You
Startups: This setup gets your MVP live fast, cheap, and ready for investors. No over-engineered Docker clusters—just a lean, systemd-powered stack you can pitch as “enterprise-ready.” Researchers: It’s a reproducible blueprint to study concurrency, cost-efficiency, or cloud trade-offs. Tweak workers, pool sizes, or instance types, and you’ve got an MVP in the cloud.
Ready to Scale Smarter?
Deploying Django to AWS isn’t rocket science—it’s decision science. Nail the worker-to-user ratio, pool your database, and keep costs low, and you’ll go from zero to 100 users without a sweat. Want to chat about your app’s specifics or optimize further? Drop me a line—I’m all about turning ideas into scalable reality.
Contact me at sammy@djangoconsultants.net for a free consultation!
