To understand the core difference between Selenium Standalone Server and Selenium Server, here are the detailed steps:

👉 Skip the hassle and get the ready to use 100% working script (Link in the comments section of the YouTube Video) (Latest test 31/05/2025)

Check more on: How to Bypass Cloudflare Turnstile & Cloudflare WAF – Reddit, How to Bypass Cloudflare Turnstile, Cloudflare WAF & reCAPTCHA v3 – Medium, How to Bypass Cloudflare Turnstile, WAF & reCAPTCHA v3 – LinkedIn Article

The “Selenium Server” historically referred to a component that evolved into the “Selenium Standalone Server.” Essentially, they are one and the same in modern Selenium 3 and 4 contexts. The key distinction, if we must find one, often lies in the historical naming conventions and the functional scope. Initially, the term “Selenium Server” was used more broadly, encompassing both the Selenium RC server and later, the server component of the Selenium Grid. However, as Selenium RC became deprecated and the WebDriver API emerged as the primary interface, the bundled JAR file that provides Grid capabilities acting as a Hub or Node and enables remote WebDriver execution became specifically known as the “Selenium Standalone Server.”

Think of it this way:

• Selenium Server Historical/Broad Term: This term could refer to the original Selenium RC server now largely obsolete or the general server component in a Selenium Grid setup. It was the central piece for running tests remotely or enabling Grid.
• Selenium Standalone Server Current/Specific Term: This is the single JAR file you download e.g., selenium-server-4.x.x.jar that bundles all necessary components to run Selenium Grid as a Hub or Node or to execute remote WebDriver tests. It includes embedded WebDriver implementations, making it “standalone” – you don’t need a separate WebDriver executable if you’re interacting with a browser on the same machine as the server, or it can route requests to remote browser drivers.

In essence, if you hear “Selenium Server” today, the speaker is almost certainly referring to the “Selenium Standalone Server.” The naming evolved to be more precise about its self-contained nature and primary function in modern Selenium ecosystems.

---

Decoding the Selenium Server: A Deep Dive into Its Evolution and Functionality

When you’re navigating the world of automated browser testing with Selenium, terms like “Selenium Server” and “Selenium Standalone Server” often pop up, sometimes causing a bit of confusion.

Think of it like this: in the early days of mobile phones, people might have just said “phone.” Now, with smartphones, feature phones, and satellite phones, we specify “smartphone” to clarify what we mean.

Similarly, the “Selenium Server” is the broader, older term, while the “Selenium Standalone Server” is the specific, modern iteration we work with today for powerful, scalable test automation.

The distinction isn’t about two different products, but rather the evolution and precise naming of a critical component.

The Genesis of Selenium Server: From RC to WebDriver

To truly grasp the “difference,” we need a quick trip down memory lane, understanding how Selenium itself evolved. The initial iteration of Selenium that required a server was Selenium RC Remote Control.

• Selenium RC’s Role: Selenium RC was the dominant tool before WebDriver. It operated by injecting JavaScript functions into the browser to control its behavior. To do this, it needed a server – the Selenium RC Server.

  • How it worked: Your test script e.g., in Java, Python would send commands to the Selenium RC Server.
  • The RC Server would then use HTTP to communicate with a browser using Selenium-Core a JavaScript application that ran within the browser’s sandbox.
  • This setup had its limitations, including security restrictions imposed by browser sandboxes and slower execution due to JavaScript injection.
  • Key takeaway: The term “Selenium Server” at this stage almost exclusively meant the Selenium RC Server.

• The Rise of WebDriver: WebDriver emerged as a fundamentally different approach. Instead of injecting JavaScript, WebDriver directly interacts with the browser’s native automation support. This means WebDriver can control the browser more robustly, bypassing many of the limitations of JavaScript injection.

  • Direct Communication: WebDriver APIs communicate directly with browser-specific drivers e.g., ChromeDriver, GeckoDriver for Firefox, EdgeDriver. These drivers act as intermediaries, translating WebDriver commands into browser-native calls.
  • No Central Server for local execution: For local test execution, you often don’t need a “server.” Your test script directly initializes a browser driver, and that driver controls the local browser. This is a significant architectural shift from RC.

• The Need for Remote Execution and Grid: While local WebDriver execution is streamlined, enterprise-level test automation often requires:

  • Running tests on remote machines.
  • Executing tests across multiple browsers and operating systems concurrently parallel testing.
  • This is where the concept of a server re-enters the picture, but in a new, more powerful form: Selenium Grid.

