On Prem Selenium
You set up on prem selenium by running a local grid hub and browser nodes. Your test scripts then send commands to this hub inside your private network. Engineering teams build this local setup to test internal web apps behind a firewall. Still, teams often grant broad network permissions to these test nodes. Broad permissions let any script or user reach sensitive internal systems without strict checks. How an on prem selenium architecture works A local browser grid uses two main parts to ru
Single Sign-On (SSO): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up on prem selenium by running a local grid hub and browser nodes. Your test scripts then send commands to this hub inside your private network. Engineering teams build this local setup to test internal web apps behind a firewall. Still, teams often grant broad network permissions to these test nodes. Broad permissions let any script or user reach sensitive internal systems without strict checks.
How an on prem selenium architecture works
A local browser grid uses two main parts to run tests. The hub acts as the central router for all incoming test jobs. The nodes run the actual web browsers on virtual machines or containers. When a developer starts a test, the script sends a request to the hub. The hub checks what browser type and operating system the test needs. Next, the hub routes the test to a matching node in the pool.
The node opens a fresh browser window and runs the test steps. It loads the internal web app, clicks buttons, and reads page text. To do this, the node must sit inside your private network. Teams place the hub and nodes on internal subnets that can reach staging databases. They also set up network rules so Continuous Integration servers can talk to the hub. Once the test finishes, the node closes the browser and reports the result.
Network access and permission setup for browser nodes
Teams control grid access through basic network firewalls and server roles. Admins restrict which internal IP addresses can send test jobs to the hub. They also assign machine roles to the nodes so they can pull container images. Some teams put a basic password check on the hub endpoint. Every test runner then shares the same static key to start browser sessions.
Also, the browser nodes need credentials to log in to internal test apps. Teams often store test user passwords in shared pipeline files. The test script reads these keys and types them into the browser login page. Because many teams share one large grid, one node pool reaches many internal apps. A single node might have network routes to billing systems, admin panels, and user portals.
Single Sign-On (SSO): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native grid setups solve and where they fall short
Running a local grid solves the main problem of testing private apps. You do not need to open firewall ports to outside cloud testing vendors. Your data stays inside your own servers, and tests run close to your apps. The native hub also does a great job of queuing jobs and scaling browsers.
Yet this native setup leaves a major security and auditing gap open. Network rules only check which server connects to the grid hub. They do not check who started the job or what the browser does next. Once a session starts, the node can visit any internal URL on that subnet. A bad script or curious user can point the browser at sensitive internal tools. Also, if test pages show real data, the browser screenshots might capture card numbers or emails. Native grid logs only show browser commands, not a clear audit trail of user actions.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why do teams run a local browser grid instead of cloud tools?
Teams use a local grid to test private apps that sit behind strict firewalls. It also avoids sending sensitive test data over the public internet to third parties.
How should we isolate browser nodes on our internal network?
Place browser nodes in a dedicated subnet with strict outbound firewall rules. Only allow traffic from the nodes to specific staging apps, never to production systems.
What is the biggest security risk of a shared internal grid?
Shared nodes often have broad network routes to many internal apps at once. Without per-request checks, any user who can reach the hub can browse those internal apps.