-- Drupal and Web Development

Notice: this post was last updated 6 years 27 weeks ago so it might be outdated. Please be cautious before implementing any of suggestions herein.

A hosting platform -- the end of an experiment

Last year we launched a beta version of Qumbia, a platform for creating Drupal sites easily. Today we are definitely shutting it down. I'll attempt to explain how it worked, why we're shutting it down, and what will replace it.

Here's how it worked:

  • one "master" site, with all the basic functionalities you'd want in a basic website (wysiwyg editing, captcha, blog, events, store etc.) was kept up to date.
  • a cloning script was set up which would clone the master site to a new directory on the same Drupal installation, using wildcard DNS. Thus, it was possible to clone the basic site in a few seconds on a new domain, for example,
  • this was all tied in to a proprietary billing system which would give clients 30 days to try out the service.
  • the cloning script allowed clients to select "features", such as a blog, a store, multilingualism, etc., which could or not be included in the site.

What went wrong:

Although Qumbia was a great learning experience, many major problems quickly came to light:

  • People who are not knowledgeable about websites don't want to pay for websites, even a limited amount. They are perceived to be free.
  • The free 30-day period was used only by lightweight personal bloggers who didn't want nor need the complex functionality of a managed Drupal site; the service was also used by spammers to have a free platform for 30 days.
  • Most serious clients with real projects are just too busy to create their sites themselves, even if it's really simple. Our good clients were those for whom we did all the site creation work on the platform.
  • The initial idea was to keep the initial site up-to-date every week, and monthly perform security updates on all client sites using drush. This proved to be hugely time-consuming and error-prone.
  • The cloning process and especially modifications made to the cloned database, for example for removing multilingualism for those who did not use it, was based on a very static database schema and had to be reviewed every time the schema changed.
  • Most of the scripts we were using were proprietary and thus we we're benefiting from community input.

So what's next?

Since we've set up this system, Aegir has emerged as an important system for managing Drupal sites from inception to security updates. It is an open-source community-supported system which seems the way of the future.

My partner at Lydie Servanin and myself are in fact no longer accepting new clients under and we are both now working at, a recognized leader in Drupal services and one of the main shops supporting Aegir.

In my opinion, using Aegir and marketing it as a Drupal management platform as opposed to a general website management platform is the way of the future in managed Drupal.