When is Selenium Grid's standalone mode the right topology for a train timetable board test suite?

principalmust knowfreq 46%

answer

Start by asking how big the run is
One machine, one process, one port
The ceiling is CPU and memory
Laptop, CI job, container
Move off only when a box runs out

basics

~20 s

Standalone is right whenever one machine can hold the whole run. Selenium 4's standalone command starts every Grid component in one process on port 4444, so a laptop, a CI job or a container needs nothing else.

solid answer

~50 s

In Selenium 4, standalone runs all six Grid components — router, distributor, session map, new session queue, event bus and node — in one process on one machine, serving WebDriver on port 4444. For a timetable board suite that is usually enough, because the concurrency ceiling is that machine's CPU and memory and most suites never reach it. It is the right shape for local debugging, for a CI job that starts the server, runs the departure-board specs and kills it, and for one container or VM a team owns. You move off it when you need more capacity than one box gives, browsers or operating systems that box cannot host, capacity added without a restart, or a grid that survives a machine dying. Choose it until measurement says otherwise, not the other way round.

In Selenium 4, `standalone` runs all six Grid components — router, distributor, session map, new session queue, event bus and node — in one process on one machine, serving WebDriver on port 4444. For a timetable board suite that is usually enough, because the concurrency ceiling is that machine's CPU and memory and most suites never reach it. It is the right shape for local debugging, for a CI job that starts the server, runs the departure-board specs and kills it, and for one container or VM a team owns. You move off it when you need more capacity than one box gives, browsers or operating systems that box cannot host, capacity added without a restart, or a grid that survives a machine dying. Choose it until measurement says otherwise, not the other way round.

go deeper

for a junior

Be ready to say that standalone runs the whole Grid in one process on one machine and answers on port 4444. Knowing that a laptop or a CI job can host it is enough at this level.

for a middle

Explain what one process buys: no registration step, one log, one lifecycle. Be able to say what sets the concurrency ceiling on a single machine and why that number is usually larger than a suite actually asks for.

for a senior

Show that you have operated this. Talk about starting a standalone server inside a CI job, waiting for it to report ready before the suite runs, and reading a queued session as a capacity signal rather than as a flaky test.

for a principal

Own the topology decision and its ongoing cost. Be ready to defend putting every team on a per-job standalone server, and to name the specific evidence — capacity, platform coverage, elasticity, availability — that would justify paying for anything larger.

What standalone actually is

Standalone is one of the three ways to deploy Selenium 4's Grid. A single command — java -jar selenium-server.jar standalone — starts all six Grid components (router, distributor, session map, new session queue, event bus and node) inside one JVM process on one machine, and that process listens for WebDriver traffic on port 4444 by default. Selenium's own documentation states the constraint plainly: standalone can only run on a single machine. That sentence is the whole capacity-planning question, and everything below follows from it.

The other Grid deployment shapes exist because sometimes one machine is not enough. The assumption worth catching in an interview is the reverse one — that a machine is presumed not to be enough before anybody measured.

The three shapes where one process is the right answer

Take a team that owns a train timetable board: a departure-board page that must be checked in several browsers on every merge. All three of the following are standalone's natural home.

A developer's laptop. Someone is writing the specification that asserts a delayed service drops to the bottom of the board. They want a real remote endpoint to point at, not a shared one, and they want to restart it whenever they break it.
A CI job. The job starts the server as a step, waits until it reports ready, runs the departure-board suite against http://localhost:4444, and lets teardown take the process with it. No server outlives the build.
A container or a single VM the team owns. One process, one port, enough for the whole board suite, and small enough that nobody has to be on call for it.

What all three buy is the same short list:

Nothing registers with anything. There is no second process to find, so an entire class of start-up failure does not exist.
One log. A refused session, a browser that would not launch and an HTTP error all land in one stream, in order.
One lifecycle. The server is created and destroyed with the thing that needed it, which is exactly right per build.
No standing operational bill. Nothing to patch, monitor or capacity-plan between runs.

What actually forces you off one machine

Four honest reasons, and one that is not a reason at all:

Capacity. The node inside the standalone process sizes its slots from the machine, and that machine's CPU and memory cap how many browsers can render a timetable board at once. When new sessions genuinely wait while the host is saturated, you are at the ceiling.
Platform coverage. A board that must be verified on a browser or operating system this host cannot install is not a capacity problem, and no amount of memory fixes it.
Elasticity. A standalone server's capacity changes when you restart it with different settings. Needing to add capacity to a live grid without a restart is a different topology.
Availability. One process is one failure domain; if it dies, every session dies with it.
Not a reason: it feels like a toy. Standalone runs the same components as any other shape and serves the same endpoint. A suite cannot tell the difference.

Decision input	Standalone on one box	A grid split across machines
Processes to operate	one	several, each with its own lifecycle
Capacity ceiling	that machine	add machines
Failure domain	the whole grid at once	per component or per host
Time to first session	seconds, from one command	once every part is up and registered
Who owns it out of hours	usually nobody	somebody, explicitly

How a lead should actually decide

Measure the run you have. How many browser sessions does the board suite want at its peak, and for how long does it hold them?
Price one machine against that number. A single modern CI runner or VM holds far more concurrent browsers than most suites ever request.
Choose the smallest shape that clears the number, and write down the evidence that would change the answer: a wait that never drains, a platform you cannot install, an availability requirement nobody has stated yet.

