Free Videos about Mastering Views

How To: Multisites vs. Multiple Sites

Play Video
Movie link (right-click to download)
Problem with this video? Contact me

Drupal's Mutlisite feature sounds like the Holy Grail for whenever you want to run multiple Drupal sites. However, the answer to "Should I use Multisites?" is best discovered by knowing what Multisites is and how it might benefit or hinder your objectives.

In this video, I provide an overview of Multisites vs. Multiple Sites, and hopefully, the insight necessary to decide.

The later part of the video runs through an optimized setup for using/running Drupal's multisites feature. It showcases an Apache configuration for better security (blocking more files), faster performance (fewer disk hits) and easier upgrading (a better way to update than using site maintence mode).

One thing I forgot to mention, in the video, with using Mulitsites was the way to implement cron.php. Assuming you have shell access, you can easily use a script to do this. For my particular multisite setup, I use a cron shell script and special thanks go to user gnat and the others in that thread for their work!

If you're looking for more information about using multisites then head on over to

ApacheMultisiteSetup.tgz3.65 KB

One thing I forgot to mention, was the loading order and using DirectoryIndex offline.php to put all sites into no access mode.

The DirectoryIndex apache directive needs to come AFTER reading in Drupal's .htaccess file (because Drupal's .htaccess declares index.php as the default).

So it would look like this...

# Keeping the drupal config in a different file makes it easier to manage

# Toggle APC cache
php_flag apc.cache_by_default 1

<Directory "/home/drupal/drupal_root">
    # Yeah, better performance - no hits to the file system
    # Loading Drupal's .htaccess into memory is much better
    AllowOverride none

    # Define your own file limitations on drupal files
    <FilesMatch "(install.php|cron.php|update.php|.txt)$">
        Order deny,allow
        Include conf.d/ip.conf
        Deny from all

    # Read in Drupal default .htaccess file asif conf - easier CVS management
    Include /home/drupal/drupal_root/.htaccess

    # Changing the index file for all sites in a multisite install is easier
    # done with an apache directive. Now you don't have to go into each site!
    # You may also want to temporarily rename Drupal's index.php to something
    # like so visitors can't get to it. ;)

    # DirectoryIndex offline.php

# Sorry, no svn peeking
<DirectoryMatch ".svn">
    # Currently pointing back to drupal
    # High traffic sites might want custom
    # error pages, no need to load drupal
    ErrorDocument 403 /index.php
    Order allow,deny
    Deny from all
    Satisfy All

# Allow the .htacces files to be used in the sites folder where /files are stored
<Directory "/home/drupal/drupal_root/sites">

# Block off access to admin and devel - just in case
<LocationMatch "/(admin|devel)">
    Order deny,allow
    Include conf.d/ip.conf
    Deny from all

Lazy as I am, could you please provide al the config files you talked about for dwnload?

Love the idea, and would like to try this out for my server!

I'm posting this comment because for some reason Mollom ate it and it never showed on the site.
---------------- snip ----------------
For the LOVE OF GOD, if you're going to talk about Open Source software PLEASE don't use a proprietary format for your media! I cannot get quicktime to work in any browser, so I simply CAN'T watch this video, which I hear is very good. Not all of us own Macs, and I personally don't want to - but I would like to be able to watch a video on any browser on any platform. I find it quite helpful. Thanks in ADVANCE. Nik

Thanks to Jonathan Lambert over at Workhabit , there is a way to play QuickTime on Linux. See this comment.

In the meantime, I am uploading the videos to as However, I don't like that they are scaled down. You can't see stuff shown on the screen as clearly.

Given that this site is a "hobby site" currently, I can't say that I'll be able to do flash immediately, but I do have the know-how to convert at 100% so the video quality is just as good. It's just a matter of time in the day. :(

If anyone reading this comment wants to help out with this site then just email me at

