Enterprise test automation at scale produces production-shaped data inside non-production environments. Real user records, real payment tokens, and real health identifiers move through the test grid every hour, and regulators now treat that test perimeter with the same weight as the live one.
For teams who have already ruled out public SaaS test grids, the next question is which private tier fits. Every SBOX customer we work with lands on one of three models: Private Cloud on customer premises, Virtual Private Cloud inside the customer's own cloud account, or Managed Private Cloud that Element34 operates in a dedicated single-tenant tenancy. Choosing between them determines which compliance perimeter your test data lives inside and how quickly your team can defend that decision in an audit.
Private Cloud runs SBOX on customer-owned infrastructure inside your own data centre. Hardware is single-tenant and physically dedicated per the NIST 800-145 definition. Selenium, Playwright, and Appium execution stays entirely inside your perimeter. Detail on SBOX Private Cloud.
VPC deploys SBOX inside your own AWS, Azure, or GCP account. Traffic between test runners and applications under test is kept off the public internet using AWS PrivateLink, Azure Private Endpoint, or GCP Private Service Connect. Existing IAM, KMS keys, and SIEM pipelines pick up SBOX telemetry natively. Detail on SBOX on VPC.
Managed Private Cloud is a single-tenant SBOX instance Element34 operates in a dedicated region on your behalf. Not multi-tenant SaaS, not a shared grid. Element34 runs the platform; you keep data isolation and residency guarantees. Detail on SBOX Managed Private Cloud.
| Criterion | Private Cloud | VPC | Managed Private Cloud |
|---|---|---|---|
| Data residency | Absolute, physical | Cloud-region bound | Dedicated region, single tenant |
| Egress control | Zero egress possible | Configurable | Zero egress by design |
| Time to first test | Weeks | Hours | Days |
| Customer ops burden | Full stack | Cloud account only | None |
| TCO shape | CapEx-heavy | OpEx, variable | OpEx, predictable |
| BYO-LLM support | Yes | Yes | Yes |
BYO-LLM matters because the SBOX AI features (test authoring, self-healing selectors, root-cause analysis) run inference on your own model endpoint. In every deployment model, prompts and completions stay inside your compliance perimeter. Compare all three side by side on the deployment comparison page, or download the Private by Design deployment guide for a worked-example walkthrough.
Private Cloud fits workloads where an auditor will not accept software-defined isolation. Classified defence work, Tier-1 European bank and insurer workloads under critical-ICT designation, and national health data programmes all sit here. The physical air-gap of Private Cloud is a different guarantee from the software-defined isolation of VPC.
A European Fortune Global 500 insurer runs 4 million-plus Selenium and Playwright tests a year on a single shared, single-tenant Private Cloud SBOX instance, entirely on its own premises. Sixty-plus development teams across the group share that grid. All test execution and audit logs stay inside the insurer perimeter. Full detail in the case study.
VPC is right when the compliance perimeter is already defined by your own cloud tenancy. Payment merchants already homologated on AWS or Azure, cloud-native SaaS operating under a Business Associate Agreement, and mid-market insurers who need speed without giving up sovereignty all belong here.
Deployment is measured in hours, not weeks. Bring Your Own Key encryption closes most of the residual shared-hardware exposure. Two caveats belong in every VPC conversation: a small noisy-neighbour risk exists for latency-sensitive performance testing, and some regulators will not accept logical isolation regardless of how it is configured. For those cases, escalate to Private Cloud.
Managed Private Cloud fits organisations whose regulatory mandate is real but whose infrastructure team is thin. Healthcare payers, MedTech manufacturers, mid-cap banks, and government contractors without cleared infrastructure staff are the recurring pattern.
The offer is specific. Element34 operates a single-tenant SBOX instance in a dedicated region on your behalf. It is not multi-tenant SaaS and it is not a shared grid. The operational shift is CapEx to OpEx, predictable subscription pricing, and no hardware refresh cycle to plan. The trade-off against on-premise Private Cloud is a small amount of latency and physical-access control, which is why buyers needing sub-millisecond proximity to internal systems still choose the on-premise route.
The regulatory clauses that shape SBOX deployment map cleanly onto the three models.
| Framework | Focus | Model that fits |
|---|---|---|
| DORA (EU financial services) | ICT third-party risk, exit plan | All three, vendor package for Managed |
| HIPAA (US healthcare) | ePHI safeguards, access control | VPC with BAA, Private Cloud, Managed |
| FedRAMP (US federal) | Approved information flow | Private Cloud, Managed with agency ATO |
| PCI-DSS v4.0 | Payments security, scope minimisation | VPC or Private Cloud |
| FDA 21 CFR Part 11 | Records integrity, e-signatures | Private Cloud, Managed |
Two forces will keep reshaping this map: compliance-as-code moving from niche practice to default, with tools like Open Policy Agent and the Cloud Security Alliance Cloud Controls Matrix becoming the reference stack, and dedicated-host offerings inside public regions creating a converged middle layer between VPC and Managed Private Cloud.
Teams who move off a shared public test-automation grid successfully treat the move as a four-step programme, not a single cutover. Classify the data in your current grid by regulatory sensitivity. Pick the SBOX model per business unit using the matrix above; retail digital may land on VPC while core banking lands on Private Cloud. Where the mandate is unclear, run a VPC proof of concept first; the migration path from VPC to Private Cloud is a documented workflow, not a rebuild. Then set a hard cutover date for the public SaaS grid, publish it to engineering, and freeze new tests on the old platform six weeks ahead. That last step is what most teams under-plan.
Watch the Private by Design webinar. A 45-minute walkthrough of a live SBOX deployment migration inside a regulated enterprise, covering the decision matrix above and the vendor documentation package. Access the on-demand webinar.
Or, if you're looking for a one-hour session mapping the three tiers onto your specific regulatory posture and existing cloud footprint, book a working session.
For most Covered Entity and Business Associate use cases, yes, provided the cloud provider has signed a Business Associate Agreement and PrivateLink or equivalent keeps ePHI off the public internet. Where a specific auditor rejects software-defined isolation, Private Cloud is the answer.
No. Every Managed Private Cloud SBOX customer runs on a dedicated single-tenant instance in a dedicated region. Nothing is shared with another Element34 customer at the compute, storage, or network layer.
The SBOX AI features (test authoring, self-healing selectors, root-cause analysis) run inference on your own LLM endpoint under a BYO-LLM configuration. Prompts and completions stay inside your compliance perimeter in every deployment model.
Three tiers: hyperscaler-native dedicated tenancies, colocation-based dedicated infrastructure, and fully managed private-cloud services. SBOX Managed Private Cloud sits in the third tier.
Yes. It is one of the most common SBOX adoption paths. Teams begin on VPC for speed, then escalate specific business units to Private Cloud as compliance requirements harden. The migration is a documented, repeatable workflow.