Automating deployment of a containerised Play 2.2.X App with Git + Docker


The idea here is to harness the power of Git hooks and Docker to automatically deploy your Play app in a new Docker container upon a simple git push to your production server


  1. Git and SSH on your deployment server (easy setup instructions can be found here)
  2. Docker installed on your deployment server, as well as a a ‘deploy’ user that will have the Git repository and should be able to access docker (either through sudo or not. Also, I fancy my sudoers file with a bit more organization, so this is what my sudoers looks like [the relevant part at least]).
  3. A template Docker container with Play installed. Taig’s container is based on Play 2.2.3 out of the box, but his Dockerfile can serve as inspiration for your own version of Play (yep, you only have to change the version number)


After playing a bit around with Dokku and googling for a dokku-like framework to do this deployment, I realised that fiddling with Dokku to do just what I needed was too cumbersome for the simple objective that I had in mind.

I did went through other frameworks, but everything seemed too complicated. If you actually have a suggestion on a system/framework to do this, please let me know (it can even be dokku, and actually be more simple than I expected [e.g. a custom buildpack that I don’t know about, whatever, let me know]).

The magic

So, all of the magic involved is done through the use of a Git hook. I got the inspiration of the usage of the lock on another post-commit hook that I found on Github (sorry, this was a bit ago and I didn’t took note of the link) and I also got the idea of making sure that the play compilation occurs before we try to build the new container from this great article with tips and lessons on automating deployment with docker (do read, some other lessons might apply in your case), otherwise we might end up with lots of faulty containers just because we had some fortuitous compilation error.

So, the Git hook follows:
As you can see, I’m compiling the code that I receive to the


directory, replacing the production conf files that are found at


with the ones that are on Git (so that you can easily leave your passwords/API keys outside of Git [yep, you should never do that :)]) The rest of the file is pretty much straightforward. I add the JAVA_OPTS when compiling the code with play stage because the arguments -JXmx=512 and -Xmx=512m do not work to lower the memory usage of the compilation itself, that actually does not need 1Gb of memory to run :) Also, I have set up on the root of the Git repository a Dockerfile that is called into action  with this command:

sudo docker build --tag="joantune/feedburner-prod:$last_commit" .

The Dockerfile that I use is based on Taig’s one, and as you can see, it is pretty basic:

Next steps

I will probably in the future change the build to accommodate a loadbalancer (like Nginx or other) for ‘hotdeploy’ (although with this solution we have only a few seconds of downtime) and more importantly for caching, or eventually even using a CDN for the static files (see this for a great article on how to optimize the serving of static files for play)  .

Anyway, any thoughts on these matters are appreciated. Hope you have found this useful.


GitPlay LogoDocker

Play 2.2.X + JPA + Hibernate – Bootstrapping the Database migration

Play Logo

Hibernate logo


After reading about the issue of migrating databases on apps based on Play 2.2.X with JPA + Hibernate here: and here:

I actually ended up using Flyway and it’s Play extension/plugin to do the DB migrations.

But inspired on other technologies that I used before, and on a comment I saw somewhere on StackOverflow (sorry, no link, I cannot remember where I saw it), I decided to make my life easier by using Hibernate’s automatic schema migration features to bootstrap my migration script.

After a bit of googling I knew that it was possible to do it programmatically or with an SBT/Maven/whatever plugin because of this:

After briefly considering, and giving up on the idea of making a build ‘target’ (call it target, goal or whatever depending on how you build your app). I gave up on the idea because I knew very little about SBT, and I didn’t want to migrate the Play app to Maven, just for the sake of doing this.

So, inspired by this page I wrote the following Plugin instead:

As you can see, it writes the migration script to the “conf/db/migration” + <persistenceUnitName> + “.sql”  file, that can then be used as a base to write your own migration script.

After writing that plugin, I simply had to enable it by adding it to the play.plugins file, after the flyway one (to allow the migration to occur):


I also commented the

<property name="" value="validate" />

line at the persistence.xml file, as the ‘validation’ is now done with the plugin.

If you have any suggestions/comments please feel free to share