Deployment options

Play applications can be deployed virtually anywhere: inside Servlet containers, as standalone servers, on Heroku, Google Application Engine, Stack, a Cloud, etc...

Standalone Play applications

The simplest and the most robust way is to simply run your Play application without any container. You can use a frontal HTTP server like Lighttpd or Apache if you need more advanced HTTP features like virtual hosting.

The built-in HTTP server can serve thousands of HTTP requests per second so it will never be the performance bottleneck. Moreover it uses a more efficient threading model (where a Servlet container uses 1 thread per request). Different modules allow you to use different servers (Grizzly, Netty, etc...) as well.

Those servers support long polling and allow to manage very long requests (waiting for a long task to complete), and direct streaming of File objects (and any InputStream if you specify the Content-Length), without blocking the execution thread.

You will have fewer problems running your application this way, as you will use the same environment that you used during the development process. A lot of bugs can be discovered only when you deploy to a JEE application server (different home dir, classloader issues, library conflicts, etc...).

Please refer to the 'Put your application in production' page for more information.

Java EE application servers

Your Play application can also run inside your favorite application server. Most application servers are supported out of the box.

Supported application servers

The following application servers are known to work with Play. Please feel free to report any other working deployment.

• JBoss 4.2.x
• JBoss 5.x
• JBoss 6M2
• Glassfish v3
• IBM Websphere 6.1
• IBM Websphere 7
• Geronimo 2.x
• Tomcat 6.x
• Jetty 7.x
• Resin 4.0.5

Deploying

You need to package your application as a WAR file. This is easily done with the following command:

play war myapp -o myapp.war

It can be invoke with the following parameters:

• --output, or -o:

• --zip:

• --%fwk_id:

• --deps:

• --exclude:

Please note that your application server must support deployment of exploded WAR files.

You are now ready to deploy your application.

You are advised to ‘isolate’ your Play application from the other applications to avoid version mismatches between the application libraries. This step is not standardized by the JEE/Servlet specification, and is therefore vendor-specific.

We recommend you refer to your application server manual in order to ‘isolate’ your WAR. As an example below is how you isolate a war file in JBoss Application server. Note that this is an optional step:

Insert the following content (or create the file) in your application war directory at myapp.war/WEB-INF/jboss-web.xml:

<jboss-web>
 <class-loading java2classloadingcompliance="false">
 <loader-repository>
 com.example:archive=unique-archive-name
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
</class-loading>
</jboss-web>

Replace com.example:archive=unique-archive-name with whatever you wish as long as it is unique.

Datasource

Play also supports Datasource and resource look-up. To use a JNDI Datasource, set the database configuration as shown below:

db=java:comp/env/jdbc/mydb
jpa.dialect=org.hibernate.dialect.Oracle10gDialect
jpa.ddl=verify

The database plugin detects the pattern db=java: and will de-activate the default JDBC system.

Custom web.xml

Some application servers, such as IBM Websphere, require you to declare a datasource in a resource-ref element in the Servlet API’s web.xml configuration file. By default, web.xml is a file that is generated by Play when you execute the play war command. To customise the generated web.xml, generate the exploded WAR version, then copy the generated web.xml file to the war/WEB-INF folder in your application. The next time you will execute the play war command, it will copy your custom web.xml from to the generated folder.

For instance, to declare a datasource for IBM Websphere 7, we can declare a resource-ref in our war/WEB-INF/web.xml file:

<?xml version="1.0" ?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
        version="2.4">
  <display-name>Play! (%APPLICATION_NAME%)</display-name>
  <context-param>
    <param-name>play.id</param-name>
    <param-value>%PLAY_ID%</param-value>
  </context-param>
  <listener>
      <listener-class>play.server.ServletWrapper</listener-class>
  </listener>
  <servlet>
    <servlet-name>play</servlet-name>
    <servlet-class>play.server.ServletWrapper</servlet-class>	
  </servlet>
  <servlet-mapping>
    <servlet-name>play</servlet-name>
    <url-pattern>/</url-pattern>
  </servlet-mapping>
  <resource-ref>
        <description>Play Datasource for testDatasource</description>
        <res-ref-name>jdbc/mydb</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
  </resource-ref>
</web-app>

Cloud-based hosting

AWS Elastic Beanstalk

AWS Elastic Beanstalk is Amazon’s Java hosting platform, based on their Amazon Web Services infrastructure. For more information about deploying a Play application, see Java development 2.0: Play-ing with Amazon RDS.

CloudBees

CloudBees is a Java application hosting platform. For more information, see the CloudBees module.

Cloud Foundry

Cloud Foundry is VMware’s cloud provider. For more information, see Running Play Framework Application on CloudFoundry and the CloudFoundry module.

Google App Engine (GAE)

The Google App Engine is one of the first cloud hosting platforms, which has different pros and cons compared to generic hosting solutions. In particular, GAE does not support JPA persistence. For more information, see the GAE module.

Heroku

The Heroku cloud application platform has Play-specific application hosting support. To deploy and run your Play application, use the following steps.

1. Install the Heroku command line client on Linux, Mac, or Windows.
2. Install git and setup your SSH key.
3. Create an account on Heroku.com.
4. Log in to Heroku from the command line:

heroku auth:login

5. Create a git repository:

git init

6. Create a .gitignore file containing the following content, to ignore files generated by Play:

/tmp
/modules
/lib
/test-result
/logs

7. Add the files to the git repository and commit them:

git add .
git commit -m init

8. Create a new application on Heroku:

heroku create -s cedar

9. Push the application to Heroku:

git push heroku master

10. Open the application in your browser:

heroku open

To view the logs run:

heroku logs

To scale the application to multiple ‘dynos’ run:

heroku scale web=2

To use the Heroku Shared Database in production add the following to your conf/application.conf file:

%prod.db=${DATABASE_URL}
%prod.jpa.dialect=org.hibernate.dialect.PostgreSQLDialect
%prod.jpa.ddl=update

For more information, see the Heroku Dev Center.

VPS / Custom Server

If you want to run play as a service on your own server you can start it with this simple upstart script
This upstart script works with ubuntu 10.04 and upwards (upstart 1.4)

bc.
description "Play Framework"
version "1.0"
env PLAY_BIN=/opt/playframework/play
env PROFILE=prod
start on runlevel ²³⁴⁵
stop on runlevel ⁰¹⁶
respawn
respawn limit 10 5
umask 022
setuid youruser
setgid www-data
chdir /home/youruser/app/current
pre-start script
test -x $PLAY_BIN || { stop; exit 0; }
rm /home/youruser/app/current/server.pid || true
end script
exec $PLAY_BIN run $HOME -Xms1024M -Xmx1024M --%$PROFILE