Testable Cloud Security

Testable Cloud was carefully built with security and data privacy as a priority at every step and in every part of our architecture.

This page outlines some key aspects the Testable Cloud security. If you would like to fully self-host our platform yourself take a look at Testable Enterprise.


Testable LLC holds an active ISO 27001 certification which can be furnished on demand for customers. Complying with this standard ensures our Information Security Management System is in line with the latest best practices.


Traffic Encryption

Testable Cloud exposes several endpoints for public use (listed below). All endpoints use TLS v1.2 to encrypt traffic.

  • testable.io (Marketing Site)
  • a.testable.io (Product Site)
  • api.testable.io (API)
  • agents.testable.io (Test Runner Coordinator)
  • selenium.testable.io (Remote Selenium Grid)
  • cdp.testable.io (Remote Puppeteer Grid)
  • playwright.testable.io (Remote Playwright Grid)
  • proxy.testable.io (HTTP Forward Proxy - Record and Replay)
  • *.gateway.testable.io (Reverse Proxy - Record and Replay)
  • docs.testable.io (Documentation Site)
Data Encryption

Testable’s databases are encrypted at rest and in transit. The databases are shared tenancy with access controls to ensure users and our support staff can only access their own data or the data they need.

Enterprise customers can further encrypt their parameters, scripts, uploaded files, output files, and traces using their own encryption key. This additional layer ensures that should you cut off our access to the encryption key, any data we have related to your account will become useless.

Customer’s provide Testable their encryption key by setting it up on either AWS, Azure, or Google Cloud. Read our encryption guide for more details.

Network Topology

Testable Cloud is deployed primarily in AWS N Virginia with long-running test runners also deployed in other regions and per-test test runners supported in all AWS, Azure, and Google Cloud regions.

Testable Cloud is deployed in such a way as to minimize as much as possible what is publicly accessible. Nearly everything is deployed to private subnets that cannot be accessed from the internet. The only exception are the AWS ALBs to expose the endpoints mentioned above which then route requests to services that sit within our private subnets. The private subnets expose a minimal set of ports and are only accessible from our public subnets.

Please get in touch with your account manager if your team would like to see a diagram of our production architecture.