Running Django, Rails and Mojolicious on Windows Server 2008 with IIS 7

Recently released  Helicon Zoo is a repository of popular web frameworks for Microsoft IIS. It makes installing and running Django, Ruby on Rails and Mojolicious on Windows Servers a piece of cake.


Please read following articles to find information how to run Django, Rails and other popular web engines on IIS:

And you can find usage examples for various web engines on a usage page.

How it works

Helicon Zoo utilizes Microsoft Web Platform Installer (WebPI) to make installation of web frameworks and all required dependencies easy and smooth. At first, you need to download and install WebPI from Microsoft web site here. This is a great tool that is already packed with many ASP.NET and PHP applications and dependencies to install a whole technology stack on your server. And the greatest thing about WebPI is that it can be extended by adding custom repositories. So copy this link –, open WebPI options

put it into the Display additional scenarios field and click Add feed.

Now if you select Applications, Tools at the bottom of the list, you will find new applications: Blank Django Project, Blank Rails Project, Blank Perl Project, Blank Mojolicious Project

These are all empty “Hello World!” applications used to install all required dependencies which you can stuff with your code later.

So let’s choose Blank Django Project, click Add and Install.  This will create new IIS application with pre-defined configuration. After download and installation are completed you can use Launch application in browser link:

What’s inside

The core of Helicon Zoo is a native IIS 7 (or IIS Express) module that provides FastCGI support. This module differs from Microsoft FCGI module generally developed to provide PHP support for IIS. Helicon Zoo Module is built using super capacitive asynchronous  I/O Completion Port technology. It supports Pipe and TCP transports and additional level of configuration to run many different FastCGI-enabled frameworks. These includes flup tor Python, Rack for Ruby on Rails, FCGI and Plack for Perl and Mojolicious.

The core configuration of Helicon Zoo Module is located in the <heliconZooServer> section of applicationHost.config file. This section defines all FastCGI engines that will work with Zoo. Here is an example of Django FastCGI engine definition using pipe transport; is our Python worker with pipe transport support:

<engine name="python.2.7.pipe"
    arguments="-O %SystemDrive%\Zoo\Workers\python\"
    transport="pipe" />

How to deploy Django projects

Helicon Zoo offers simple way to deploy your Django applications on the server or test machine. First you install Blank Django Project in desired location using Web Platform Installer, then you overwrite this project content with your project files and set up deployment into this forlder. Blank Django Project installs all required dependencies on target machine and puts web.config (the only file needed for your application) in the root directory of application.


Configuration of Zoo-powered applications is done with web.config file. Here is an example of such file to configure Django application for 32-bit.

<?xml version="1.0" encoding="UTF-8"?>
   <application name="django.project.x86" >
     <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%;%PYTHONPATH%" />
     <add name="DJANGO_SETTINGS_MODULE" value="settings" />
   <add name="django.project.x86"
       scriptProcessor="python.2.7.pipe"  path="*" verb="*"
       modules="HeliconZoo_x86" preCondition="bitness32"
       resourceType="Unspecified" requireAccess="Script" />

Several important things are defined here:

  • scriptProcess="python.2.7.pipe" — a reference to FastCGI engine defined in the applicationHost.config;
  • environment variable PYTHONPATH — a path where Python will check to load modules.  Here path to this IIS application is appended to allow Python to load additional modules directly from the directory of your application without installing them globally in the system.
  • environment variable DJANGO_SETTINGS_MODULE — a Python path to the configuration file of your Django project, for example ‘mysite.settings’.

Static content

It is recommended to serve static content omitting Django to save processor time and increase performance. You can easily do this by putting all static files into a directory with the following web.config in it. This will disable Django module in directory:

<?xml version="1.0" encoding="UTF-8"?>
   <remove name="django.project.x86" />

Django configuration example

Let’s assume our Django project consists of three applications:

  • site — a site itself with pages templates, static files, and;
  • blog;
  • store.

