Cloud breaks, your app shouldn’t

Cloud Breaks

This week we all witnessed another major cloud outage. This time it was Microsoft Azure. According to Microsoft, the outage was caused by an undetected bug that was rolled out to production affecting the block storage used by almost all Azure services.

Cloud outages happen. There has been too many of them to keep track of. Not all outages are major but every day we see many small incidents affecting a small number of services.

I think the best way to mitigate the risk of cloud outages is to first accept that no matter how hard cloud providers try, there always going to be issues affecting their customers availability and performance. Once we accept that as a fact of life we can try to find a way to protect ourselves against it.

Hybrid Cloud, the hype and the reality

Hybrid cloud, where you can weave multiple cloud provides into one infrastructure has been talked about for a long time now. Frankly I have not seen any successful production stacks being deployed on a hybrid cloud, nor have I seen much desire in doing so from customers.

I believe this is because most hybrid cloud solutions focus on merging multiple clouds into one infrastructure and not attempting to build an immutable infrastructure setup that can be replicated quickly and easily on any cloud provider, which I think is the best way to leverage multi cloud providers to achieve high availability and performance.

Immutable stack is one that is not modified but rebuilt every time there is a need for a change. If you can build your entire stack quickly enough on any cloud provider, you can switch your users away from the one suffering from outages in an “acceptable” length of time, depending on the nature of your business.

Discipline requires tools

Building an immutable infrastructure requires both discipline and tools. Good tools help people enforce good practices easier.

Instead of policing your devs not jump on servers and run shell commands directly, you can make it very easy to script out what they want done on a server. Instead of constantly asking everyone to write rollback scripts for their migrations, make it easy to redeploy the whole stack from scratch as quickly as possible.

Not every solution is applicable to every situation. There will always be situations when you need to write migration scripts or rollback ones. We will always need to put out fires or debug issues by having direct access to servers. But let’s focus on the majority of cases. Let’s build our tools and therefore disciplines for the 80% cases instead of getting hung up on the 20% of the cases.

What makes an immutable stack?

Few principles can help us with achieving immutability in our infrastructure:

  1. Limit the “sources of truth” to as few as possible.
    If you have your application code to run on servers, Chef scripts to build and modify those servers, VM images that are built with your build system and database migration scripts, then you have 4 sources of truth. They can, and will, go out of sync over time. You can police this and put safeguards in place to minimise the possibility of this, but it’s always better to have fewer “sources of truth”.
    Moreover, you can be sure that migrations never run end to end from start to finish. Dependencies change and components get updated so often that the migration from state A to state B for your servers 6 months ago is almost guaranteed not to run on fresh new servers now.

  2. Strive to make your data store as reproducible and possible. This sounds easier than it is and can be the most expensive part of your immutable infrastructure. Many Ops teams consider data outside of the remit of building infrastructure. We simply don’t have good tools for data + schema version control.
    Taking pre-deployment backups is one strategy which requires good data store design and backup policies which can be performed quickly enough. Beyond databases, other data stores (like S3 or other cloud based block storage systems) can have version control and rollbacks.
    However when it comes to resilience against cloud outages, multi cloud data availability is the most important part of the solution. Setting up database replications across cloud providers and data centres can help with that aim. In this scenario you constantly keep your data “warm” in multiple locations, prepared for a failover.

  3. Make sure you can redirect traffic as quickly as possible. Using fast response DNS services with low record TTL can help in many cases, although not everything between your servers and your users is going to honour TTL values. However in many cases a combination of low TTL DNS records, traffic proxy services like Cloudflare and maximising the use of CDN for your static assets can help with a vast majority of cases.

Combining these three principles can get you a long way in your quest for high availability and protecting you again cloud outages. At Cloud 66 we build tools to help you with building immutable infrastructure and would love to hear about your experiences with building high availability applications.

Codeanywhere, Deploy anywhere

Today we are announcing our partnership with a great company: Codeanywhere.