For the love of all that is Open Source, do not change to Flash videos!! It is just recently that Adobe has released a 64bit flash version, after over 4 years of them claiming that it was "coming soon", and it's an alpha, not even a finished product. Adobe is NOT Open Source friendly. And by all accounts, will not be for a long time, if ever.

You can use the flashvideo module to upload and transcode the video to flash. Plus it will leave the original version as well. You also have the option of creating a link to either/or the flv and other version for people who want options.

Thanks Kappaluppa,

Since all the content on the site is currently free, I don't have much time to offer the alternatives. However, somewhere down the road I may offer alternate formats. We'll see what the future holds. :)


OGG has an option to cross post to the Internet Archive. If you use it, will transcode your video to OGG.

I don't think this video can be easily converted to ogg/theora, it appears to have a weird, possibly variable(?) frame rate. If it is variable then theora doesn't that yet (it's a planed feature, coming soon!).

I've used FireFox AND IE on Windows XP Pro and I simply just can't view the video. Your other site works, but I would still get this taken care of cuz this video ranks high in Google.

The video is actually loading from S3 so it may not load immediately. I'd love to spend as much time as possible on enhancing the site. Unfortunately, for the next few months, I have a big project preventing me from putting the time into fixing a few things.

For the time being, I have been posting the videos to Here's the link for this video.

There are a number of things I'd like to do to make it easier to watch the videos, and I do have flash versions of the videos. I just need to get them up. :( I'll see what I can do over the next few weeks.


On the "Differences" slide you mention that Upgrading Drupal is more complex with Multisites and for Module Management the exact opposite.

In my experience the two are very similar tasks and in both cases I would say that the Multiple Sites scenario is more complex.

Yes, in some cases you will have to take offline all your sites before deploying the new version. But, you will have to take all these sites offline anyhow, just not at the same time. With Multiple Sites you will have to do many deployments of Drupal core or of modules, instead of only one.

In most cases when you upgrade Drupal, and I assume you mean minor upgrades - from 6.5 to 6.6 for example, you really don't have to take any site offline and update.php does not need to be run at all. In this way more common case Multisites are by far less complex.

If you are upgrading Drupal from 5 to 6 for example, then you have to upgrade each site individually and this is a quite long manual process.

It depends on the perspective of what you consider upgrading. There are two parts to upgrading Drupal. 1) The actual codebase and 2) The database (multiplied times however many sites you're managing).

Regarding total time all sites are down, while upgrading, you are correct, and it's all relative to the issues you come across while upgrading.

The vantage point I was taking, was that of upgrading the Drupal database (which is where you potentially come across more errors than with the codebase). I should have clarified, the process of upgrading the codebase of drupal is one which is covered in the second item of Version Control. Although, when I re-listened to the video, I must admit it sounds like I'm saying that upgrading the Drupal codebase is more complex, which it is not.

I made the assumption that viewers would understand that when I was talking about upgrading Drupal I was talking about running update.php and making the changes to the database. True, this is less complex, when compared to Multiple Sites, because you potentially only have one version of all your modules to update (unless using modules subfolders within each site folder [meaning all modules in are sites/all/modules]).

The "more complex" aspect I was referring to was running update.php on Multisites. If you have 10 sites, then you're going to be down for a longer period of time (perceptively - taken from a financial mindset), than if you are running Multiple Sites. The biggest issue however, is when conflicts happen within one of the ten databases. You can't roll the site back as easily with version control because 9 of your databases upgraded successfully, where you now need to troubleshoot the one - because they're all using the same code.

Unless you're really good at writing helpful shell scripts for automating this process, you may find Multisite upgrading more complex. With Multiple Sites, only one site out of the ten is affected. I guess I should say your stress factor is less with Multiple Sites than with Multisites - regarding upgrading.

If you've got good automation, and you can batch upgrade your sites' update.php then you're correct in every way. Upgrading is less complex. I was just assuming more of a beginner's approach to using Multisites.

Thanks for helping to clarify things for those reading this thread!

I've modified my technique slightly. Rather than rename Drupal's index.php, I'm simply blocking access to it based on the same criteria for other levels of sites access. I've uploaded a new tgz file with the setup files.

I also added a copy of my offline.php file which should be at your drupal root.


# Offline mode changes the index page to offline.php and limits
# access to index.php based on specified criteria.

# Changing the index file for all sites in a multisite install is easier
# done with an apache directive. Now you don't have to go into each site!
# You also want to temporarily block access to Drupal's index.php.

# If access criteria is met then index.php will be used because it was
# added first by Drupal's .htaccess. Note, you need offline.php in the
# document root!

DirectoryIndex offline.php


# OPTION 1: If you know you have mod_rewrite, you can simply shuttle
# every request (which is now headed to index.php) to offline.php

# <IfModule mod_rewrite.c>
#     RewriteCond %{REQUEST_URI} /index.php [NC]
#     RewriteRule ^.*$ /offline.php [L,R=302]
# </IfModule>

# OPTION 2: If you uncomment the following then you'll simply block
# any request right at the door. Apache will throw a forbidden page.
# Of course you can use your own custom error pages but not quite
# as nice as a MOVED TEMPORARILY (302) - this may be more secure
# I don't know if you can hack around mod_rewrite to get to index.php

# <FilesMatch "index.php$">
#   Order deny,allow
#   Include conf.d/ip.conf
#   Deny from all
# </FilesMatch>

How about updating the RSS feed to include the videos. I'd like to subscribe using Miro.

i learned a lot from this video, thanks!

then i came back to check out the comments & download the config files, but the video downloads automatically so it saturates my (slow) WAN connection while i'm reading the comments -- please make the videos load on demand, not on viewing the page

thanks again

Thanks a lot! That was really helpful. I have the feeling that I am going to have to go back through that a couple times to get everything. I really appreciate the file with all the text. That will save me a lot of time.

As for your root password jokes on you! I went into localhost as root and was able to delete everything! Hmmm, maybe I should have backed up first... My site now seems to be having some issues... ;-)

