Combining HTML files with a Django website

I’ve been trying to work out how to run this site using Django, while maintaining some of old static HTML files on at their current URLs. But I’m a bit stuck and am looking for ideas.

My website at has accumulated a lot of stuff over the years. The bulk of the site (the weblog and associated pages) is currently running on Movable Type with a lot of custom PHP, and that’s the part I’m slowly re-writing in Django.

However, there are lots of other bits and pieces that I don’t want to lose, but don’t easily fit into the structure of the main website. For example:

Ideally I’d like to keep all these online, at the same URLs, when I move the rest of to a new Django site, but I’m not sure whether that’s feasible. And if it feasible, what would be the least bad way to do it.

Here are the options I’ve thought of so far:

  1. Create a new site, under a subdomain of, for static HTML and its images etc. Redirect the current URLs to this site. This seems simplest, but will mean changing URLs.

  2. Host on WebFaction which, I think, will allow me to combine a Django website with one or more “Static” websites under different directories. This sounds like it should work, and I already have PHP/HTML sites on WebFaction, but it feels fiddly.

  3. Host on Heroku (which was my initial aim) and use multiple buildpacks to serve the Django site and the static directories. However, I can’t see anything in the docs that say multiple buildpacks let you do this, so maybe it’s not possible.

  4. Somehow serve HTML pages through the Django site, maybe using something like django-staticflatpages. I’ll probably do this for a couple of currently-single HTML pages (like /japanese/) but I think it’s a non-starter for larger quantities of pages (laborious to set up, very inefficient, and there are issues with relative links to in-page graphics etc).

  5. Use Nginx on DigitalOcean (or wherever) to serve Django and then certain directories as static files. This ticks all the boxes except I really don’t want to administer servers any more.

Leaving aside option 5, option 1 seems simplest, but it feels a shame that the URLs of pages and files should be so dependent on the differing technologies used to code the site.

After so many years of running sites that are either solely Django/Flask/etc, or else solely uploading-PHP/HTML-files-to-a-shared-server, trying to combine these different things seems unnecessarily awkward.

Do you have any other ideas? Do let me know on email or Twitter. I can’t be the first to want to do this.

UPDATE, 27 Oct 2017: Thanks to those of you who offered suggestions. We now have a couple of further options:

  1. Use a reverse proxy like Amazon CloudFront or Cloudflare to serve the static files and the Django app from different places. e.g. Put static files on Amazon S3 and the Django app on Heroku, then, I think, use CloudFront’s Behavior Path Pattern to set them as different origins. (Thanks, Frankie Roberto.)

  2. Use WhiteNoise to serve all the static files from your Django app on Heroku. e.g. Put directories of static files in the folder specified by WHITENOISE_ROOT and set WHITENOISE_INDEX_FILE (currently only in v4.0b4) to 'index.html' or whatever works for you. (Thanks Matthew Somerville.)

Option 7 seems almost too good to be true, for someone who wants a relatively simple life. I haven’t tried it in production with a lot of directories of a lot of files yet, but hopefully it’ll work fine. You could always use a CDN to help with the load if necessary. I like that it keeps all the files — static HTML files, Django app, plus its images, CSS, etc — in one location. And it’s easy to add new directories of static files by putting them in the WHITENOISE_ROOT directory and pushing to Heroku.

Commenting is disabled on posts once they’re 30 days old.

18 Oct 2017 at Twitter

  • 9:16pm: @paulrobertlloyd Thanks Paul, good to know that works!
  • 6:59pm: Very good. Ten years of permanent URLs for BBC programmes. Well done everyone!…
  • 6:50pm: @paulpod @SonyUK You should be able to get a repair or replacement from the seller, regardless of the warranty.
  • 5:36pm: @dracos I just noticed that looking through the Issues. Sounds promising, thank you :) I will have a poke when I next get the time…
  • 5:18pm: @dracos Oh, interesting… I’m using Whitenoise for the static assets, hadn’t noticed I could add other files. Think it’d be OK serving HTML?
  • 5:05pm: @benterrett @infovore Let me know your fax no and I’ll send it right over.
  • 4:40pm: @infovore Maybe I’ll just delete it all and write any new blogs on Medium ha ha
  • 4:35pm: @infovore I’m not sure that’d work.
  • 4:33pm: @infovore Yeah that does seem best. I was just relieved with my recent decision that paying for Heroku is better than administering a server :(
  • 4:07pm: I’m guessing correct answer is Option 5, but I really don’t want to set up servers any more. I’m hoping there’s an easier & better Option 6.
  • 4:06pm: Does anyone Django-y have any thoughts on how best to combine a load of legacy HTML files with a Django site…?…
  • 2:06pm: It might not be a false alarm! FreeAgent forgot to update the only place in the UI that this change was apparent to anyone using it.
  • 1:42pm: @freeagent The interface still says a level 8 Accountant can delete all data…
  • 12:19pm: Partially false alarm! If you want your accountant to add Journal Entries, or file VAT returns, they can still also delete ALL your data.
  • 12:03pm: Finally!… (After 7 years of complaints, your accountant no longer has permission to delete all your FreeAgent data.)

18 Oct 2017 in Links

On this day I was reading