Element34
Platform
Product editionsSBOX CoreSBOX AISBOX Managed
AI native modulesStudioAI authoringAuto HealSelf-healing locatorsAutomated RCAFailure root causePulse ReportsSite health intelligenceReal Device CloudiOS and Android
Integrations & moreCI/CD integrationsJenkins, GitLab, GitHub ActionsNotificationsSlack, MS Teams, JiraAI capabilitiesPrivate inference, BYO LLMRoadmapAPI, Visual, TCM, Accessibility
Deployment
Private Cloud (self-hosted)Virtual Private Cloud (VPC)Managed Private CloudCompare deployments
Security
ArchitectureCompliance postureAudit and governanceResponsible disclosure
Industries
Banking and Financial ServicesInsurance and ReinsuranceGovernment and Public SectorHealthcare and HealthTechMedTech
Resources
Case studiesComparison guidesBlogDocumentationWhitepapers
Company
AboutCustomersCareersContact
Book a demo
Security · Architecture

Element34 architecture: Hub + Executors behind your firewall.

Hub + N Executors · Stateless license · HA in default offering

AI-native test automation running inside your own infrastructure. Two-component reference: one Hub plus N Executors, deployable as Helm chart, Docker on VM, or bare metal. Stateless-licensed, single-tenant, zero runtime telemetry to Element34.

  • Hub + N Executors
  • Stateless license
CUSTOMER PERIMETER - AIR-GAP SUPPORTED Hub DASHBOARD - LICENSE - RBAC Executor 1BROWSER Executor 2BROWSER Executor 3DEVICE Executor 4BROWSER Executor 5BROWSER Executor nDEVICE
Hub Executor Customer perimeter
Two-component reference

The two-component reference architecture. One Hub plus N Executors.

SBOX uses two component types: a Hub Virtual Machine and N Executor Virtual Machines, one called the Hub and the other called the Executor. The Hub hosts the dashboard. Executors run the actual browser and device sessions. Add Executors to scale parallel-session capacity.

01 · Hub

Hub VM, orchestrates

Hosts the dashboard the user interacts with. Holds the Stateless license. Enforces RBAC and project-scoped automation tokens. Queues incoming test sessions and dispatches work to Executors.

  • Dashboard, admin, project management
  • Stateless license validation
  • RBAC, SSO via OIDC
  • Test queue, dispatch to Executors
  • BYO LLM call orchestration
  • Audit event emission
02 · Executors

Executor VMs, run tests

Handle the actual browser launches and test execution. Pull work from the Hub. Run the browser or device session. Stream session output back to the Hub. One Hub plus N Executors is the canonical pattern.

  • Browser session execution (Selenium / Playwright)
  • Device session execution (Appium)
  • Video + screenshot capture
  • Customer-side artifact storage
  • Scaled by parallel-session target
  • Ubuntu + Docker prerequisites
03 · HA

High availability, in the default offering

Per Element34: in the default offering, customers can run multiple Hubs for high availability. Active Hubs share the work; Executors register against the Hub fleet. No upgrade tier required.

  • Multiple active Hubs in the default offering
  • Executor fleet load-balanced across Hubs
  • Resiliency to single-Hub failure
  • Standard reference, not a paid add-on

Deployment-mode differences across Private Cloud, VPC, and Managed Private Cloud live on the Compare Deployments page.

Runtime flow

How a test execution flows through SBOX. Six steps. Inside your perimeter.

From author commit to browser launch to results in the customer SIEM. Every step happens inside the customer security boundary.

1
Author writes test
In Studio, or any Selenium / Playwright IDE.
2
CI pushes to Hub
Jenkins, GitLab, GitHub, Azure DevOps. Project-scoped token.
3
Hub queues
License validated, RBAC checked, dispatched.
4
Executor pulls
Available Executor accepts the session.
5
Browser / device session
Test runs. Video + screenshots captured.
6
Results to customer storage
S3-compatible storage. Audit events to customer SIEM.
Customer-controlled AI

BYO LLM. SBOX calls your model. Element34 never sees a prompt.

Studio, Auto Heal, Automated RCA, and Pulse Report all route prompts to a customer-configured AI provider. The Element34 cloud is not in the call path. The data flow stays between the SBOX Hub and the customer's own AI subscription.

Element34 cloud no connection at runtime SBOX Hub inside customer perimeter Studio - Auto Heal RCA - Pulse Customer LLM customer subscription customer key - customer audit Azure / Bedrock / Anthropic / self prompts + responses Element34 not in the loop
Azure OpenAI AWS Bedrock Anthropic direct Self-hosted model
Honest about egress

Honest about egress. One outbound dependency, customer-controlled.

Architecture review questions get straight answers. SBOX is not a runtime caller of Element34, but Private Cloud does need to pull new browser images on a schedule. Here is the actual flow.

Egress in plain English

Runtime test traffic stays inside the customer perimeter.

