A practical recipe for deploying a Play Framework application to Amazon EC2

Play Amazon Blog1

Running a Play Application on an Amazon Linux EC2 Instance

At Rijware, we have found that the combination of the Play Framework ( →) and Amazon Web Services provides an efficient and scalable platform to build web applications.  We like Play for its performance characteristics, but as important, for the level of developer productivity it provides.   It is a production tested framework, used by organizations with large numbers of users such as LinkedIn and The Guardian.  Amazon Web Services (AWS) provides both scalable computing resources and application services that can lower capital costs as well as labor in setting up servers and maintaining their technology stacks. Innumerable startups and established organizations use AWS to run their cloud applications; Netflix, GE and Ticketmaster are but a few examples. Together Play and AWS provide an effective platform for building an application from a prototype or minimum viable product right up to full production scale.  The AWS free tier is a great way to get started on a prototype or MVP application.

This article is intended to provide some practical information that can be used to deploy a Play application on an Amazon Linux AMI EC2 instance that uses an Amazon Elastic IP.  We do not go through the creation of a Play application, but assume that one has already been created and it is ready to be deployed.

Figure 1 illustrates the key components of the deployed application.  The Play application runs within Amazon Linux which is deployed as a single EC2 instance.  Typically a web application has some sort of persistent storage behind it, and Amazon’s DynamoDB and RDS services can provide this function.  The use of these services is specific to the type of application you may be deploying and is not covered in this article.  Figure 1 shows DynamoDB simply to demonstrate where it would fit into the architecture.  In addition or in place of it could be any combination of AWS services that your application needs, such as RDS.  In general, these services could be configured before creating the EC2 instance since they can be accessed from your development environment and integrated that way prior to deploying your application to EC2.

Figure 1:  Deployment Architecture

How does one go about creating this deployment stack?  Here are the steps, all designed to stay within the bounds of the AWS free tier.  These instructions assume that you have created an AWS account.  The details of each setup step required in AWS are not provided here since they can be easily found in the AWS documentation.  We mostly use the AWS web console to perform management tasks and that is the basis for the instructions included here.

  1. Login to the AWS management console.
  2. Choose the EC2 service.
  3. From the console, create an Amazon Linux t1.micro instance.

Once the instance is created, access to it must be granted in order to install your Play application and allow users to reach the web server.  So, the next step is to setup a security group.

  1. Still in the EC2 management console, select Security Groups.
  2. Create a new security group.
  3. Add an inbound rule for SSH from the computer that you will be using to deploy the Play application to the Linux instance.  It’s a good idea to lock SSH access to specific IP addresses that you control.  To check your externally visible IP address, you can launch this URL →
  4. Add an inbound rule for HTTP (and HTTPS if needed) that accepts all sources.  If you want to keep this instance private for the time being, restrict access to desired sources.  You should have a set of rules that look something like Figure 2.

Figure 2: EC2 Security Group configuration

If you have a registered domain name that you plan to use for your web application then you can use an Elastic IP to associate with the domain name in your DNS provider registry.  Without an Elastic IP, your instance will have an IP address dynamically allocated that can change.  If you do not plan to use your own domain name then this step can be skipped and you can access your instance using the public DNS that EC2 generates for your instance.  To obtain and configure an Elastic IP:

  1.  In the EC2 management console, select Elastic IPs
  2. Choose Allocate New Address
  3. Once the address has been allocated, it can be associated with your Linux instance.  In the console, select Instances.
  4. Select your Linux instance and under the Actions menu, choose to associate an Elastic IP address.
  5. Associate the Elastic IP that was created.

The next step in the setup is to start the Linux instance if not already running.  This can be done from the EC2 console page by selecting the instance and pressing Launch Instance.  After it is running, it is time to connect to the instance.  There are a number of ways to do this, depending on your environment.  The AWS documentation explains your choices.  See here: Accessing Instances →

Once you have access to the Linux instance, either via Putty, SSH or MindTerm, you are ready to deploy your Play application.

In order to prepare the application for deployment, a distribution file should be created.  This can be accomplished with a single command at the Play console.  From the console (using Play version 2.2.0), enter the “dist” command.  The result will be a zip file in your project’s target/universal folder.  That zip file can now be uploaded to your Amazon Linux instance using SCP.  Depending on your environment, choose an SCP client for this task.  Note that the MindTerm SSH client that can be launched from the EC2 console includes an SCP plugin.

Once the application file has been uploaded, it can be unzipped.  We created a script called updateit to facilitate this task.  To install this script:

  1. copy file to /usr/bin
  2. chmod +x /usr/bin/updateit to ensure that it is executable
To use the script, use this command:  updateit

Figure 3: updateit script file

While the Play dist command does include a script to start the application, something more is needed to have your application start automatically if the instance is restarted.

We created a script file called playit to start and stop our Play server on the Amazon EC2 server instance.  To install the script:

  1. copy file to /etc/init.d
  2. chmod +x /etc/init.d/playit
  3. chkconfig –add /etc/init.d/playit
  4. chkconfig playit on

To use the script to start, stop or check the status of the application, use these commands (as the ec2-user):

service playit start
service playit stop
service playit status


  1. It is important if you are using a micro instance (which only has 615 MB of memory), to restrict Play to use less than that (see -mem 512 flag in the script file).
  2. For production use, you probably want to have WHERE defined as null to avoid an unneeded log file, but it can be useful during the early days to spot installation issues.

Figure 4: playit script file

The next step is to remap the ports on the Amazon EC2 instance so that the HTTP port (80) is redirected to the Play default port (9000).
To do this we need to add some rules to the iptables firewall rule set, which can be done by editing the iptables file in /etc/sysconfig.

Figure 5: iptables file

Now you should be able to start your Play Framework application and access it via your browser.  You can test this by accessing it using your instance’s Public DNS, which looks something like this:  So launching this url should bring you to your application`s home page:

If you wish to associate your own domain name with this instance, you must now update the DNS registry for your domain to point to the Elastic IP created earlier.  After that, you should be able to access your application using

That wraps up a basic guide to getting a Play application deployed, setup and running on an Amazon Linux EC2 instance.  In our case there remained a couple of problems that we still needed to solve.  One concern we had was that we needed a way to update our application with minimal impact to our users.  A slightly more subtle problem was that we wanted to protect some of the pages in our application using HTTPS.  So, we wanted to be able to redirect any HTTP requests for those pages to use HTTPS.  Stay tuned, we will add follow-up posts on these topics shortly.


Leave a Reply

You must be logged in to post a comment.