Understanding Selenium Standalone Server: The Modern Workhorse

• Core Functionality: This JAR file bundles all the necessary components to run Selenium Grid. It acts as both a Hub and a Node within a Grid setup, depending on how you configure it.

  • Hub: The central point of the Selenium Grid. It receives test requests, manages the pool of connected Nodes, and routes tests to appropriate Nodes based on desired capabilities browser type, version, OS.
  • Node: The machine that actually runs the browser and executes the tests. Nodes register themselves with the Hub, making their capabilities available.
  • Remote WebDriver Execution: Even if you’re not setting up a full Grid, you can use the Standalone Server to execute WebDriver tests remotely. Your client script connects to the server, and the server then manages the interaction with the browser on its machine.

• Why “Standalone”? The term “standalone” is critical here. It signifies that: Selenium cloud

  • It’s a single JAR file that contains all the necessary components. You don’t need to download multiple files or manage complex dependencies beyond a Java Runtime Environment JRE.
  • It can run independently, without requiring a complex installation process. Just java -jar selenium-server-4.x.x.jar and you’re good to go.
  • It includes embedded WebDriver implementations, meaning if you’re running the server and a browser on the same machine, it can often handle the browser interaction without a separate driver executable. However, for modern browsers Chrome, Firefox, Edge, Safari, you still generally need their respective browser driver executables e.g., chromedriver.exe, geckodriver.exe for the Standalone Server to interact with them effectively.

• Typical Use Cases:

  • Setting up Selenium Grid: The primary use case for parallel and distributed testing.
  • Running tests on a remote machine: When your test scripts are on one machine, but you want to execute tests on a browser running on another machine e.g., a dedicated test server.
  • Testing against specific browser versions: When you need to maintain a controlled environment for browser versions.

• Example Download: You’d typically download it from the official Selenium website: https://www.selenium.dev/downloads/ under the “Selenium Grid” section. The file name will be something like selenium-server-4.X.X.jar.

Architectural Differences: How They Handle Browser Interaction

The fundamental architectural shift between Selenium RC which used the older “Selenium Server” and modern WebDriver which can utilize the “Selenium Standalone Server” dictates how they interact with browsers.

• Selenium RC Server Architecture:

  • Test Script: Sends HTTP commands to the RC Server.
  • Selenium RC Server: Receives commands, translates them into JavaScript, and injects that JavaScript into the browser. It acts as an HTTP proxy between the test script and the browser.
  • Selenium-Core JavaScript: Runs inside the browser, receives commands from the RC Server, executes them using browser DOM manipulation, and sends results back.
  • Browser: Executes the injected JavaScript.
  • Limitations:
    • JavaScript Sandbox: Restricted by browser security policies e.g., same-origin policy, making interactions with certain elements or external resources difficult.
    • Performance: Injecting and executing JavaScript can be slower than native interaction.
    • Reliance on JavaScript: If JavaScript is disabled or behaves unexpectedly, tests could fail.

• Selenium Standalone Server WebDriver Architecture:

  • Test Script: Uses the WebDriver API to send commands to the Selenium Standalone Server acting as a Hub or Node.
  • Selenium Standalone Server Hub/Node:
    • As a Hub, it receives requests and forwards them to an appropriate Node.
    • As a Node, it receives requests and forwards them to the specific browser driver e.g., ChromeDriver, GeckoDriver running on its machine.
  • Browser Driver e.g., ChromeDriver.exe: A separate executable provided by the browser vendor. This driver implements the WebDriver Wire Protocol, translating WebDriver commands into native API calls understandable by the browser. It launches and controls the browser directly.
  • Browser: The actual browser instance Chrome, Firefox, Edge, Safari that receives native commands from its respective driver.
  • Advantages:
    • Native Interaction: More robust, faster, and less susceptible to browser JavaScript issues.
    • Bypasses Sandbox: Directly controls the browser, allowing for more complex scenarios.
    • Scalability: The Hub/Node architecture of Selenium Grid enables massive parallelization.

• Data Point: According to a Selenium survey in 2022, over 70% of teams running Selenium tests utilize Selenium Grid which relies on the Standalone Server for parallel execution, demonstrating its critical role in modern test infrastructures. This highlights the practical importance of the Standalone Server.

