This document is an overview of Watu's infrastructure and procedures. If your inquire is not covered, please, open a support ticket for us and we'll address it.


Watu runs in Linode, a company trusted by more than 400k customers that is HIPAA and PCI compliant. Specifically we have our servers located in the London datacenter. We have one database server and many web servers (we can add more web servers dynamically to cope with growth and traffic spikes). We use Linode's load balancer to distribute the traffic between the servers. We use puppet for all the configuration of our servers so we can spawn new ones immediately.


Security

We take security very seriously. We don't add security later, we make sure our code is security from the day we write it. The way we do that is by following a well known guidelines. All our developers are security aware before joining the company or spend time learning about security when they do.


These are some of the guidelines we follow at Watu:

  • We don't write security related code unless we have to. We instead relay on third party tools and libraries that are used by literally thousands of organizations and kept up to date and patched.
  • As a matter of policy we never reveal passwords (this is actually mathematically impossible for us as we store them hashed with bcrypt) or any other confidential information. Sometimes we get messages asking us to reveal information about an account and as far as we know this is always people owning the account, but we have to decline and tell them to visit Watu by themselves to see that information even when that's more annoying than just answering the question.
  • We use SSL everywhere. When you visit a Watu page you are immediately switched to a secure encrypted channel. We do SSL termination at our load balancer.
  • We use HTTP-only and Secure cookies for our session.
  • We keep all our servers automatically up to date using cron-apt.
  • We keep all the libraries Watu uses up to date manually as this requires testing the new versions work well with Watu.
  • We are subscribed to various sources for CVE (Common Vulnerabilities and Exposures) and when something might affect us we address it as a matter of high priority.
  • We use the popular programming language Ruby, specifically the latest version of Ruby 2.1.
  • We use Ruby on Rails, a framework used by thousands of companies and organizations. We are using the version 3.X which is kept up to date for security issues.
  • We regularly check the security status of our code with Bundler Audit and Brakeman Scanner.
  • We use Sorcery for handling user authentication. This means that:
    • We hash passwords in an unrecoverable manner using the bcrypt algorithm.
    • We have brute force protection.


Backups

When it comes backups, there's two different bodies of data we backup. The most critical is the database and the other one is the uploaded files including pictures. 


Database

The database is backed up daily by means of a server snapshot. All our servers are snapshoted daily so recovering them will be quick. We keep three copies of these snapshots:

1. The most recent snapshot

2. A week old snapshot 

3. A two week old snapshot 


On top of that, we make a snapshot before performing any potentially problematic maintenance operation and generally we just keep it until the next time. These backups are kept in the London datacenter.


The database is also dumped daily into a file that is then copied to Amazon S3 over an encrypted channel, a solution thousands of companies around the world trust for backups. In Amazon we keep a daily snapshot of the last 2 months and at least a weekly snapshot before that forever (since the day Watu launched).


The files

We store several millions of files. Backing them up is no easy feat. For example, Linode's snapshot system that we use for the database and fast recovery just can't deal with this amount of files. The files are stored in a Gluster distributed file system across all our web servers and each web server has a backup process running continuously backing them up to Amazon S3. The mean time to backup of a single file is around 3 days at the moment.