The principal-level position is not that standalone is best, nor that a bigger grid is more professional. It is that topology is a consequence of a measurement; that a standalone server per CI job is the cheapest correct answer for most suites; and that the larger shapes are paid for in operations forever rather than once.

## What standalone actually is **Standalone** is one of the three ways to deploy **Selenium 4's Grid**. A single command — `java -jar selenium-server.jar standalone` — starts all six Grid components (**router**, **distributor**, **session map**, **new session queue**, **event bus** and **node**) inside one JVM process on one machine, and that process listens for WebDriver traffic on **port 4444** by default. Selenium's own documentation states the constraint plainly: standalone can only run on a single machine. That sentence is the whole capacity-planning question, and everything below follows from it. The other Grid deployment shapes exist because sometimes one machine is not enough. The assumption worth catching in an interview is the reverse one — that a machine is presumed not to be enough before anybody measured. ## The three shapes where one process is the right answer Take a team that owns a **train timetable board**: a departure-board page that must be checked in several browsers on every merge. All three of the following are standalone's natural home. 1. **A developer's laptop.** Someone is writing the specification that asserts a delayed service drops to the bottom of the board. They want a real remote endpoint to point at, not a shared one, and they want to restart it whenever they break it. 2. **A CI job.** The job starts the server as a step, waits until it reports ready, runs the departure-board suite against `http://localhost:4444`, and lets teardown take the process with it. No server outlives the build. 3. **A container or a single VM the team owns.** One process, one port, enough for the whole board suite, and small enough that nobody has to be on call for it. What all three buy is the same short list: - **Nothing registers with anything.** There is no second process to find, so an entire class of start-up failure does not exist. - **One log.** A refused session, a browser that would not launch and an HTTP error all land in one stream, in order. - **One lifecycle.** The server is created and destroyed with the thing that needed it, which is exactly right per build. - **No standing operational bill.** Nothing to patch, monitor or capacity-plan between runs. ## What actually forces you off one machine Four honest reasons, and one that is not a reason at all: - **Capacity.** The node inside the standalone process sizes its slots from the machine, and that machine's CPU and memory cap how many browsers can render a timetable board at once. When new sessions genuinely wait while the host is saturated, you are at the ceiling. - **Platform coverage.** A board that must be verified on a browser or operating system this host cannot install is not a capacity problem, and no amount of memory fixes it. - **Elasticity.** A standalone server's capacity changes when you restart it with different settings. Needing to add capacity to a live grid without a restart is a different topology. - **Availability.** One process is one failure domain; if it dies, every session dies with it. - **Not a reason: it feels like a toy.** Standalone runs the same components as any other shape and serves the same endpoint. A suite cannot tell the difference. | Decision input | Standalone on one box | A grid split across machines | |---|---|---| | Processes to operate | one | several, each with its own lifecycle | | Capacity ceiling | that machine | add machines | | Failure domain | the whole grid at once | per component or per host | | Time to first session | seconds, from one command | once every part is up and registered | | Who owns it out of hours | usually nobody | somebody, explicitly | ## How a lead should actually decide 1. **Measure the run you have.** How many browser sessions does the board suite want at its peak, and for how long does it hold them? 2. **Price one machine against that number.** A single modern CI runner or VM holds far more concurrent browsers than most suites ever request. 3. **Choose the smallest shape that clears the number,** and write down the evidence that would change the answer: a wait that never drains, a platform you cannot install, an availability requirement nobody has stated yet. The principal-level position is not that standalone is best, nor that a bigger grid is more professional. It is that topology is a consequence of a measurement; that a standalone server per CI job is the cheapest correct answer for most suites; and that the larger shapes are paid for in operations forever rather than once.

Your CI runs the timetable-board suite in six parallel jobs. One standalone server each, or one shared grid?
One standalone per job, almost always. Each job gets a server whose lifetime is the job's, so a hung session cannot leak into another build and nothing keeps running between builds. A shared grid only pays off when jobs need capacity or platforms no single runner has, and it brings a wait queue, an owner and an on-call story with it.
What signal tells you the standalone machine has genuinely run out, rather than the suite just being slow?
Look at whether requests are waiting for a slot or waiting for the application. If new sessions sit unserved while the host's CPU is saturated and browsers are swapping, you are at the machine's ceiling. If the box is idle and the run is still long, the cost is in the timetable board's own load time or in the suite's waits, and more machines will not help.
Does standalone restrict you to one browser type?
No. The node inside the standalone process offers slots for the drivers it finds on the machine, so one process can serve several browsers at once. The real limit is what that one operating system can install: a Linux host cannot offer a browser that only ships elsewhere, and that is a platform-coverage reason to leave standalone rather than a Grid limitation.

saying these in an interview costs you the question

Says standalone is only for demos and never belongs in CI
Assumes a multi-machine grid is always more production-ready than standalone
Thinks standalone can be spread over two machines by pointing them at each other
Believes standalone can serve only one browser session at a time
Picks a multi-machine grid before measuring what one machine actually delivers

When is Selenium Grid's standalone mode the right topology for a train timetable board test suite?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What standalone actually is

The three shapes where one process is the right answer

What actually forces you off one machine

How a lead should actually decide

▾common follow-ups3 questions

▾red flags5 flags

What standalone actually is

The three shapes where one process is the right answer

What actually forces you off one machine

How a lead should actually decide

answer

go deeper