I was getting so tired of all the admin stuff I had to do. Now you just saved me a ton of time! ;) Thanks!

Trying your implementation on a Debian box with sub-domains.

I can get the primary domain - to work. When I try I get a page not found.

I have several multisite installs running currently, but I am using a different method.

Anything pointers for a Debain Apache install?


I've not personally used subfolders. My only use with multisite has been with whole domains. Although, there is nothing that I mentioned in the video that is specific to one distro. The configuration is Apache specific and relates to how Drupal handles multiple sites using its multisite feature.

Sorry I can't be of more help on this one.

thank you for this. this is very helpful and well done.

Hi I can not get the this video to work in either IE or Firefox. What do I need to watch the video.
Thank you

The video is still around, just not loading in his player for some reason

If you have a multi-site with each site in its own db, is there a way to automagically enable a new module for every single site inside the modules install function? Or, do I have to connect to every database and install the schema "by hand" so to speak?

With multisite you can have all the site-wide modules in /sites/all/modules/ and yes you'll have to enable them one by one for each individual site. I heard you can set up the database to share things like blocks, modules, users, etc

sorry for asking, and I apologize for my English

Drupal 6.10
Debian 8
Mysql 5.21

I try to install and operate and as different sites, but installed and functioning properly, install, installs in principle,
creates the database, comes to the new home, but when I Click on any link reads the database, and result.
Access denied
You are not authorized to access this page

Any idea:


site1 --------------> sites/ symlinks

In drupal_root/sites

---- --------------> example symlinks
---- example