When to Use the Standalone Server vs. Local WebDriver

One common question is whether you always need the Selenium Standalone Server. The answer is no, not for all scenarios. The choice depends on your testing requirements.

• When to Use Selenium Standalone Server:

  • Parallel Testing: When you need to run many tests simultaneously across different browsers, versions, or operating systems. This is the hallmark of Selenium Grid.
  • Distributed Testing: When your test execution environment where the browsers reside is physically separate from your test script execution environment where your CI/CD pipeline or local machine is.
  • Centralized Test Infrastructure: For large teams or organizations that want to manage a shared pool of test environments.
  • Cross-Browser/OS Testing: To efficiently test compatibility across various environments without setting up multiple local machines.
  • Resource Optimization: Offloading browser execution to dedicated machines can free up resources on your local development machine or CI server.
  • Selenium 3 & 4 Compatibility: The Standalone Server is designed to work seamlessly with modern WebDriver APIs.

• When Local WebDriver Execution is Sufficient:

  • Local Development & Debugging: For quick local tests or when developing new test scripts.
  • Small Projects: If your project has a limited number of tests and doesn’t require parallel execution.
  • Single-Browser Testing: If you only need to test against one browser type on your local machine.
  • Simple CI/CD Pipelines: For pipelines where tests are executed sequentially on a single build agent that has browsers installed.
  • Getting Started with Selenium: It’s often easier to start with local WebDriver execution to understand the basics before into Grid.

• Example Scenario: Imagine a startup with 50 end-to-end tests. If they need to run these tests on Chrome, Firefox, and Edge for every commit, running them sequentially on a single machine would take too long. By deploying a Selenium Grid using the Standalone Server, they could run all 150 tests 50 tests x 3 browsers in parallel across 3-5 nodes, reducing execution time from potentially hours to minutes. This efficiency translates directly into faster feedback loops for developers, which is crucial for agile methodologies. Selenium vm for browsers

Setting Up and Running the Selenium Standalone Server

Getting the Selenium Standalone Server up and running is straightforward, but understanding its configuration options is key to leveraging its power.

• Prerequisites:

  1. Java Development Kit JDK: Ensure you have Java installed. Selenium Standalone Server is a Java application. You can verify this by typing java -version in your terminal. For Selenium 4, Java 11 or higher is recommended.
  2. Selenium Standalone Server JAR: Download the latest stable version from https://www.selenium.dev/downloads/.
  3. Browser Drivers: Download the specific browser driver executables e.g., chromedriver.exe, geckodriver.exe, msedgedriver.exe for the browsers you intend to test. Place them in a directory that’s included in your system’s PATH environment variable, or specify their location when launching the server.

• Launching the Server as a Hub:

  java -jar selenium-server-4.x.x.jar hub
  

  • This command launches the server as a Grid Hub. By default, it runs on http://localhost:4444. You can access the Grid console at http://localhost:4444/ui.
  • Port Customization: java -jar selenium-server-4.x.x.jar hub --port 5555

• Launching the Server as a Node:

  Java -jar selenium-server-4.x.x.jar node –detect-drivers –publish-events tcp://localhost:4444 –session-timeout 300

  • This command launches a node that automatically detects available browser drivers if they are in the PATH and registers with the Hub running on localhost:4444.

  • --detect-drivers: A convenient flag in Selenium 4 that attempts to find and configure browser drivers installed on the system if they are in the PATH.

  • --publish-events tcp://localhost:4444: Specifies the address of the Hub for the Node to register.

  • --session-timeout 300: Sets the maximum time in seconds a session can remain idle before being terminated.

  • Manual Driver Specification if not in PATH: Writing good test cases

    
    
    java -jar selenium-server-4.x.x.jar node --driver-location "C:\Path\To\Drivers\" --publish-events tcp://localhost:4444
    

    This tells the node where to find your chromedriver.exe, geckodriver.exe, etc.