Codeanywhere lets developers code in the cloud using their awesome online code browser, code editor and sanbox development boxes, complete with full shell access, syntax highlighting and syncing with Dropbox and Google Drive.

Codeanywhere IDE

Cloud 66 + Codeanywhere

Codeanywhere makes it extremely easy to develop in the cloud, and now you can deploy your code directly from your Codeanywhere DevBox to any cloud provider with a single line using Cloud 66.

Making this work is very simple:

$ cd ~
$ wget -O cx
$ tar -xvf cx

Now Cloud 66 Toolbelt is available under a directory named with its version. You can copy it to a directory that is in your $PATH like /usr/local/bin

$ sudo mv ~/cx_0.1.10_linux_amd64/cx /usr/local/bin

Now you can initialise the Toolbelt and link it to your Cloud 66 account:

cx init  

Follow the instructions and your Toolbelt is linked to your Cloud 66 account.

Now you can use the Toolbelt directly from your Codeanywhere DevBox to deploy your app.

If you have used the Git Repo address of your code when starting your DevBox, you can deploy your stack from ~/workspace:

Codeanywhere Git URL

cx redeploy  

This does not need the -s <stack> since your stack is deployed from the same Git repository as with ~/workspace.

For more information on using the Toolbelt, checkout Cloud 66 Toolbelt Documentation.

Happy coding! on Cloud 66

This is a guest post by Jacob from, who recently moved their infrastructure over to AWS with Cloud 66 management. They managed to reduce their monthly costs by 90%, while drastically improving performance. This is their experience.


Hi, my name is Jacob and I am an engineer at Playlist, an internet radio streaming company. In my role, I wear many different hats and touch many different systems encompassing backend, frontend, and devops. Last month, we successfully migrated our Ruby on Rails primary application from Heroku onto AWS EC2 hardware using Cloud 66, with great success. So, I wanted to share some of our story.

Since September of last year, we were utilizing Heroku to host, our main application. We had migrated from entirely custom servers with custom bash scripts for deployment to Heroku for the ease of rapid deployments, and also for the ability to quickly attach addons to our application (like Redis). We also appreciated the ability to scale up our app serving capacity as our userbase grew. Being able to run git push to trigger deployments made everything quick. However, as time progressed, cost and network performance really began to hurt.

The Problem


Running our app was expensive on Heroku. Our hosting bill started out in the hundreds of dollars per month and steadily grew towards thousands per month. In May of 2014, we launched a more complex backend that nearly tripled our costs.

At the peak of the problem, we were running an average of 24 2X dynos (!) per day in order to keep the request queuing time down. Anything lower and requests would start to pile up and response times would begin to climb, and we could literally watch the number of concurrent users in Google Analytics plummet 80%. There were multiple pain points with our backend that could have potentially been solved by a rearchitecting to use more background processes and perhaps something like websockets, but with a small team, we really could not afford to stop development on the next backend in order to patch the current one.

We began building the backend for the next major version of our products. By using Go and incorporating a lot of the lessons learned from the first backend, it was considerably more performant. But in the meantime, we really needed to do something with the Rails app until we could complete and test the new backend.

The Solution

I had heard of Cloud 66 about two years ago on Hacker News, but had never really given it a serious try. After some research, I decided to spin up our Rails app on EC2 using Cloud 66 to see if it might be a viable alternative to Heroku. It was painless to set up. After it analyzed our application, I edited the environment variables with our custom values and told Cloud 66 not to manage the database (we use Amazon RDS), and Cloud 66 built our first server. Customer support was super helpful, especially via chat, and I increased our server count to three (on c3.large instances). Once I was confident that the application was running correctly, I switched our DNS record at CloudFlare, and instantly we were live in production.

Side note: the Cloud 66 toolbelt is very useful. During the migration, it was easy to keep track of the logs with the cx tail command.


