Contents
After years of hosting Django in production — on DigitalOcean, on AWS ECS, behind CloudFront, Cloudflare, and Bunny — my honest answer to “where should I host Django?” is this: the platform matters less than you think, and the seams matter more. Keep every vendor behind environment variables, treat egress as a first class cost from day one, and start simpler than your ego wants to. This post is the journey that taught me each of those lessons, with the real bills attached.
Most “my hosting journey” posts are a tour of vendor landing pages. This one is the actual sequence of decisions and migrations behind two production systems: a veterinary clinic platform that has run since 2019 and needed zero commits for the whole of 2024, and a devotional education video platform whose infrastructure story includes a day that cost 1,500 dollars. If you want a side by side comparison of providers, I keep that in a separate post — the 12-host comparison. This is the story of what actually happened.
Chapter 1: A Boring Monolith on DigitalOcean
The first Django app I still run today is a veterinary clinic platform I built solo in 2019 — OTP logins, billing, reminder SMS on a schedule, real clinics in India depending on it. The hosting decisions I made for it were deeply unfashionable: pinned dependencies, everything configured through environment variables, and one Docker image that runs as the web server, the Celery workers, and the beat scheduler, differing only in the command. That one artifact runs three ways depending on what the deployment needs — docker-compose on a plain droplet, raw Kubernetes manifests, or a managed App Platform spec — so I was never locked to any provider’s control plane. I wrote up the full anatomy of those decisions in the low-maintenance Django monolith post.
DigitalOcean earned its place in that setup the honest way: transparent pricing, documentation that respects your time, and a clear path from a cheap droplet to managed databases and the App Platform without changing the artifact you deploy.
The payoff arrived years later. In October 2025 I moved the app’s entire file storage layer — pet photos, prescription PDFs, billing exports — from AWS S3 to DigitalOcean Spaces. The migration touched zero Python: because the storage backends had always been thin django-storages subclasses reading everything from the environment, the whole move shipped as an env-var change and an image rebuild. The same week, switching the email vendor was also just config.
What this chapter taught me: your hosting choice is rarely permanent, so make it cheap to change. The decision that aged best was not picking the right vendor — it was making every vendor swappable.
Chapter 2: Raw AWS, Because the Workload Demanded It
The second system pointed the other way. The Happy Thoughts platform serves video courses to users on phones in small-town India, often on prepaid data packs — and a single 20-minute lesson was shipping as a 1.2 GB HD file. Fixing that meant building an in-house streaming pipeline: ffmpeg transcoding adaptive HLS ladders on Celery workers in ECS, chunks in S3, delivery through CloudFront with signed URLs.
For that workload, a Heroku-style PaaS was never really on the table. Transcode jobs pin a CPU core for fifteen-plus minutes and need their own isolated queues so they never starve logins and payments; delivery needs private buckets that only answer to the CDN. That shape of problem wants raw primitives — which is exactly what AWS sells. And when the content team started dropping 150-plus videos in a single day and buried our CPU workers, being on AWS meant the escape hatch — handing transcoding to AWS MediaConvert — was one service away.
What this chapter taught me: “best hosting” is workload-dependent. The same person can be right to run one app from a single Docker image on a droplet and another on raw ECS. Choose the platform whose primitives match your hardest problem, not your average one.
Chapter 3: The 1,500 Dollar Day
Then came the morning that reframed everything I believe about hosting. On an ordinary day, roughly 5,000 users watched our videos — and CloudFront quietly served about 9 TB of egress to Indian phones at roughly 0.17 USD per GB. The bill for that one day was about 1,500 dollars. Nothing was broken. That was the terrifying part: the system worked perfectly, and every unit of user love had a price tag that grew the more we succeeded.
For a venture-backed startup that is a rounding error. For a non-profit running on donations, it is a five-alarm fire. The lesson I took from it is the one I now push on anyone choosing hosting for a media-heavy Django app: compute is not the bill that kills you — egress is. It doesn’t appear in load tests, it doesn’t page you, it scales with success rather than failure, and it arrives a month late. If your app serves large files or video, the egress meter should choose your host, not the deploy workflow.
Chapter 4: Leaving the Meter — Wasabi, Cloudflare, and a 600 Dollar Desktop
The hunt for cheaper bytes led somewhere most hosting guides never go. We moved storage to Wasabi and delivery to Cloudflare, because the Bandwidth Alliance between them took our egress cost to effectively zero — and it carried a cost nobody had itemized: Wasabi is S3-compatible, not S3, and AWS MediaConvert flatly refuses to write anywhere that isn’t real S3. Zeroing the egress bill broke our transcoder.
So we went back to owning transcoding. First a prototype on vast.ai’s rented GPUs, which we judged not production-reliable enough yet. Then the unglamorous winner: a 600 dollar Ubuntu desktop with an NVIDIA card, sitting in a corner of an office, running ffmpeg with NVENC and pushing HLS ladders to Wasabi. It was scrappy, it saved a genuinely meaningful amount of money for an NGO, and I would make every one of those calls again at that scale.
What this chapter taught me: the hosting landscape is bigger than the AWS-versus-PaaS debate. Purpose-mismatched pricing (CloudFront egress to India) and purpose-matched pricing (storage vendors that don’t meter egress) can differ by an order of magnitude for the same bytes.
Chapter 5: Growing Out of the Hack — the Move to Bunny
The scrappy stack had a domain of validity, and we outgrew it. At roughly 3.5 TB of media and 30,000 users — about 60 percent of them paying — the numbers turned against us: our egress-to-storage ratio climbed past 7-to-1 against a storage vendor whose fair-use expectations assume roughly 1-to-1, the desktop’s 600 GB cache started thrashing, and an office uplink physically could not carry prime-time streams. We moved media delivery to Bunny.net — purpose-built storage and CDN where heavy egress is the product, not a tolerated exception — for about 205 dollars a month, fully predictable.
Moving 3.5 TB between object stores while users streamed the whole time, with no maintenance window, was its own discipline: dual-write every new transcode to both stores, backfill and verify the catalogue object by object, then flip a single DNS CNAME. The rollback plan was flipping it back.
What this chapter taught me: clever-and-free is right while you’re validating; predictable-and-purpose-built is right once the thing is load-bearing. Recognizing the day a hack stops being clever and starts being exposure is a hosting decision too.
What the Quest Actually Taught Me
Boiled down, the whole journey compresses into four rules I now apply to every Django deployment:
- Make vendors swappable before you need to swap them. Storage behind
django-storagessubclasses, email behind SMTP settings, everything vendor-specific in environment variables. Both of my real migrations were config changes, not rewrites. - Model cost-to-serve from day one. Put a projected egress number next to your daily active users. The 1,500 dollar day was trivially predictable from metrics we already had — the failure was being surprised.
- Match the platform to your hardest workload. A boring monolith belongs on a boring, cheap platform. A transcoding pipeline belongs where the primitives live.
- Revisit the decision when the scale changes. Every setup in this story was right when we chose it and wrong two orders of magnitude later. Hosting is not a decision you make once.
So Where Should You Host Django?
My journey deliberately did not pass through Heroku, Render, Railway, or Fly.io, so I won’t pretend to first-hand verdicts on them — I compare them on their merits in the full 12-host comparison and in a PaaS-only shortlist. But the framework the journey produced applies to any of them:
- For the solo founder or MVP builder: your most precious resource is time. Pick a managed platform, keep your config in the environment, and ship. You can always migrate later — cheaply, if you set the seams up now.
- For a growing startup: DigitalOcean’s droplet-to-App-Platform path is the one I have personally leaned on for six years, and it has never punished me for it. Predictable pricing matters more than peak capability at this stage.
- For media-heavy or cost-sensitive workloads: do the egress math before you pick anything. The delivery bill, not the compute bill, will decide whether your architecture survives its own success.
And if you are just making your first deployment, start with the beginner’s walkthrough — it covers the Gunicorn-Nginx-PostgreSQL foundations every one of these paths eventually rests on.
Resist the urge to over-engineer on day one. The best hosting for Django is the one that lets you ship, learn, and iterate — and that costs you a config change, not a rewrite, when your success forces you to move.
Navigating these architectural trade offs is what I do every day. If you are a founder or CTO trying to map your Django application’s journey from MVP to scale and need a strategic sounding board, I can help. Reach out to me at Kuldeep Pisda.