• Configuration Files: For more complex Grid setups, especially in Selenium 4, you can use TOML configuration files to define Hub and Node settings. This makes managing configurations easier, particularly in CI/CD environments.

  • Hub Config e.g., hub_config.toml:

    
    port = 4444
    
    
    host = "localhost"
    
    
    url = "http://localhost:4444"
    

  • Node Config e.g., node_config.toml:

    publish = “tcp://localhost:4444”
    subscribe = “tcp://localhost:4444”

    session-timeout = 300
    detect-drivers = true

    driver-location = “C:\Path\To\Drivers\” # Uncomment if drivers not in PATH

  • Running with config:

    Java -jar selenium-server-4.x.x.jar hub –config hub_config.toml

    Java -jar selenium-server-4.x.x.jar node –config node_config.toml

• Monitoring: Once the Grid is running, you can monitor its status and sessions via the Grid UI at http://localhost:4444/ui. This provides a visual overview of connected nodes and active sessions. Selenium with java for automated test

Migrating from Selenium RC to WebDriver and Standalone Server

If you’re working with an older codebase that might still reference “Selenium Server” in the RC context, migrating to WebDriver and the Standalone Server is a crucial step for modernizing your test automation.

• Why Migrate?

  • Deprecation of RC: Selenium RC is officially deprecated. Its development has ceased, and it’s no longer supported. Continuing to use it poses risks in terms of compatibility with newer browsers and operating systems, and potential security vulnerabilities.
  • Improved Performance and Robustness: WebDriver’s native interaction offers significantly better performance and more reliable test execution compared to RC’s JavaScript injection.
  • Broader Browser Support: WebDriver is actively maintained to support the latest browser versions and their features.
  • Simpler API in many cases: The WebDriver API is generally considered more intuitive and object-oriented.
  • Seamless Grid Integration: The Standalone Server is built for WebDriver, making Grid setup and scaling much more efficient.

• Migration Steps High-Level:

  1. Understand WebDriver API: Familiarize yourself with the core WebDriver classes and methods WebDriver, WebElement, By, findElement, findElements, click, sendKeys, etc..

  2. Replace DefaultSelenium or Selenium with WebDriver: This is the most fundamental change.

     • RC Example:

       // Selenium RC Deprecated
       Selenium selenium = new DefaultSelenium"localhost", 4444, "*firefox", "http://www.example.com/".
       selenium.start.
       selenium.open"/".
       
       
       selenium.type"id=username", "testuser".
       

     • WebDriver Example Local:
       // WebDriver Modern

       WebDriver driver = new ChromeDriver. // Or new FirefoxDriver, new EdgeDriver
       driver.get”http://www.example.com/“.

       Driver.findElementBy.id”username”.sendKeys”testuser”.

     • WebDriver Example Remote/Grid via Standalone Server: Myths about selenium testing

       // WebDriver with RemoteWebDriver using Standalone Server/Grid

       DesiredCapabilities capabilities = new DesiredCapabilities.
       capabilities.setBrowserName”chrome”.

       WebDriver driver = new RemoteWebDrivernew URL”http://localhost:4444/wd/hub“, capabilities.

  3. Update Locators: While many locators id, name, css, xpath are similar, the syntax for using them with By objects in WebDriver is different.

  4. Handle Waits: WebDriver introduces explicit and implicit waits, which are more robust than RC’s waitForPageToLoad or waitForCondition.

  5. Utilize Page Object Model POM: While not strictly a migration step, adopting POM is highly recommended for maintainable WebDriver test suites.

  6. Set up Selenium Grid Standalone Server: If you need parallel or distributed execution, deploy the Selenium Standalone Server as a Hub and connect your Nodes.

  7. Phased Migration: For large test suites, consider a phased migration. Migrate one module or set of tests at a time, ensuring stability at each step.

• Statistics: While direct statistics on RC to WebDriver migration are hard to pinpoint, the official Selenium project’s deprecation of RC in favor of WebDriver speaks volumes. The community’s shift has been almost universal, with very few new projects or active maintenance efforts continuing to use RC. This reflects the significant advantages and future-proofing offered by WebDriver and its ecosystem, supported by the Standalone Server.

The Future: Selenium 4 and Beyond

Selenium 4 brought significant enhancements to the Selenium Standalone Server and the Grid architecture, solidifying its role as the backbone for distributed testing. Maven dependency with selenium

• Unified JAR: In Selenium 4, the Selenium Standalone Server JAR consolidates the Hub, Node, and standalone client functionalities into a single executable. This simplifies deployment.