The blue bar between 10/21 08:00 and 10/21 16:00 is our switch to Cloud 66, and the difference in web app performance was immediately noticeable. Plus, this was with only 3 servers (instead of those 24 dynos). Our number of song plays per day (an important metric to us) increased almost immediately by about 15%, demonstrating again that web app performance directly impacts key metrics.

Cost was drastically improved. We increased our server count to 4, just to be safe, and with AWS reserved instances, our monthly costs are now less than 10% of what they were on Heroku. App performance is significantly more stable and response times are lower.

Additionally, we did not lose the convenience of being able to deploy with git, and actually improved the workflow by using the Cloud 66 redeploy hook with our continuous integration service, Circle CI. Now if our tests pass, deployment is automatic. Check out the Github Flow for more information on our development process.

Going Forward

We really love the experience with Cloud 66. I was a little disappointed that we would not be able to use Cloud 66 when we switch to the non-Rails Go backend. However, Cloud 66 is working on supporting Docker, so we are happy we will be able to package our app into a container and continue to take advantage of the awesome features and support of Cloud 66.

Another feature I am excited about utilizing is Elastic Addresses - we can spin up a backup deployment on another cloud (Digital Ocean, Rackspace, etc.), and then if (/when) AWS us-east-1 goes down, we can failover to the other cloud.

Overall, we have been very happy with Cloud 66 for our application deployment. If you have not tried it out, I would highly recommend it.

Continuous delivery with Codeship and Cloud 66

Codeship and Cloud 66

We're really excited to announce our partnership with the awesome guys at Codeship! We love the idea of building for the builders (aka developers), and by helping developers focus on their code and automating its delivery, they can do more of what they love.

Why Codeship?
Our partnership with Codeship is founded on the idea of making lives easier for developers, and this integration does exactly that.

By triggering automated tests on your code when you push your code, you can deploy with confidence. Your users will love the speed at which your new features are rolled out!

How does Cloud 66 integrate with Codeship?
Integrating Cloud 66 with Codeship is as simple as copying and pasting a URL!

Once you've deployed your stack with Cloud 66, you'll see a Redeployment hook URL on your Stack information page. When you visit your project on Codeship, simply click "Set up Continuous Deployment", select "Script" and paste your URL into the field in this format:

curl -X POST -d "" [Redeployment hook URL]  

We're working hard to make this process simpler, and would love to hear your feedback! We're all about making your life easier, and we're all ears :)

Two new awesome features

Today I am happy to announce two new features: Individual Linux Users and RabbitMQ AddOn.

Individual Linux Users

Until now, a single shared user (the one used by the cloud provider) and SSH key was used for both deployments and all SSH accesses by the members of your team.

Starting from today, all new stacks will have an individual and unique user for every memeber of your team.

This means if a someone leaves your team, their access to servers will be revoked automatially without your intervention. And any new addition to your team will automatically be commissioned on all of the applicable servers based on the priviledges you assign them.

This feature is transparent to all users and will be automatically used by the toolbelt without any change. If you want to use it directly with your own SSH terminal, downloading the SSH key from the server page will download your own individual SSH key and not the shared one.

RabbitMQ AddOn

We just added RabbitMQ to the list of our addons. You can now install a managed instance of RabbitMQ on your stack with a click of a button.

Until now, RabbitMQ was installed on stacks only if it was used in your Rails, Sinatra or Padrino stacks. Now you can add it as a standalone part of your infrastrucutre after the stack has been created.


Connecting Stripe to Xero

Stripe is our payment provider. We love the simplicity of Stripe and the convenience that it brings. We are also big fans of Xero, our accounting software. As a company with presence in both US and UK, we needed a way to connect Stripe to Xero to allow us calculate the correct taxes and make our life easier when it comes to reconciling our revenue with our bank statements.

Taxes, taxes, taxes

Every time you charge a customer in Stripe it creates a unique payment in the system. This payment is linked to a single customer. Stripe then pays the total of all the payments (minus their fees) to your bank account under a single transaction.

Imagine the following scenraio

 Customer    | Country | Payment
