Question

I have created a Django proyect with 20 sites (one different domain per site) for 20 different countries. The sites share everything: codebase, database, urls, templates, etc.

The only thing they don’t share are small customizations (logo, background color of the CSS theme, language code, etc.) that I set in each of the site settings file (each site has one settings file, and all of these files import a global settings file with the common stuff). Right now, in order to run the sites in development mode I’ll do:

django-admin.py runserver 8000 --settings=config.site_settings.site1
django-admin.py runserver 8001 --settings=config.site_settings.site2
...
django-admin.py runserver 8020 --settings=config.site_settings.site20

I have a couple of questions:

1. I’ve read that it is possible to create a virtual host for each site (domain) and pass it the site’s settings.py file. However, I am afraid this would create one Django instance per site. Am I right?
2. Is there a more efficient way of doing the deployment? I’ve read about django-dynamicsites but I am not sure if it is the right way to go.
3. If I decide to deploy using Heroku, it seems that Heroku expects only one settings file per app, so I would need to have 20 apps. Is there a solution for that?

Thanks!

Answer 1

So, I recently did something similar, and found that the strategy below is the best option. I’m going to assume that you are familiar with git branching at this point, as well as Heroku remotes. If you aren’t, you should read this first: https://devcenter.heroku.com/articles/git#multiple-remotes-and-environments

The main strategy I’m taking is to have a single codebase (a single Git repo) with:

• A master branch that contains all your shared code: templates, views, URLs.
• Many site branches, based on master, which contain all site-specific customizations: css, images, settings files (if they are vastly different).

The way this works is like so:

First, make sure you’re on the master branch.

Second, create a new git branch for one of your domains, eg: git checkout -b somedomain.com.

Third, customize your somedomain.com branch so that it looks the way you want.

Next, deploy somedomain.com live to Heroku, by running heroku create somedomain.com --remote somedomain.com.

Now, push your somedomain.com branch code to your new Heroku application: git push somedomain.com somedomain.com:master. This will deploy your code on Heroku.

Now that you’ve got your somedomain.com branch deployed with its own Heroku application, you can do all normal Heroku stuff by adding --remote somedomain.com to your normal Heroku commands, eg:

• heroku pg:info --remote somedomain.com
• heroku addons:add memcache:5mb --remote somedomain.com
• etc.

So, now you’ve basically got two branches: a master branch, and a somedomain.com branch.

Go back to your master branch, and make another new branch for your next domain: git checkout master; git checkout -b anotherdomain.com. Then customize it to your liking (css, site-specific stuff), and deploy the same way we did above.

Now I’m sure you can see where this is going by now. We’ve got one git branch for each of our custom domains, and each domain has it’s own Heroku app. The benefit (obviously) is that each of these project customizations are based off the master branch, which means that you can easily make updates to all sites at once.

Let’s say you update one of your views in your master branch–how can you deploy it to all your custom sites at once? Easily!

Just run:

• git checkout somedomain.com
• git merge master
• git push somedomain.com somedomain.com:master # deploy the changes

And repeat for each of your domains. In my environment, I wrote a script that does this, but it’s easy enough to do manually if you’d like.

Anyhow, hopefully that helps.