• Improved Grid Architecture:

  • Event Bus: Selenium 4 Grid introduces an Event Bus, which allows for asynchronous communication between Grid components Hub, Routers, Nodes. This makes the Grid more resilient and scalable.
  • Distributed Architecture: The Grid can now be deployed in a more distributed fashion, with components running on different machines.
  • GraphQL API: A new GraphQL API provides a more flexible way to query Grid status and session information, making integration with monitoring tools easier.
  • Docker Support: Selenium 4 has first-class Docker support, enabling easy deployment of Grid components as containers. This is a must for cloud-based test environments and local development.
  • Observability: Enhanced logging and metrics expose more insights into Grid operations.

• W3C WebDriver Standard Compliance: Selenium 4 is fully compliant with the W3C WebDriver specification. This means:

  • Improved consistency across different browser implementations.
  • Better interoperability between Selenium and other WebDriver-compliant tools.
  • More predictable behavior of test scripts.

• Impact on the “Standalone Server”: The enhancements in Selenium 4 further cement the Selenium Standalone Server as the definitive “server” component. Its capabilities have expanded, making it an even more robust and versatile tool for complex test automation needs. The notion of a separate “Selenium Server” that isn’t “Standalone” becomes even more anachronistic in this context.

• Cloud-Based Alternatives: While the Selenium Standalone Server and Grid is powerful for self-hosting, it’s worth noting the rise of cloud-based Selenium Grid providers e.g., BrowserStack, Sauce Labs, LambdaTest. These services abstract away the need for you to manage your own servers, offering instant access to a vast array of browser/OS combinations and massive parallelization. For many organizations, the operational overhead of maintaining a self-hosted Grid leads them to these cloud solutions. However, understanding the Standalone Server remains foundational, as these cloud providers essentially offer it as a service.

• The Future: As browsers continue to evolve and testing needs become more complex, the Selenium project will continue to innovate. The Selenium Standalone Server, or its conceptual successor, will remain central to enabling flexible, scalable, and robust test execution, especially in distributed environments. Its evolution reflects a constant effort to adapt to modern software development practices, including DevOps and cloud-native deployments.

Frequently Asked Questions

What is the primary difference between Selenium Standalone Server and Selenium Server?

The primary difference is largely historical and semantic.

In modern Selenium versions 3 and 4, the term “Selenium Server” is synonymous with the “Selenium Standalone Server.” The Standalone Server is a single JAR file that bundles all the necessary components to run Selenium Grid as a Hub or Node or to facilitate remote WebDriver execution.

Historically, “Selenium Server” could refer to the older Selenium RC server, which is now deprecated.

Do I need the Selenium Standalone Server to run WebDriver tests?

No, you do not always need the Selenium Standalone Server to run WebDriver tests. Myths about functional testing

For local test execution where your browser and test script are on the same machine, you can directly use the WebDriver API by initializing a browser-specific driver e.g., ChromeDriver, FirefoxDriver. The Standalone Server is primarily needed for remote execution or setting up a Selenium Grid for parallel and distributed testing.

What is Selenium Grid and how does the Standalone Server fit into it?

Selenium Grid is a system that allows you to run Selenium tests on different machines against different browsers in parallel. The Selenium Standalone Server is the core component of Selenium Grid. You launch one instance of the Standalone Server as a Hub the central router and other instances as Nodes where browsers run. Nodes register with the Hub, and your test scripts connect to the Hub to execute tests remotely across the available Nodes.

Can I use the Selenium Standalone Server with Selenium RC?

Historically, the “Selenium Server” was indeed the server for Selenium RC.

However, Selenium RC is deprecated and no longer actively developed.

The modern Selenium Standalone Server versions 3 and 4 is designed to work with WebDriver.

While there might be some legacy compatibility in very old versions, it’s strongly advised to migrate from Selenium RC to WebDriver if you are still using it.

Where can I download the Selenium Standalone Server?

You can download the Selenium Standalone Server JAR file from the official Selenium website: https://www.selenium.dev/downloads/. Look under the “Selenium Grid” section for the latest stable release.

What are the prerequisites for running the Selenium Standalone Server?

The main prerequisite is a Java Runtime Environment JRE or Java Development Kit JDK installed on your system. For Selenium 4, Java 11 or higher is recommended.

Additionally, you will need the specific browser driver executables e.g., chromedriver.exe, geckodriver.exe for the browsers you want to automate, placed in your system’s PATH or specified when launching the server.

How do I launch the Selenium Standalone Server as a Hub?