ACME Inc     | US      | $10.00  
Blimey Ltd   | UK      | $9.00  
Ze Corp GmbH | Germany | $8.00  

2 days after these payments are taken, you will have $27 paid in your account. This is all good unless you are either:

  1. You are a EU company and need to charge VAT for EU customers but not the non-EU ones
  2. You are a US company and need to charge different tax rates for different states.

If you are like us and use Xero, you can setup different accounts for different VAT or tax rates. For example you can have the following income accounts:

 Account | Description  
 4000    | Sales UK     
 4001    | Sales EU     
 4002    | Sales non-EU 

or even more detailed accounts spliting sales and support (as they are taxed differently).

The big question here is How do I split that $27 between these accounts?

When you file your VAT return (or US sales tax) you should split that amount like this:

 Account | Description  | Amount 
 4000    | Sales UK     | $9.00  
 4001    | Sales EU     | $8.00  
 4002    | Sales non-EU | $10.00 

You definately don't want to do this manually every 2 days!

APIs to the rescue

We built a connector that connects Stripe to Xero and splits the payments into the correct account.

Step 1 - Create a Xero developer account

Go to Xero developer resources page and get started. Xero gives you a Demo account as well so you don't mess up your real accounts.

Step 2 - The connector

require 'stripe'  
require 'xero_gateway'

