In providing ultimate flexibility in terms of deployment,
your Dancer app can be run as a simple cgi-script out-of-the-box.
No additional web-server configuration needed.
Your web server should recognize .cgi files and be able to serve Perl scripts.
The Perl module Plack::Runner is required.

Start by adding the following to your apache configuration (httpd.conf or sites-available/*site*):

WARNING: Dancer's use of global variables and Coro's threaded behaviors can cause some unexpected behaviors. See this GitHub issue for more details. Unless you have really, really strongly compelling reasons to use Corona, consider using Twiggy or Starman instead.

To start your application, just run plackup (see Plack and specific servers above for all available options):

as value: the options to pass it as a list. In our case, there is no option to specify to Plack::Middleware::Deflater, so we use an empty YAML list.

To test if content compression works, trace the HTTP request and response before and after enabling this middleware. Among other things, you should notice that the response is gzip or deflate encoded, and contains a header Content-Encoding set to gzip or deflate

The simplest way to achieve this is to push your main application directory to dotcloud with your bin/app.pl file copied to (or symlinked from) app.psgi.

Beware that the dotcloud service enforces one environment only, named deployment. So instead of having environments/development.yml or environments/production.yml you must have a file named environments/deployment.yml.

Also make sure that your Makefile.PL (or other dependency mechanism) includes both Dancer and Plack::Request.

If you use the Template::Toolkit and its INCLUDE or PROCESS directives, you might need to add the search path of your view files to the config. This is probably going to be something like INCLUDE_PATH: '/home/dotcloud/current/views' in config.yml.

An alternative implementation is to use a variation of the above Plack::Builder template:

This also supports hosting multiple apps, but you probably also need to specify the specific Environment configuration to use in your application.

When mounting under a path on dotcloud, as in the above example, always create links using the uri_for() method for Dancer routes, and a uri_base variable for static content as shown in Dancer::Cookbook. This means whatever base path your app is mounted under, links and form submissions will continue to work.

Another option would be to run your app stand-alone as described above, but then use a proxy or load balancer to accept incoming requests (on the standard port 80, say) and feed them to your Dancer app.

This could be achieved using various software; examples would include:

It could be used simply to hand requests to a standalone Dancer app. You could even run several instances of your Dancer app, on the same machine or on several machines, and use a machine running balance to distribute the requests between them, for some serious heavy traffic handling!

To listen on port 80, and send requests to a Dancer app on port 3000:

balance http localhost:3000

To listen on a specified IP only on port 80, and distribute requests between multiple Dancer apps on multiple other machines:

NOTE: Only a single Dancer application can be deployed using the Plack::Handler::Apache2 method. Multiple Dancer applications will not work properly (The routes will be mixed-up between the applications).

It's recommended to start each app with plackup using your favorite server (Starman, for example) and then put a web server (Apache, Nginx, Perlbal, etc.) as a frontend server for both apps using reverse proxy (HTTP based, no fastcgi).

If you want to deploy multiple applications under the same VirtualHost, using one application per directory for example, you can do the following.

This example uses the FastCGI dispatcher that comes with Dancer, but you should be able to adapt this to use any other way of deployment described in this guide. The only purpose of this example is to show how to deploy multiple applications under the same base directory/virtualhost.

Of course, if your Apache configuration allows that, you can put the RewriteRules in a .htaccess file directly within the application's directory, which lets you add a new application without changing the Apache configuration.