To launch the server as a Hub, open your terminal or command prompt, navigate to the directory where you downloaded the JAR file, and execute the command: java -jar selenium-server-4.x.x.jar hub. By default, it will run on http://localhost:4444. Open source spotlight oswald labs with anand chowdhary

How do I launch the Selenium Standalone Server as a Node?

To launch the server as a Node, you typically need to point it to a running Hub.

An example command is: java -jar selenium-server-4.x.x.jar node --detect-drivers --publish-events tcp://localhost:4444. This command will detect installed browser drivers and register the node with a hub running on localhost:4444.

What is the default port for the Selenium Standalone Server Hub?

The default port for the Selenium Standalone Server Hub is 4444. You can access the Grid console at http://localhost:4444/ui once the Hub is running.

Can I change the default port for the Hub or Node?

Yes, you can change the default port.

For the Hub, use the --port flag: java -jar selenium-server-4.x.x.jar hub --port 5555. For a Node, the port is usually automatically assigned or can be specified in configuration files.

What is the wd/hub endpoint used for in Selenium?

The wd/hub endpoint e.g., http://localhost:4444/wd/hub is the standard entry point for WebDriver client requests when connecting to a Selenium Grid Hub or a Standalone Server acting as a remote WebDriver server.

Your RemoteWebDriver instance will point to this URL.

What are Desired Capabilities in the context of the Standalone Server?

Desired Capabilities are a set of key-value pairs that are sent by the client your test script to the Selenium Grid Hub or Standalone Server to specify the kind of environment browser, version, OS, etc. you want for your test.

The Hub then matches these capabilities with available Nodes to route your test.

What is the advantage of using Selenium Grid with the Standalone Server?

The main advantage is the ability to perform parallel and distributed testing. Common cross browser compatibility issues

This significantly reduces test execution time, allows for testing across various browser/OS combinations efficiently, and centralizes test infrastructure management, leading to faster feedback loops in the development cycle.

Is Selenium Standalone Server compatible with Selenium 4?

Yes, the Selenium Standalone Server is fully compatible with Selenium 4. In fact, Selenium 4 brought significant architectural improvements to the Grid, making the Standalone Server even more robust and capable for distributed testing with features like the Event Bus and GraphQL API.

Can I run multiple Nodes on the same machine with the Standalone Server?

Yes, you can run multiple Nodes on the same machine, provided each Node uses a different port and has access to its own browser instances if running multiple instances of the same browser type. This can be useful for maximizing resource utilization on a powerful test machine.

What is the role of browser drivers e.g., ChromeDriver when using the Standalone Server?

Browser drivers are essential.

The Selenium Standalone Server, when acting as a Node, communicates with these specific executables e.g., chromedriver.exe, geckodriver.exe. These drivers then translate the WebDriver commands into native API calls that the actual browser understands and executes.

How do I manage browser drivers with the Standalone Server in Selenium 4?

In Selenium 4, you can use the --detect-drivers flag when launching a Node, and it will attempt to find browser drivers located in your system’s PATH.

Alternatively, you can explicitly specify the location of your driver executables using the --driver-location flag or by configuring it in a TOML configuration file for the Node.

Is the Selenium Standalone Server suitable for cloud deployments?

Yes, the Selenium Standalone Server and specifically the Grid components it provides is very suitable for cloud deployments.

Its Java-based nature and command-line interface make it easy to deploy on virtual machines, containers especially with Selenium 4’s Docker support, or managed services in cloud environments like AWS, Azure, or GCP.

What are some common issues when setting up the Selenium Standalone Server?

Common issues include: Challenges faced by qa

• Incorrect Java version e.g., Java 8 for Selenium 4.
• Browser drivers not found not in PATH or --driver-location not specified.
• Firewall blocking ports 4444 or custom ports.
• Network connectivity issues between Hub and Nodes.
• Browser versions mismatching driver versions.
• Insufficient memory allocated to Java for running the server.

Are there any alternatives to self-hosting the Selenium Standalone Server/Grid?

Yes, there are several excellent cloud-based Selenium Grid providers such as BrowserStack, Sauce Labs, and LambdaTest.

These services allow you to run your Selenium tests on their pre-configured infrastructure, abstracting away the need for you to manage your own Standalone Servers, browsers, and operating systems.

They offer immediate access to a wide array of browser/OS combinations and massive parallelization capabilities.