# methods here are called only by Stripe
class PaymentHookController < ApplicationController

    XERO_ACCOUNTS = { :no => 4004, :eu => 4002, :uk => 4000 }

    # called by transfer.paid event of stripe
    # NOTE: for now it only works with product revenue. Support revenue needs to be identified and invoiced differently
    # NOTE: This will require xero private key to be available in the home dir
    def transfer_paid
        raise ActiveRecord::RecordNotFound if !custom_authenticated

        if params[:type] != 'transfer.paid'
            # we are going to accept this as valid but not follow through on our side. this way Stripe will not retry
            render :json => { :ok => true, :message => 'not a transfer.paid event' }

        Stripe.api_key = Configuration.stripe_private"Received Stripe transfer.paid callback with payload #{params.to_json}")

        line_items = []
        # get a list transactions within this payment by calling back. For some reason the payload doesn't have all of them
        transaction = Stripe::Transfer.retrieve(params[:data][:object][:id]).transactions.all(:count => 100) # need to do this to get all transactions
        tx = transaction[:data]
        tx.each do |item|
            # find the transaction
                # we don't need to file Stripe charges
                next if item[:type] != 'charge'

                # get the charge
                charge = Stripe::Charge.retrieve(item[:id])
                # get the customer
                account = Account.find_by_stripe_customer_id(charge[:card][:customer])

                if account.nil?
                    Rails.logger.error("Account not found for #{charge[:card][:customer]}")
                    Rails.logger.debug("Adding line item for charged of customer #{}")

                line_items << { 
                    :description => "Usage charge for customer #{} CH:#{charge[:id]} TX:#{params[:data][:object][:id]}", 
                    :account_code => XERO_ACCOUNTS[account.vat_category], 
                    :unit_amount => item[:net].to_f / 100.00
            rescue => e
                Rails.logger.error("Failed to retrieve Stripe charge #{item[:id]} due to #{e}")

        if line_items.empty?
            Rails.logger.error("No line items were created")
            render :json => { :ok => false, :message => 'No line items created' }, :status => 400
        end"Creating invoice in Xero")
            gateway =, Configuration.xero_key, File.join(Dir.home, 'xero.pem'))
            # create a xero invoice
            invoice = gateway.build_invoice({
                :invoice_type => "ACCREC",
                :due_date =>,
                :reference => "Stripe Invoice for Transfer #{params[:data][:object][:id]}",
                :line_amount_types => "Inclusive"
   = 'Stripe'

            line_items.each do |item|
                invoice.line_items <<
                :description => item[:description],
                :account_code => item[:account_code],
                :unit_amount => item[:unit_amount])

        rescue => e
            Rails.logger.error "Failed to create invoice due to #{e}"
            render :json => { :ok => false, :message => e.message}, :status => 500

        render :json => { :ok => true, :message => 'Done' }


  • custom_authenticated is a method not defined here. It returns true if the call can be authentiacated. You can use your prefered way to make sure the call is made by Stripe.
  • You need to make sure your Xero API pem key is accessible by the code (under user home directory in this sample)

What's happening?

The connector is simple. It gets hit with a POST load (webhook) by Stripe. It then parses the payload of the webhook and looks up each of the customers behind every payment that made up the transaction in our database to detemine their VAT situation (or US sales tax one as an example). It then uses Xero API to file each payment under the right account number.

Step 3 - Push it up

This is a Rails controller example for the connector. You can put it in your app, or split it into a smaller app hosted on Heroku or your own server with Cloud 66.

Step 4 - Hook it up to Stripe

Now that the connector is live, you can add a Web Hook to your Stripe account. The webhook will be hit everytime Stripe transfers money to your account and the connector will split the amount into its constituencies and file them against the correct Xero account.


Measuring Customer Happiness

There was a time when I could send a personal email to every single new customer who had signed up for Cloud 66 and talk to them about their business, code and other cool things. It was great to know our customers personally, know what they do and what they are looking to get out of Cloud 66. I still know many of our customers by first name and try to catch up with them on the phone or Skype every now and then.

But we have grown so much over the past 12 months that I cannot keep up with our growth and get in touch with every customer personally.

The question I ask myself these days is: How can we continue that personal touch at scale?

There are great tools out there to help with better customer relationship. From email based automation tools like to integrated CRM solutions like Intercom, or support ticket systems like HelpScout.

We use those tools to build more personal welcome emails, drip campaigns or enrich our understanding of our customers by bringing in external sources of information like Facebook, Twitter or Github.

But that doesn’t answer the biggest question we keep asking ourselves: Are our customers happy?

If a customer is paying you, then they are either happy or don’t have other options.

It is rare to have a product that is the only option for a customer (excluding nasty businesses that lock customers in by legal or sometimes illegal tricks). So how would you know if your customer is going to still pay you the next month? How can you measure customer happiness when you cannot get in touch with every single one and use your human judgement?

How would you know if your customer is going to still pay you the next month? How can you measure customer happiness when you cannot get in touch with every single one?

Happiness Metric

Doing a simple search online shows a lot of “Customer Satisfaction Metrics” articles. Most of those are useless. They rely on surveys, “intentions”, “perceptions” or “expectations”.

No one gives honest and accurate answers to a long survey about how they feel about a company. No one can measure intentions, perceptions or expectations. These are mostly ways for consultants to come in, run workshops and hold meetings and generate long reports for no one to read.

We tried building a reproducible analytical way to measure customer happiness. We are software engineers, not human behaviour experts so this is not going to be a scientific exercise or a definitive answer to the customer happiness question. We are still proving our theories and improving our algorithms, but we think it’s worth sharing it with others.

Building a Happiness Score

The first step is to identify actions that customers perform on the product that show engagement. The more engaged customers are with a product, the more likely they are to be happy. We used "last deployment date" as one of our measurable engagement metrics. Based on that we can calculate a last deployment score which is calculated like this:

    def last_deployment_score
        # days since last deployment
        x = - last_deployment_at
        # decay: 1 right after deployment and almost 0 after 15 days
        return Math.exp(-x/5)

This will look like this:

last deployment with decay

Older customers are not necessarily happier customers (although it might be the case for the majority of no-lock-in businesses). Your older customers are more likely to tell you if they are unhappy with the product than very young ones. This makes account life score another candidate to measure:

    def account_life_score
        x = - created_at
        return (20*x)/(15*x+300)

The account life score will increase quickly for the first 60 days of the account life and then goes flat as the account gets older.

account life score

If you have a high churn, you can change this to decrese the score after a while.

Another important factor showing engagement for most SaaS business is "time since last login". A last_sign_in_score can look like this:

    def last_sign_in_score
        # days since last signin
        x = - last_sign_in_at
        # decay: 1 right after signin and almost 0 after 15 days
        return Math.exp(-x/10)

Which would look like this:

last sign in with decay

In this example if a customer hasn't logged in for 35 days, their user happiness score will drop to almost zero.

Overall Happiness Score

A collection of scores for specific metrics can help you identify issues with customers before you lose them. However an overall happiness score is always useful to bring things to your attention.

We did that by simply assigning weighting to each category and averaging the result.

An example could be like this:

    def happiness_score
        return (account_score * 0.7) + (team_score * 0.3)

Normal Ranges

The formulae here are experimental and we are always fine-tuning them based on other interactions we have with our customers. Some of these formulae can get complex so commenting your code is a good tip!

You will start to see the "normal ranges" for each score category as you use them more. This is a good place to use rolling averages and standard deviations as a way to monitor sudden change (like when a customer usage pattern suddenly changes with no warning and you need to reach out to them).

Customer Support Interactions

When we started this project, we thought measuring customer support interactions (support tickets, online chats, etc) could be a good way to measure customer happiness. This is true in the sense that customers care about your product if they are engaging in a support conversation. But this rarely means they are happy. Think of the number of times you sent a support ticket to Facebook or Google. Or when a bug in the product requires a lot of customer interaction. Neither case is an indicator of your happiness or unhappiness with the product.

That's why I don't think using customer support interactions on their own withuot any manually entered meta data is going to be useful to the overal score.

Cloud 66 API v3 is here

Our new API is now released and ready to build awesome apps against!

The new API has pagination, asynchronous calls and much more.

The best part? Personal Authentication Tokens.

Personal Access Tokens

Our API, like many other ones is RESTful and uses oAuth for authentication. We use oAuth 2.0 instead of 1.0 which is much easier to use by clients but still can be very painful, especially is used with commandline tools like cURL.

That's why we introduced Personal Access Tokens.

A Personal Access Token is a simple way to issue a revokable and secure token for your API clients that is also scoped. In a normal oAuth 2 scenario, you need to create a new app and do the whole oAuth 2 dance to get the token so you can use it as Authorization Bearer with your HTTP requests. With a Personal Token all you need to do is to issue a new token, select the "scopes" you would like this token to have access to and use it as the authorization bearer.

Create a new token

Here is how:

  • First, head to "Authorized Applications" under "Account" and click on Create a new Personal Access Token.
  • Give your Personal Access Token a rememberable name and select the "scopes" you would like it to have. For more information on scopes, see API v3 documentation.

New Personal Access Token

  • You can see the token by clicking on the name after it's created.

Use your token

Let's say you would like to have a cURL command that lists all of your stacks. This action will require a "public" scope. Once you have a Personal Access Token with public scope, you can simply use cURL to get the list of your stacks:

$ curl -H "Authorization: Bearer 2ea2032cf6264d50aedb832fbba114788b687eb496ad4ae58226e5adc2d07561"

Replacing the long UUID with your Personal Access Token.

Revoke your tokens

You shoulnd't use Personal Access Tokens for applications writen to work with Cloud 66. Personal Access Tokens are purely there for personal use and should be treated like passwords.

You can revoke the Personal Access Tokens by deleting them from your account.

Customer spotlight: Zibbet

Zibbet image

As a team of developers, we're always intrigued to learn about how people use our service. We try our best to reach out to our customers and see how best we can help make their lives easier. We recently got in touch with the great guys at Zibbet to learn more about how they use Cloud 66.

For those who don't know, Zibbet is a marketplace for awesome handmade and vintage products. They take a firm stance against resellers on the site - which sets them apart from a marketplace like Etsy. When Etsy changed their policy to allow resellers last year, many merchants jumped ship to Zibbet. So many in fact that Zibbet servers struggled to stay up! They previously hosted on Heroku, and recently migrated over to Cloud 66. We spoke with Pavel Kotlyar, the person in charge of Zibbet tech, to find out more.

How did you originally host Zibbet?

Heroku, 5PX (5 passengers per dyno) for web, 1PX for worker + to auto scale in case of unexpected traffic + Heroku Postgres Baku.

What was your reasoning for moving to Cloud 66?

Our application was a brand new rebuild of our old web site, but unfortunately we did not have enough time before the release to optimise it well enough in terms of memory consumption. We also had quite large data to manage, so 6GB RAM on Heroku with 5 processes per dyno was not good for us and we often got errors on Heroku related to memory overflow during peak traffic. We can’t afford to have 1 process per dyno and pay for 25 PXes… So the main reason - we needed more powerful servers with more RAM but at the same time we needed the same simplicity of server operation, setup, scale and management. We don’t have a DevOps or server admin in the team and our developers really like to focus on application development rather then on servers management and maintenance.

How did the move affect your monthly hosting bill?

It was a pleasurable surprise - we’ve got much more powerful servers with Digital Ocean and Cloud 66 and our monthly cost literally became 50% cheaper than on Heroku with Heroku Postrges.

How did you go about migrating to Cloud 66?

We had some small issues related to Procfile settings as for example Redis should not be there, because it automatically running with Sidekiq and passenger already installed in the stack. But overall it was very easy and the support was very helpful as well as the documentation. The migration of the database, thanks to Cloud 66 documentation was smooth and easy as well, we’ve migrated 7Gb database from Heroku and imported it to our Postgres server in 15 mins following the steps from the docs. So the downtime was about 20 mins including DNS changes.

Did you experience any issues with the move?

We had very few issues and as mentioned, it was Procfile settings and some issues related to our CI deploy configuration settings. I was able to run our Heroku configuration very quickly.

Is there anything else you'd like to add?

We are happy customers, so far so good. We even don’t need the support anymore since everything is working just fine. A few days ago we decided to rebuild our search with Elasticsearch and with Cloud 66 we can setup Elasticsearch server with one click, this is awesome!

We're really happy to be working with the great people at Zibbet, and always love to hear from our customers. If you're working on something cool and would like us to share it, get in touch with us!

Announcing OS level security monitoring

The recent security vulnerabilities found in bash (shellshock) again have caused sleepless nights for many developers and sysadmins. We had similar issues last time when Heartbleed was found to be affecting many servers.

Reacting to a situation like this usually consists of three steps:

  1. Checking to see if you are affected
  2. Finding a way to fix the issue
  3. Rolling out the fix with minimum disruption

Am I affected?

This is the first step. It usually involves searching the net, reading forums and threads to find the most reliable way to check if a server or application is vulnerable to a specific threat.

How to fix it?

Once it is known that a server is vulnerable to a security issue, the next step is to find a fix. This usually involves finding the right patch for the OS, the fixed version of a component or gem.

How to roll it out?

Now that we know how to fix the issue, we need to find out how we can roll it out as quickly as possible with as little diruption to our customers.

How can Cloud 66 help?

Everyone who is deploying a Rails, Sinatra or Padrino stack on Cloud 66 benefits from automatic OS updates as well as an option to roll out fixes to more sever issues during deploy with "Apply Security Upgrades" option on the deploy menu.

Our StackScore also keeps monitoring your overall infrastructure setup as well as some parts of the app for known security issues.

OS level security monitoring

We are pleased to announce that from today we are also checking all Cloud 66 deployed servers for known security issues at the OS level (like Shellshock) regularly and will reflect the results in your Security StackScore. You will get an email when there is an issue and when automatic security upgrades fix the problem. So no more worries about the possibility of vulnerability and being unsure if a server is left behind.

OS level security monitoring is available to all Cloud 66 customers from today for free!

Stay secure and kepping rocking!