Private Cloud uses a background cron job to check for new browser images on a 24-hour cycle. Air-gap customers point the cron at an internal mirror. There is no other outbound traffic to Element34 at runtime.

Default Private Cloud Background cron, 24-hour cycle, customer-owned Docker registry pull for new browser images.
Air-gapped Private Cloud Cron points at an internal mirror inside the customer perimeter. No outbound to Element34.
VPC Image pull occurs inside the customer cloud account through customer-elected egress controls. Element34 has no write access.
Managed Private Cloud Element34 operates the workload in the customer-elected region. Customer-controlled egress. Patch SLA covers image refresh.
Identity

Identity and access. What ships today, what is on the roadmap.

SSO via OpenID Connect is supported and demonstrated today. SAML and SCIM are on the roadmap. We do not overstate what we have shipped.

Supported today

OIDC SSO, LDAP, RBAC, project tokens

  • SSO via OpenID Connect, supported with providers like GitLab, Okta, and Auth0
  • LDAP integration for enterprise directory binding
  • RBAC enforced inside the Hub
  • Project-scoped automation tokens for CI pipelines
  • Stateless licensing across deployments
Roadmap

SAML and SCIM integration

  • SAML SSO integration on the roadmap
  • SCIM-based user and group provisioning on the roadmap
  • Role granularity confirmed during deployment scoping
Architecture FAQ

Architecture, answered.

What are the components in the Element34 SBOX reference architecture?
The SBOX reference architecture is two components. One Hub plus N Executors. The Hub hosts the dashboard, holds the Stateless license, runs RBAC, queues test sessions, and exports audit events. The Executor pulls work from the Hub and runs the test against a browser or device. Customers typically run one Hub and a fleet of Executors sized to parallel-session targets. The model is intentionally two tiers, not three or four.
How does Element34 prove single-tenancy?
Single-tenancy is a deployment property, not a marketing claim. In Private Cloud, the customer runs the Hub and Executors on customer infrastructure. In VPC, SBOX runs inside the customer cloud account on AWS, Azure, or GCP. In Managed Private Cloud, Element34 operates a dedicated environment for one customer in the customer-elected region. No shared compute, no shared storage, no multi-tenant database is involved. Architecture diagrams and infrastructure-as-code artifacts are shared under NDA.
Is high availability available out of the box?
Yes. Per Element34: "in the default offering ... we also offer HA as well it's high availability so you can run multiple hubs in the default offering itself." Customers can run multiple Hubs active and a fleet of Executors. The two-Hub minimum for HA is part of the standard reference, not a paid add-on.
How does Stateless licensing work?
Per Element34: "The license key is an encrypted string or encrypted license token that is stateless once generated and shared." The customer applies the license inside the Hub admin page. There is no callback to Element34, no usage telemetry leaves the customer environment, and the vendor cannot count how many times the key was applied. Annual licenses are standard; trial licenses run two to four weeks.
What egress traffic does SBOX actually make at runtime?
Runtime test traffic stays inside the customer perimeter. The one outbound dependency is a customer-controlled artifact pull for new browser images on a default 24-hour cron cycle. Air-gapped customers point the cron at an internal mirror. There is no other outbound traffic to Element34 at runtime.
Which identity providers are supported today?
SSO via OpenID Connect is supported and demonstrated today. OIDC sign-in works with providers like GitLab, Okta, and Auth0. LDAP integration is supported for enterprise directory binding. SAML and SCIM are on the roadmap; do not treat them as shipping today. Project-scoped automation tokens give CI pipelines a separate identity from human users.
How does BYO LLM work in practice?
The Hub calls the customer's own AI provider directly. Studio, Auto Heal, Automated RCA, and Pulse Report all route prompts to a customer-configured endpoint: Azure OpenAI, AWS Bedrock, Anthropic direct, or a self-hosted model. Prompt content stays between SBOX and the customer LLM. Element34 cloud is not in the call path and has no access to prompts, responses, or test data.
What runs in air-gap mode?
Private Cloud supports fully air-gapped operation. Container images and Helm charts are mirrored to the customer's internal registry. The browser-image cron points at the internal mirror. There is no outbound connectivity to Element34 at runtime. Air-gap is a Private Cloud deployment pattern; VPC and Managed Private Cloud assume customer-managed egress.
How is the Hub plus Executor footprint sized?
Sizing is scoped to the customer's parallel-session target. Two Virtual Machines is the minimum, prerequisites are Ubuntu and Docker. Reference sizing tables (cores, memory, disk per Executor at common parallel-session counts) are shared under NDA during architecture review.
How does Architecture relate to Compare Deployments?
This page covers the component model, the runtime flow, and the proof points buyers raise during architecture review. The deployment-mode differences across Private Cloud, VPC, and Managed Private Cloud, including who owns what operational responsibility, live on the Compare Deployments page.

Talk to one of our solutions engineers.

We will walk your security, compliance, and platform teams through the Hub plus Executors topology, share the deployment artifacts under NDA, and scope the right sizing for your parallel-session target.

Read the compliance posture →