Sauce Labs Blog

Worth mentioning that Saucelabs takes security very seriously. If anything in this email is true (I can't speak to it at all), then I wouldn't use BrowserStack for testing anything connected to my systems. Sauce, on the otherhand, destroys every VM after each use, guaranteeing that you get a known good (and uncompromised) state for each usage. And unlimited manual testing is $10 a month, which is a great price. (Disclaimer: Former Saucelabs employee. Currently doing other things unrelated and don't keep in touch, but I definitely know the Sauce claims in http://sauceio.com/index.php/2011/09/security-through-purity/ are true.)

I'm one of the developers in charge of the Sauce Labs' backend and thought I should chime in and confirm with you that that's not the case with our cloud. Our infrastructure is hosted in our own data center and we've gone to great lengths to never, ever reuse VMs. You can read more about our "security through purity" approach: http://sauceio.com/index.php/2011/09/security-through-purity/

http://sauceio.com/index.php/2012/08/apple-sauce-android-sauce/ https://github.com/saucelabs/mac-osx-on-kvm

Sauce does Mac OS X virtualization using some patches Alexander Graf and René Rebe helped them bring up to date, which they've released (see http://sauceio.com/index.php/2012/08/apple-sauce-android-sauce/). I tried hacking their patches into a recent snapshot of the KVM tree but there were some issues. I sort of wonder if anyone else has managed to get their code working, because it would be a neat hack if so.

As a customer, security is important when you are testing your internal, firewalled, infrastructure. This is one of the main reasons Sauce Labs (where I work) gives every test its own VM that's destroyed afterwards. Using a shared or reused VM opens the door to malicious code running in the background. There's an article devoted to this topic here: Security Through Purity — http://sauceio.com/index.php/2011/09/security-through-purity/

Now that is a reasonable concern. Keeping db hardware happy is certainly an expensive undertaking. I think I'm more used to the arguments like the one from Sauce Labs, where the VP whines, "What are schemas even for? They just make things hard to change for no reason. Sometimes you do need to enforce constraints on your data, but schemas go way too far," [1] and then goes on to say that his company is moving from using CouchDB to using MySQL as a key-value store with serialized JSON (data integrity and performance be damned -- I mean, really, the thought of converting millions of values in a table to objects just to run a home-grown MapReduce function on them when you could just LEARN HOW TO USE MySQL is pretty much the most insane thing I've ever heard lol). Do you have any experience with Amazon RDS? I haven't tried it; I guess my concern would be the same as any other AWS product--they tend to fail catastrophically from time to time. Then again, if you're doing cloud NoSQL through Amazon, you're going to run into the same issues (see: Reddit). [1](http://sauceio.com/index.php/2012/05/goodbye-couchdb/)