An approach for handling a maintenance interruption or update of a live Play Framework application.


A lightweight approach for updating a live Play Application

In our previous article (Here →) we described how to set up a PlayFramework-based application on an Amazon EC2 Linux instance. Once the application is up and running it is inevitable that the next thing that you will want to do is update it. Unfortunately in the current environment, stopping the Play application will leave your site unreachable by your users, resulting in a browser error message when they attempt to navigate to it.

There are a number of ways to solve this problem. One approach is to front-end your Play Application with a load balancer, allowing you to switch between your current application and a newly deployed version. If you are using a single EC2 instance to run your application, this could be achieved by installing an Apache Web Server and configuring it for load balancing. This would allow you to switch from a Play application running on one port to another on a second port by updating the cluster membership configuration. However, if you don`t want to install and configure a load balancer on your instance, there are alternatives.

In this article we describe a light-weight approach that allows you to switch from the production application to a second small Play application that can be used to tell your visitors when the site is under construction. This can be acceptable for short periods of downtime while performing an upgrade or fixing a problem with the site.


This is a strategy we have used in the early stages of an application’s development in order to operate within the AWS free usage tier, but then realized that it could be useful in other Linux-based hosting solutions (GoDaddy, BlueHost, etc) as well.   Having the small “UnderConstruction” Play application was important since there was not enough memory available to run two versions of our application simultaneously on one EC2 T1 micro instance.  It may also be useful to have the distinct UnderConstruction mode to allow maintenance activities to be performed even if there are no resource constraints.  Otherwise, virtually the same technique described in this article could be used to switch between two versions of the main Play application.

Figure 1: Using iptables to switch between two Play applications

The Play framework allows multiple applications to be run at the same time each communicating through their respective ports.   In an earlier post (Here →) we used iptables on our Amazon EC2 Linux instance to remap from the default Play port of 9000 to the standard http port 80 expected by most web users.

Figure 1 shows a pictorial representation of how we combine these two properties to implement our “Under Construction” strategy.   When we want to perform site maintenance we reconfigure iptables to map port 80 to port 9001 which is being monitored by a second small Play application.

We then created a lightweight, single page Play application with a message for our users that the site is temporarily down for maintenance work. 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.  In our example we unzipped the application into the /home/ec2-user/maintenance directory.

To make it simpler to switch maintenance mode on and off, we wrote a small script file called maintenance (see Figure 2)

copy the file to /usr/bin
chmod +x /usr/bin/maintenance

maintenance start
maintenance stop


  • The port is defined to be 9001 to override the Play default of port 9000  ( -Dhttp.port=9001 )
  • memory is set to a small number, since the “Under Construction” play application is likely pretty small, and it needs to be able to co-exist on what might be limited available memory if using an Amazon EC2 micro instance. ( -mem 32 )

 Figure #2 maintenance script file

The maintenance script requires two versions of iptable files (iptables-9000 & iptables-9001) to be created, as it replaces the default iptables file with one specific to the ports being remapped.

To create the files do the following as sudo:

  • save a copy of /etc/sysconfig/iptables to /etc/sysconfig/iptables-9000
  • save a second copy of /etc/sysconfig/iptables to /etc/sysconfig/iptables-9001 and then edit it to replace the remapping of port 80 to port 9001 (see Figure 3)

Figure #3 iptables-9001 script file

 The end result is a simple mechanism that can be used to start and stop maintenance mode so that users will see an explanatory message while the site is being updated.


Leave a Reply

You must be logged in to post a comment.