setting.php ( then install
$db_url = 'mysqli://example:example@localhost/example';
$db_prefix = '';
I add
$base_url = ''; --------------> site1 symlinks

setting.php ( then install
$db_url = 'mysqli://site1:site1@localhost/site1';
$db_prefix = '';
I add
$base_url = '';



DocumentRoot /var/www/sitios/drupal_root
LogLevel warn
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined
ServerSignature On
DirectoryIndex index.php index.html index.php home.shtml index.cgi

Directory "/var/www/sitios/drupal_root"
Options +Indexes
AllowOverride All
allow from all

Alias /site1 /var/www/sitios/site1

directory "/var/www/sitios/drupal_root"
Options +Indexes
AllowOverride All
allow from all


sorry in

site1 ———————> sites/ symlinks

By doing

  <FilesMatch "(install.php|cron.php|update.php|.txt)$">

you are blocking access to robots.txt file, which will not allow googlebot and other robots to access your robots.txt

We need a way to allow robots.txt to be visible to bots.

something like

<FilesMatch "robots.txt">
Allow from all

or maybe do a better way of recognizing googlebot (Allow from googlebotIP? )

Would be nice to have solution to allow all major bots (Google, Yahoo, MSn) to have access to robots.txt

Wow, I can't believe I forgot robots.txt! Thanks for catching it. In fact, there are a few other settings I've added since I shot this video. Such as turning off gzip compression on the .ico file, which can mess things up on the favicon. Here is my latest drupal.conf file.

# Keeping the drupal config in a different file makes it easier to manage
# include this file within your virtual host(s).

# Toggle APC cache for testing if needed
php_flag apc.cache_by_default 1

# Remove any offending mod_security rules
# that prevent proper drupal functioning

#SecRuleRemoveById XXXXXX

# Alias your favicon to the right path in drupal/misc so
# you don't get log errors. When using your own custom icon,
# override this after this file is called in within the
# virtual host directive for each unique site

Alias /favicon.ico /change/this/path/to/drupal/misc/favicon.ico
# and don't compress it
<FilesMatch "^favicon.ico$">
  SetEnvIfNoCase Request_URI .ico$ no-gzip dont-vary

<Directory "/change/this/path/to/drupal">
  # Yeah, better performance - no hits to the file system
  # Loading Drupal's .htaccess into memory is much better
  AllowOverride none
   # Define your own file limitations on drupal files
<FilesMatch "(install.php|cron.php|update.php|.txt)$">
        Order deny,allow
       Include /change/this/path/to/your/conf/ip.conf
     Deny from all
   <FilesMatch "robots.txt">
      Allow from all
   # Read in Drupal default .htaccess file asif conf - easier CVS management
  Include /change/this/path/to/drupal/.htaccess
   # Offline mode for multisite setup - see file for more info
    # Uncomment the line below to set sites to offline mode
  # Include /change/this/path/to/your/conf/offline.conf

# Sorry, no svn peeking
<DirectoryMatch ".svn">
    # Currently pointing back to drupal
    # High traffic sites might want custom
    # error pages, no need to load drupal
    ErrorDocument 403 /index.php
    Order allow,deny
    Deny from all
    Satisfy All

# Allow the .htaccess files to be used in the sites folder where /files are stored
<Directory "/change/this/path/to/drupal/sites">

# Block off access to admin and devel - just in case you're using on production
# this is very strict because it's limited based on IP addresses
# adjust as needed
<LocationMatch "/(admin|devel)">
   Order deny,allow
   Include /change/this/path/to/your/conf/ip.conf
Deny from all

Where are you loading the DSO support, Listen, ServerRoot, ServerName, DocumentRoot setting. Are you just showing partial of your drupal.conf file?

I think your video is in QuickTime format which I don't have installed.
I have no intention to install it for one video.

Quicktime is evil. I'm not saying it's as evil as itunes but it is at the same level as windows media player. So why not use VLC instead? It's better and it's a multiplatform alternative, although with this particular movie it has some difficulties. Some weird encoding is happening here, hitting my cpu's. I had to close a virtualbox to watch. Things get better with Matt's newer videos.
On windows you can also use quicktime alternative, but this will only play your quicktime media, nothing else.

and I am not going to install MS media sth :-)
your choice.
But you will miss sth really great.

Thanks for the video. Lots of really good information!

I would be interested in your (multisites vs. multiple sites) thoughts on setting up the following project:

  • 30 domains each running Drupal
  • Each domain will host blogs for multiple users
  • Identical user names (i.e. Tom) will be in use across the different domains, but will be owned by different people, (i.e. "Tom" on will be owned by a different person than "Tom" on
  • Hosting all domains in a shared hosting account
  • Drupal 6.12 on Linux server with Apache (only access to Apache is through cPanel Apache Handlers)
  • Several years of PHP and MySQL experience, but am just starting out with my first Drupal site(s)

Can you have multiple users with the same username across different domains using multisites?

For an experienced Drupal admin, would you recommend multiple sites (so as to minimize potential pitffalls) or recommend multisites (to minimize required administration time)?



However, my first piece of advice is to make [super] sure, you're familiar with and comfortable with, a version control system. You'd simply have too much pain doing this type of setup any other way.

The biggest thing I'm afraid of in your post above is shared hosting account. Assuming you might have the ability to manage your own version control repositories. What you are proposing should be done in an environment where you have full control (my suggestion). This can either be via a Xen (or some other virtualized environment - including the cloud - like ec2) or via a dedicated box. Shared hosting simply won't cut it if any one or more of those sites gets a decent amount of traffic.

Plus, you'll want monitoring like Munin and/or Cacti to know which of the sites is getting what traffic.

Here are the providers I have used and like.

  • Slicehost is one I'm currently using. I LOVE how you can scale your slice, have inexpensive backups, run off of RAID 10 and can transfer (without bandwidth cost) between slices in an internal network. They were bought by Rackspace so they've got some muscle behind them.
  • ThePlanet is where I had many of my former servers for many years. I got great service and loved the monitoring. You don't get the disk redundancy or inexpensive backups by default, but you can add any number of features you want.
  • SoftLayer is where I'm currently hosting this site. I would consider moving it to Slicehost, however, the bandwidth plans at Slicehost are more limited than going with a dedicated box and a generous bandwidth plan.

The next biggest thing I would be concerned about is backups. You have to have a backup plan and that can be with a secondary server, a secondary drive in the same server, offsite backups, RAID options and other methods related to backups (stuff such as S3 and using something like this) in order to feel comfortable with potenial "bad stuff" happening.

There are a ton of thing to cover regarding your goals, but fortunately, you can find a ton of info on the nets!

Multiple Sites vs. Multisites really depends on how many things will differ across all the sites. If they are all going to be the same, all going to upgrade at the same time and essentially be centrally managed, then go with multisites. If the owners of the sites will control which modules they use and there are a number of potential variables then you'll want to use multiple sites for sure.


Thanks for your advice regarding setting up Multiple Sites vs. Multi-sites. Also, thanks for your recommendations on Munin and Cacti, and the hosting sites.

I currently have 24 GB of hosting space on HostGator. Initially, I'm pretty satisfied, but I'm sure I'll be looking for some more safety nets in the near future, maybe even prior to replicating multiple sites. Lots to think about.

I also want to say thanks for the "How To: Manage Drupal Permissions More Easily" video you created. I've spent several hours searching for the perfect "modules cocktail" that would enable me to restrict whose blog posts can be promoted to the front page. From all I can tell after watching your video, I believe you have found the magic bullet, the override_node_options module. For me, the rest of the video was was simply delicious frosting on the cake.

Great site!



Bear with me I am a bit of a greenhorn.

There is nothing easier than following directions to the letter and getting expected results. But it is never quite that easy is it.

Unfortunately my broadband access is NOT static. As much as I pay it should be but alas that discussion is for someone else.

Would you provide an example of other options to use where instruction provides using a static IP? I would be most appreciative.


The example of using an IP is actually the most restrictive. There are a number of ways, including using a Cookie, using htpasswd or htdigest via either the httpd.conf file or via .htaccess files.

The best advice I can offer, beyond what the video covers, is to do Google searches on the keywords related to authentication. The links above will hopefully get you started.

Thanks Matt.

A little push in the right direction is what was needed.

I have been looking for someone to put together a Drupal resource like this (that wasn't asking for a $300 subscription)!
Your production standards are top-notch.
The multi- vs multiple is just what I was looking for. I am now in the process of pouring through your other tuts.
I just wanted to say "Please, keep up the great work!"
If you are taking requests, I would very much like to see more on this subject as well as upgrade and back-up strategies.

On a slightly related note: I just discovered a new(beta) site.
It is a great resource for developers that allows for up to 3 separate installs (even includes D7) for FREE! (My favorite flavor)
The really cool thing is that you can share your customized installs with others.

Anyway, thanks again for the wonderful resource.
If there is anything I can do to help, let me know.

Win XP can view quicktime in firefox...just get the add-on....there is a linux quicktime viewer...try MPlayer, Quicktime 4 linux and there's an non open source one as well..i think its called Crossover.....

Great video tutorial! Very easy to understand! Upgrading Drupal when you have a multisite installation setup is much harder than having a single site setup. If you put the time into upgrading each site on your multisite setup, the benefits of having this kind of setup outweigh running many servers each with it's own Drupal install. Read more about Drupal multisite installations at

great video, great job, i just love to listen, it is very good to follow and great tips.
Love to see more.
I will check out the buttons coffee and more.

Hey that video was nice. And I was able to understand the diff. You only releases videos in your site? Only about Drupal? I would like to know?

Your videos are terrific. Coming from a non-programming background, they are very helpful. I am trying to set up multi-site on an intranet and currently am not using a domain name but an IP address (actually using a virtual server). I notice that the hosts file for the apache server associates the IP address with 'drupal6' (without the quotes). Most of hte Drupal literature references or other references to domain names when setting up multisite. This generally makes sense in the public arena with web hosting etc.

My questions are if one is using an IP address for the default or root of Drupal and you wish to set up multiple sites using sub directories:

(a) do you name the subfolders for the new sites as "default.subdirectorysite1 , default.subdirectorysite2, etc" or as ", etc"?

or (b) do you create a local domain name and change the apache hosts file to associate your default with, say, ?

This was a very enlightening video. Sadly, after investigating, I found that Apache 1.3.x (the version our company is running) does not support the include directive in directory or virtual host contexts. Figured I'd just mention that for other folks who may have run into the same problem.

I confused now. Which do you use a mutlisite (one drupal install and site setup under sites directory) or Mutliple Sites (multiple Drupal installs). Have start with Multisites and want to change to Multiple Sites for the reason you have stated. I am trying to figure out the directory structure to get it to work. So this is what I was thinking
www/ install and use the sites default directory or contributed modules and themes
www/ install and use the sites default directory for contributed modules and themes
Is this correct?

How does one configure the .conf files? What does one do when they do not have access to the conf files (share hosting) like you have. I can configured on my local development box but not on the live hosting site. Also I would like implement some the restrictions to the files install.php, robot.txt, update.php. etc . So there another way to do it.

Great site and videos I am always becoming back to the site for information. Keep up the great work.
Thank you,

Hi Matt,
Thanks for this great tutorial. I am on a shared hosting and would like to implement multisite/multiple sites. My sites (3 of them) will have the same features and perform the same basic functions (blogging), the only thing different will be the domain names. They won't generate alot of traffic - since they are personal blogs.

  1. Should i be doing multisite or multiple sites (i am not 100% clear) what do you think?
  2. How can i carry out the actions in your tutorial on a shared environment? Since i don't have access to .conf files - Can i do this in .htaccess files? If so, can you show how? Are there alternatives for someone in a shared environment? Can you create a mini tutorial for these please or point to some helpful links on how to do these?

Your time and attention is greatly appreciated. I look forward to your reply eagerly.

I am still a Drupal noob, but watching the vid seems to have helped to get some stuff to sink in. Well put together!