The interface of subdomain administration has been deeply overhauled. So far, once a domain had been added to your alwaysdata account, you were able to create subdomains pointing to a precise directory. This mechanism entailed various limitations:

  • it was necessary to add the management domain beforehand, which was not particularly intuitive
  • when a site can be accessed through various subdomains ( and, you have to type the destination directory for each of them
  • the setting-up of a subdomain is limited to its destination directory. For a few months, it has been possible, however, to ask us to activate Passenger or mod-wsgi by contacting us
  • it is tedious to host several sites in one subdomain, in distinct directories

Let’s give way to “Sites”

Forget about that system, and discover the new alwaysdata administration section: Sites. Instead of handling subdomains like before, from now on what you will create will be “sites”. A site is made up of:

  • one or several addresses. An “address” is a subdomain, and in addition to it at times, a path. Here are a few examples :,,,
  • its type. We are offering at the moment 5 types, which will be detailed below
  • configuration options depending on the type

This new system offers numerous advantages:

  • it is no longer necessary to add your domain beforehand. Adding a management domain is now only required when you wish to use our DNS servers
  • whatever the number of addresses your site has, there is no more configuration to duplicate
  • you can indicate a path in your addresses. Thus, you can have a Django application on and a PHP application on without tampering
  • you do not have to contact us any more to activate Passenger or mod_wsgi
  • you can create an HTTP redirection without having to toil to create an .htaccess file
  • you can share a domain with several accounts belonging to the same customer

The one-click application installing process has been integrated to this Site section: you have an Install an application button allowing you to install, like before, a WordPress, phpBB, DokuWiki… automatically. The option of deleting applications, however, has been withdrawn: as it was not intuitive enough and confusing, you will now have to delete an application you no longer need manually.

The types of sites

  • Standard Apache, which corresponds to the type used so far in all subdomains. It is adapted to static files, PHP or any application using FastCGI. In case of doubt, it is the type that you should use
  • Customized Apache: it will allow you to indicate your own Apache guidelines, without any limits. Be careful enough not to break anything :)
  • Redirection: as its name shows, it will allow you to set up HTTP redirections. It is available in 3 modes: 301 (permanent), 302 (temporary) and transparent (reverse proxy)
  • Ruby on Rails: you simply have to indicate your application directory and it will be deployed via Passenger. In the future, you will be able to opt for another deploying mechanism other than Passenger, for those of you who prefer other technologies (Unicorn, for instance)
  • WSGI: your WSGI application will be redeployed with mod_wsgi. And the same applies in that the technology may be changed later on (hello gunicorn)

Migrating existing accounts

Subdomains have been converted automatically into sites. If you had several subdomains pointing to the same directory, we have created only one site. The names of the sites generated are not very original (Site 01, Site 02, etc.) and it is up to you to change them as you wish. Should you detect the slightest bug, in spite of all of our caution, please do contact us.

And what next?

This new interface, on which we started working a long time ago, will allow us to add new features such as HTTP caching, dedicated IPs (already available on request), SSL certificates (ditto). The statistics interface (Piwik) will also be modified for each site to have its own statistics. And above all, we will add new site types: Django (which is already running smoothly with FastCGI), Node.js, Java, Erlang…

Follow us on Twitter to take part in our next beta tests :)


  1. N2 Feb 28, 2012 @ 11:47 AM

    Ça tombe vachement bien ! Je viens de migrer mon premier site chez Alwaysdata, je m’apprêtait tout juste à configurer le .htaccess ;p

  2. richard Feb 28, 2012 @ 11:50 AM

    Great works !

  3. Julien Breux Feb 28, 2012 @ 2:10 PM

    Merveilleux. <3 Django & NodeJS.

  4. Nicolas Steinmetz Mar 2, 2012 @ 10:07 PM

    Pour WSGI, est-ce que ça veut dire qu’il va être possible d’avoir à la racine du (sous-)domaine une application utilisant wsgi et rendre accessible un répertoire de ce (sous-)domaine sans passer par wsgi ? Ou faut-il passer par du apache personnalisé ?

    Ex : test.mondomaine.tld est une appli wsgi. test.mondomaine.tld/blog lui qui est un simple export html est accessible ?

  5. Nicolas Steinmetz Mar 2, 2012 @ 10:17 PM

    Je me réponds à moi-même, non pour le mode “wsgi” simple.

    En lisant la conf apache, on voit un numéro associé à WSGIProcessGroup qu’on retrouche en début de fichier dans la variable WSGIDaemonProcess. Si on fait un apache personnalisé, comment on sait quelle nouvelle valeur on doit mettre si on utilise du WSGI customisé ?

  6. Cyril Mar 2, 2012 @ 10:55 PM

    Mixer WSGI et PHP (ou autre), oui c’est possible. C’est le principe : chaque « site » est installé sur un sous-domaine + path, et tourne indépendemment des autres. D’ailleurs si vous regardez le sites.conf généré, il n’y a pas de magie : on a un Alias sur /blog (dans votre exemple), et mod_wsgi s’occupe de /.

    Concernant le WSGIProcessGroup, le numéro est simplement celui de votre ID de site, mais c’est censé être opaque. Pourquoi vouloir le réutiliser de toute façon ? Mettez n’importe quelle autre valeur dans vos propres WSGIProcessGroup.

    Dernière chose, ce nouveau système n’en est encore qu’à ses débuts, on va étoffer tout ça (et corriger les bugs remontés). En l’occurrence, on utilise mod_wsgi pour le moment, mais on va rapidement utiliser gunicorn à la place. Enfin, pas à la place : on pourra continuer à utiliser mod_wsgi si on veut, mais gunicorn sera plus puissant et sera utilisé par défaut.

  7. Nicolas Steinmetz Mar 3, 2012 @ 9:20 PM

    Ahhhh ok, je vois l’idée sur les sites. J’avais raté cet aspect puissant…

    Bon j’ai un bug a priori quand même, je passe par le support :)

  8. nennogabriel Mar 5, 2012 @ 2:03 PM

    So Nice!!

    I’m exciting with an idea to deploy django using only ftp and don’t need to access throug ssh to configure fastcgi.

    Congratulations guys, you have best hosting I ever saw.

  9. Klaitos Mar 16, 2012 @ 9:18 PM

    Très bonne mise à jour ! Continuez ainsi :)

  10. alexh Jul 27, 2012 @ 5:19 AM

    ahh… Node.js… Looking forward to it :)
    Good luck for the future deployments!

RSS feed for comments on this post. | TrackBack URL

Leave a comment