Colophon for the GOV.UK beta

We’ve been cataloguing the technologies and tools we’ve used in producing the beta of GOV.UK. Naturally our technology stack is always evolving, but this list captures its state at the moment when the beta was released. You can see the equivalent list for here.

We’ll be updating this post with links to more detailed blog entries on various tools and technologies over the coming days.

Hosting and Infrastructure

  • DNS hosted by
  • Servers are Amazon EC2 instances running Ubuntu 10.04LTS
  • Email (internal alerts) sending via Amazon SES and Gmail
  • Miscellaneous file storage on Amazon S3
  • Jetty application server
  • Nginx, Apache and mod_passenger
  • Jenkins continuous integration server
  • Caching by Varnish
  • Configuration management using Puppet

Languages, Frameworks and Plugins

  • Most of the application code is written in Ruby, running on a mixture of Rails and Sinatra
    Rails and Sinatra gave us the right balance of productivity and clean code, and were well known to the team we’ve assembled. We’ve used a range of gems along with these, full details of which can be found in the Gemfiles at
  • The router is written in Scala and uses Scalatra for its internal API
    The router distributes requests to the appropriate backend apps, allowing us to keep individual apps very focussed on a particular problem without exposing that to visitors. We did a bake-off between a ruby implementation and a scala implementation and were convinced that the scala version was better able to handle the high level of concurrency this app will require.


  • MongoDB
    We started out building everything using MySQL but moved to MongoDB as we realised how much of our content fitted its document-centric approach. Over time we’ve been more and more impressed with it and expect to increase our usage of it in the future.
  • MySQL hosted using Amazon’s RDS platform
    Some of the data we need to store is still essentially relational and we use MySQL to store that. Amazon RDS takes away many of the scaling and resilience concerns we had with that without requiring changes to our application code.
  • MaPit geocoding and information service from mySociety
    MaPit not only does conventional geocoding (what’s the lon/lat for a postcode) but also gives us details of all the local government areas a postcode is in, which lets us point visitors to relevant local services


  • HTML & CSS (naturally), with elements from HTML5 & CSS3 where appropriate
  • Javascript uses jQuery, jQuery UI, Chosen, and a variety of other plugins
  • Gill Sans provided by
  • Google web font loader


James Stewart is Tech Lead on the beta of GOV.UK. You can follow @jystewart on Twitter


  1. Fantastic information – and interesting implementation.

    Are you planning on releasing (either stubbed/genericised) your various application configurations/VCL/etc, as well as your code? I had a scan through GitHub and couldn’t spot it.

    I’m also quite interested in your deployment approach – the choice of mod_passenger vs Unicorn, if you already have nginx in there. Are there any plans to expand on that kind of information?

    1. We’ve mostly used passenger because we had it in place early on and the pace of development didn’t leave time to switch to Unicorn. Switching to Unicorn is high on the list of things to work on post-release as it’ll help us simplify a few dependencies and reduce disruptions around deploys.

      The varnish config, a few bits of application config and our provisioning scripts are private at the moment as we’ve got quite a lot of sensitive information in them. We’re going to try our best to get as much of that public as we can, but it’s going to take a while to get there as there’s a lot to work through.

      There’s a blog post coming soon on how we’ve managed provisioning servers and our use of puppet, but if you have any specific questions I’m happy to try and address them here or we can use them to guide future blogging…

      1. Thanks Ryan. Passenger Enterprise is an interesting option but we’re actually in the middle of migrating all the ruby apps to use Unicorn as it fits much better with the way we’re now running our servers.

        One of the team has recently written a tool to help us use unicorn with upstart – – which is working very nicely.

  2. Am so excited to see such a great set of technologies in use. Very cutting edge, and more organizations would do well to try some of these things out. I also think using a decent tech stack is a helpful in attracting and retaining good techies to work on your sites, which is very important given how hard it is to find people these days.

    1. Great. Thanks for sharing that link. Out of interest, why did you choose to develop your own search engine rather than use something like Lucene/solr?

  3. Out of interest, why Which subscription did you go with? We’re currently debating between Dyn and DnsMadeEasy…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s