Selenium Cloud Service
A selenium cloud service runs automated browser tests on remote servers. You point your test scripts to a remote endpoint with an API key. Engineering teams use this setup to test web apps across many browsers at once. Teams often share one broad API key across all build servers and developer laptops. Broad permissions let any user or script run tests against internal staging apps. How a selenium cloud service works A local test script needs a browser and a driver to click buttons and read pa
Service-to-Service Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A selenium cloud service runs automated browser tests on remote servers. You point your test scripts to a remote endpoint with an API key. Engineering teams use this setup to test web apps across many browsers at once. Teams often share one broad API key across all build servers and developer laptops. Broad permissions let any user or script run tests against internal staging apps.
How a selenium cloud service works
A local test script needs a browser and a driver to click buttons and read pages. Maintaining dozens of browser versions on your own servers takes too much time. A selenium cloud service hosts those browsers and drivers on remote virtual machines. Your test runner sends commands over the network to the remote hub. The hub reads your desired browser settings and starts a fresh virtual machine. The remote browser opens your target web app and runs each test step. When the test finishes, the service shuts down the virtual machine and wipes the disk.
To test internal staging apps, the remote browser needs a network path into your private network. Teams usually run a tunnel client inside their private network to bridge this gap. The tunnel client opens an outbound link to the cloud provider. Remote browser traffic then flows through that tunnel straight to your internal staging servers. Teams control who can start tests by assigning roles and API keys in the provider dashboard. Most teams store a shared key in their continuous integration tool so every build can run tests.
How teams manage remote test permissions
Teams usually start by creating one account for their build pipelines. Developers also get accounts to run single tests from their laptops while fixing bugs. Admins group users into teams and set limits on how many browsers run at once. If a tunnel connects to a staging network, admins often restrict who can use that tunnel. Some teams start a fresh tunnel for each build and close it right after.
In practice, managing many separate keys and tunnels slows down daily work. Teams often fall back to a single persistent tunnel that keeps the session active all day. Every developer and build job then shares the same path into the private network. If a developer laptop gets compromised, the attacker can use that shared key and open tunnel. They can point remote browsers at internal admin dashboards or other private services.
Service-to-Service Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native grid setup solves and what it misses
A remote browser grid solves the hard problem of scaling browser tests across operating systems. Built-in account roles and API keys decide who can log in and start a browser session. Network tunnels let remote browsers reach private test servers without opening inbound firewall ports. These native controls handle basic user login and test routing well.
Still, the native setup only checks permissions when a session starts. Once the tunnel is open, the setup does not inspect what the script or user does in flight. A valid test key lets a script reach any internal host reachable from the tunnel machine. Test scripts can also pull real emails, phone numbers, or card numbers from staging pages into logs. Screenshots and video logs stored in the cloud may hold those sensitive fields in plain text. Native grid roles cannot rewrite those fields or block risky commands inside a running session.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do remote browsers reach private staging apps?
You run a small tunnel agent inside your private network. That agent creates a secure outbound link so remote browsers can load internal web pages.
Why is sharing one API key across build jobs risky?
A shared key makes it impossible to see which person or job ran a specific test. If the key leaks, you must update every pipeline at once to rotate it.
Can browser test logs expose sensitive user data?
Yes, page source dumps and screenshots capture whatever appears on the test screen. If staging databases hold real emails or card numbers, those values end up in external test logs.