Static files are located in site/media and are available as /media/ virtual directory (i.e. MEDIA_URL='/media/').

After we install Blank Django Project in the root of web site and copy our Django application project in it we will have the following directory structure:

/media/ — is a virtual directory which is mapped to site/media and Django is disabled there using web.config file example above. In the root web.config PYTHONPATH points to the site root directory and DJANGO_SETTINGS_MODULE is set to site.settings:

   <application name="django.project.x86" >
     <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%" />
     <add name="DJANGO_SETTINGS_MODULE" value="site.settings" />

That’s all!
Sincerely, Helicon Tech team.

This entry was posted in Helicon Zoo and tagged . Bookmark the permalink.

10 Responses to Running Django, Rails and Mojolicious on Windows Server 2008 with IIS 7

  1. Alex says:

    The default Python project works fine but I have a problem with a more complex project that I’m trying to launch with IIS7. The same project launches in the development server but in IIS it returns an error:

    Unhandled Exception
    An unhandled exception was thrown by the application.

    How can I know what went wrong? It looks like the error happens before Python captures the exception. Could that be a problem with the pipe?

  2. Robert says:

    In two words: bril jant.

    After pulling my hair out for weeks trying to get Python to work on IIS on any protocol but old cgi, you finally solved that part of my problem by really enabling FastCGI..

    There remains a challenge though: debugging. I use WingIDE to step through code etc but I can’t get it up and running nor hook into it within the IIS embedded process. I guess I can tweak things by loading a nix server, pointing it at tcp port X not listening to it, while in reality having a long running process (manually started) listening to that port. It’s not trivial to set up from where I stand so if somebody has a better idea or pointers towards it I’m eager for it.

    I have to say: I used some php and I can really understand why so many people are drawn to it because of the zend-debugger and ease of setup. If Python would reach that ease it would pull in a lot more of serious programmers and give it really the momentum it deserves.

    • ruslan says:

      Hello Robert,

      Helicon Zoo was developed as solution for running python and django projects in production.
      The right common way is debugging your project locally, inside your IDE. All modern Python IDE (WingIDE, Komodo, PyCharm and PyDev) have good debugging tools.
      Debugging python applications running in IIS via Helicon Zoo is unsuitable way.

  3. Robert says:

    Thanks for your answer. I resolved my issue.

    Personally I think this HeliconZoo dll beats all other solutions including pyIsapi which isn’t even rightly compiled for Python27 and then I couldn’t get it to work anyway *shrug*

    I’m trying to understand how the connection, port communication etc with IIS works so I wanted to step through flup code etc. I can now do that.

    I use WingIDE and found out it was actually a well justified security block that was resolved with a minor tweak . I can debug like a champ now, easy as sliced bread. It’s actually kind of logical since the IIS process runs as a different user.

    I have IIS on my local laptop to mimic as must as possible a live server, I think it’s suitable to develop that way, but that’s a whole different discussion.

    I think you should promote this dll more, right now it’s well hidden in the products you deliver but it could be more of a flag on your ship.

    Another thing is, the moment I ever encounter a problem on my live windows server I can now easily hook into the live process and troubleshoot a Python request. I understand that it’s not the ‘proper’ way but this way of working helped me out tons of times in my life. The database on my server is about 1 terrabyte and the functionality of my application is largely dynamically steered by the contents of my database, including code snippets and the evaluation of logical expressions that are in the database. No way I can copy and reproduce everything 1 on 1 to my development machine.

    Thanks. I’ll leave php behind and never look back.

    • Grant Callaghan says:

      Can you give more information about how you were able to look at the live process? I am having a file upload problem and would love some visibility into what’s going on. I usually develop for linux but this client has windows service level agreement : (.

      Thanks for any help you can provide!

  4. nonhlanhla says:

    Thank you guys for an amazing product

  5. Ebru Yatkin Ajans says:

    really good job.. thanks

  6. Fantastically useful bless you, I reckon your visitors will probably want further stories such as this keep up the excellent content.