You also can proactive to force applying arguments directly from (node, standalone or node-docker) container environment variables. Define the environment variable with name starts with SE_BROWSER_ARGS_ and following by config key is up to you (ensure those are unique when you define multiple arguments). For example:

List chromium command-line arguments for your reference.
Note: Currently, this is applicable for node browsers Chrome/Chromium, Edge.
Node configuration options  Copy Section
The Nodes register themselves through the Event Bus. When the Grid is started in its typical Hub/Node
setup, the Hub will be the one acting as the Event Bus, and when the Grid is started with all its five
elements apart, the Event Bus will be running on its own.
In both cases, it is necessary to tell the Node where the Event Bus is, so it can register itself. That is
the purpose of the SE_EVENT_BUS_HOST, SE_EVENT_BUS_PUBLISH_PORT and SE_EVENT_BUS_SUBSCRIBE_PORT environment
variables.
In some cases, for example, if you want to tag a node, it might be necessary to supply a custom stereotype to the node config. The environment variable SE_NODE_STEREOTYPE
sets the stereotype entry in the node's config.toml. An example config.toml file can be found here: Setting custom capabilities for matching specific Nodes.
Here is an example with the default values of these environment variables:

In another case, if you want to retain the default Node stereotype and append additional capabilities, you can use the SE_NODE_STEREOTYPE_EXTRA environment variable to set your capabilities. Those will be merged to the default stereotype. For example:

This help setting custom capabilities for matching specific Nodes. For example, you added your custom capabilities when starting the Node, and you want assign a test to run on that Node which matches your capabilities. For example in test code:

Noted: Your custom capabilities with key values should be in W3C capabilities convention, extension capabilities key must contain a ":" (colon) character, denoting an implementation specific namespace.
Noted: Ensure that Node config detect-drivers = false in config.toml (or --detect-drivers false in CLI option) to make feature setting custom capabilities for matching specific Nodes get working.
In addition, default Node stereotype includes capability se:containerName which can visible in node capabilities, or session capabilities to identify the container name where the node/session is running. The prefixed se:containerName is not included in slot matcher. By default, value is getting from hostname command in container, this value is equivalent to the container_id that you saw via docker ps command. If you want to override this value, you can set the environment variable SE_NODE_CONTAINER_NAME to your desired value. For example, when deploy to Kubernetes cluster, you can assign Pod name to env var SE_NODE_CONTAINER_NAME to track a node is running in which Pod.

In an advanced case, where you control to spawn up a Node container, let it register to Hub, and then trigger a test to be assigned exactly to run on that Node. By default, the value of command $(hostname) is added to capability name container:hostname in Node stereotype. Combine with above feature setting custom capabilities for matching specific Nodes. You can use the hostname of the Node container just spawned up and set it as a custom capability. For example, in Python binding:

_Noted: Those above changes require new image tag where the changeset is included & released._
Node configuration relay commands  Copy Section
Relaying commands to a service endpoint that supports WebDriver.
It is useful to connect an external service that supports WebDriver to Selenium Grid. An example of such service could be a cloud provider or an Appium server. 
In this way, Grid can enable more coverage to platforms and versions not present locally.
The following is an en example of configuration relay commands.
docker-compose-v3-test-node-relay.yml
If you want to relay commands only, selenium/node-base is suitable and lightweight for this purpose.
In case you want to configure node with both browsers and relay commands, respective node images can be used.
To use environment variables for generate relay configs, set SE_NODE_RELAY_URL and other variables as below. Those will be used to generate the default relay config in TOML format looks like below.

Instead of input value for each environment variable to construct the default relay stereotype, you can use the SE_NODE_RELAY_STEREOTYPE environment variable to overwrite the default relay stereotype with your custom stereotype.
In another case, if you want to retain the default relay stereotype and append additional capabilities, you can use the SE_NODE_RELAY_STEREOTYPE_EXTRA environment variable to set your capabilities. Those will be merged to the default relay stereotype.
To run a sample test with the relayed node, you can clone the project and try below command:

Setting Sub Path  Copy Section
By default, Selenium is reachable at http://127.0.0.1:4444/. Selenium can be configured to use a custom subpath by specifying the SE_SUB_PATH
environmental variable. In the example below Selenium is reachable at http://127.0.0.1:4444/selenium-grid/

Setting Screen Resolution  Copy Section
By default, nodes start with a screen resolution of 1920 x 1080 with a color depth of 24 bits and a dpi of 96. 
These settings can be adjusted by specifying SE_SCREEN_WIDTH, SE_SCREEN_HEIGHT, SE_SCREEN_DEPTH, and/or SE_SCREEN_DPI 
environmental variables when starting the container.

Grid Url and Session Timeout  Copy Section
In some use cases, you might need to set the Grid URL to the Node, for example, if you'd like to access the BiDi/CDP endpoint. 
This is also needed when you want to use the new RemoteWebDriver.builder() or Augmenter() present in Selenium 4 
(since they setup the BiDi/CDP connection implicitly). You can do that through the SE_NODE_GRID_URL environment 
variable, eg -e SE_NODE_GRID_URL=http://<hostMachine>:4444. Setting this env var is needed if you want to see the live view while sessions are executing.
Grid has a default session timeout of 300 seconds, where the session can be in a stale state until it is killed. You can use
SE_NODE_SESSION_TIMEOUT to overwrite that value in seconds.

Session request timeout  Copy Section
A new session request is placed in the Session Queue before it is processed, and the request sits in the queue until a matching
slot is found across the registered Nodes. However, the new session request might timeout if no slot was found. By default, a 
request will stay in the queue for up to 300 seconds before it a timeout is reached. In addition, an attempt to process the request
is done every 5 seconds (by default).
It is possible to override those values through environment variables in the Hub and the SessionQueue (SE_SESSION_REQUEST_TIMEOUT
and SE_SESSION_RETRY_INTERVAL). For example, a timeout of 500 seconds would be SE_SESSION_REQUEST_TIMEOUT=500 and a retry 
interval of 2 seconds would be SE_SESSION_RETRY_INTERVAL=2.
Increasing session concurrency per container  Copy Section
By default, only one session is configured to run per container through the SE_NODE_MAX_SESSIONS environment variable. It is
possible to increase that number up to the maximum available processors, this is because more stability is achieved when one
container/browser has 1 CPU to run. 
However, if you have measured performance and based on that, you think more sessions can be executed in each container, you can
override the maximum limit by setting both SE_NODE_MAX_SESSIONS to a desired number and SE_NODE_OVERRIDE_MAX_SESSIONS to 
true. Nevertheless, running more browser sessions than the available processors is not recommended since you will be overloading
the resources.
Overriding this setting has an undesired side effect when video recording is enabled since more than one browser session might be
captured in the same video.
Running in Headless mode  Copy Section
Firefox,
Chrome,
When using headless mode, there's no need for the Xvfb server to be started.
To avoid starting the server you can set the SE_START_XVFB environment variable to false 
(or any other value than true), for example:

For more information, see this GitHub issue.
Noted:
- In new Chrome/Chromium versions (v127+), SE_START_XVFB is required to be set to true to run in --headless=new mode.
- In new Chrome/Chromium versions (v132+), --headless only runs in the new mode, so you need to set SE_START_XVFB to true when using --headless mode.
Stopping the Node/Standalone after N sessions have been executed  Copy Section
In some environments, like Docker Swarm or Kubernetes, it is useful to shut down the Node or Standalone
container after N tests have been executed. For example, this can be used in Kubernetes to terminate the
pod and then scale a new one after N sessions. Set the environment variable SE_DRAIN_AFTER_SESSION_COUNT to
a value higher than zero to enable this behaviour.

With the previous command, the Standalone container will shut down after 5 sessions have been executed.
Automatic browser leftovers cleanup  Copy Section
In long-running containers, it can happen that browsers leave some leftovers. These can be stuck browser processes
of jobs that have already finished but failed to fully stop the browser, or temporary files written to the /tmp
file system (notably on Chrome-based browsers). To avoid these filling up resources like process IDs and file system
usage in the container, there is an automatic cleanup script running every hour in the node containers. This will
clean up old processes and old temporary files. By default, this is disabled. When enabled, this will clean up browsers
running for longer than 2 hours, and files older than 1 day. These can be enabled and tweaked with the following
environment variables:
* SE_ENABLE_BROWSER_LEFTOVERS_CLEANUP: default value false, set to true to enable the cleanup.
* SE_BROWSER_LEFTOVERS_INTERVAL_SECS: default value 3600 (1 hour), cleanup interval in seconds.
* SE_BROWSER_LEFTOVERS_PROCESSES_SECS: default value 7200 (2 hours), browsers running for longer than this time will be killed.
* SE_BROWSER_LEFTOVERS_TEMPFILES_DAYS: default value 1 (1 day), files generated by Chrome-based browsers in /tmp will be removed after these number of days (ignored when using Firefox).
If you use Selenium for long-running sessions and expect browsers to be running for longer than 2 hours, either do
not set SE_ENABLE_BROWSER_LEFTOVERS_CLEANUP to true (leave the default value of false), or tweak
SE_BROWSER_LEFTOVERS_PROCESSES_SECS to set a value higher than your expected long-running browser processes.

With the previous command, the cleanup will be enabled with the default timings.

With the previous command, the cleanup will be enabled, but will run every 2 hours (instead of 1), will kill browsers
running longer than 1 hour (instead of 2 hours), and will remove temp files older than 2 days (instead of 1).
---
Mask sensitive information in console logs  Copy Chapter
Few variables output like password, secret, etc. are masked in console logs. For debugging purposes, you can disable it by setting SE_MASK_SECRETS to false
While creating bash script, your can mask the output by using syntax echo "Current value is $(mask ${YOUR_VARIABLE})
SE_MASK_SECRETS_MIN_LENGTH default is 3. It means a long string will be masked to * to avoid exposing length for brute force attack.
Secure connection  Copy Chapter
By default, there are default self-signed certificates available in the image in location /opt/selenium/secrets includes
- server.jks: truststore file to configure for JVM via system property javax.net.ssl.trustStore when start the server.
- server.pass: file contains the truststore password for JVM via system property javax.net.ssl.trustStorePassword.
- tls.crt: Server certificate for https connection is set to Selenium option --https-certificate.
- tls.key: Server private key (in PKCS8 format) for https connection is set to Selenium option --https-private-key.
There are environment variables to configure the secure connection:
| Environment variables                 | Default                             | Option of | Description                                   |
|---------------------------------------|-------------------------------------|-----------|-----------------------------------------------|
| SE_ENABLE_TLS                         | false                             |           | Enable secure connection with default configs |
| SE_JAVA_SSL_TRUST_STORE               | /opt/selenium/secrets/server.jks  | JVM       |                                               |
| SE_JAVA_SSL_TRUST_STORE_PASSWORD      | /opt/selenium/secrets/server.pass | JVM       |                                               |
| SE_JAVA_DISABLE_HOSTNAME_VERIFICATION | true                              | JVM       | Disable host checks for components internally |
| SE_HTTPS_CERTIFICATE                  | /opt/selenium/secrets/tls.crt     | Selenium  | Set to CLI option --https-certificate       |
| SE_HTTPS_PRIVATE_KEY                  | /opt/selenium/secrets/tls.key     | Selenium  | Set to CLI option --https-private-key       |
Via volume mount, you can replace the default certificates with your own certificates.
The self-signed certificate also needs to be trusted by the client (add to system widely bundle trusted CA) to avoid error message relates to SSL handshake when creating RemoteWebDriver.
Refer to sample: docker-compose-v3-full-grid-secure.yml
Browser language and locale  Copy Chapter
Different browsers have different ways to set the language and locale from binding.
Firefox  Copy Section
Firefox can be configured to use a specific language and locale by setting the profile preference when create WebDriver from binding. In addition, language pack need to be installed as add-on for browser UI language to take effect. For example, to set the browser language and locale to vi-VN, you can use the following steps:
Get the latest Firefox language pack for the desired language e.g. https://download.mozilla.org/?product=firefox-langpack-latest-SSL&lang=vi. Then, you can install the language pack as an add-on when creating the RemoteWebDriver instance.

There is a script to get all available language packs for a given Firefox version. You can run the script to get the language packs to your source. For example:

Or, you can mount the container directory $(readlink -f $(which firefox)))/distribution/extensions to host directory to access packs were pre-built in the container for using in your test script.
Managing processes in container  Copy Chapter
Supervisor is used to manage processes and logs in the container. Few configuration for supervisord can be set via environment variables as below:
| Environment variables        | Default                | supervisord config    |
|------------------------------|------------------------|-------------------------|
| SE_SUPERVISORD_LOG_LEVEL     | info                 | supervisord.loglevel    |
| SE_SUPERVISORD_CHILD_LOG_DIR | /tmp                 | supervisord.childlogdir |
| SE_SUPERVISORD_LOG_FILE      | /tmp/supervisord.log | supervisord.logfile     |
| SE_SUPERVISORD_PID_FILE      | /tmp/supervisord.pid | supervisord.pidfile     |
___
Building the images  Copy Chapter
Clone the repo and from the project directory root you can build everything by running:

If you need to configure environment variables in order to build the image (http proxy for instance), 
simply set an environment variable BUILD_ARGS that contains the additional variables to pass to the 
docker context (this will only work with docker >= 1.9)

_Note: Omitting_ VERSION=local _will build the images with the released version but replacing the date for the 
current one._
If you want to build the image with the host UID/GID, simply set an environment variable BUILD_ARGS

If you want to build the image with different default user/password, simply set an environment variable BUILD_ARGS

___
Build the images with specific versions
Based on the latest Dockerfile (by cloning the repo and from the project directory root), you can build the images with a specific combination of Selenium Grid, and browser versions.
For example, you would like to build node-chrome and standalone-chrome images with the Grid based version 4.17.0, Chrome browser versions 119, 120, 123 respectively.

In generic, the script takes the following arguments:
- $1 (mandatory): Selenium Grid version. Details are fetching from matrix file
- $2 (mandatory): Browser major version, multiple values separated by comma. Details are fetching from matrix file
- $3 (optional): browser name. If not provided, it will iterate over all the browsers (chrome, edge, firefox)
- $4 (optional): Push image to registry. By default, it is false. If you want to push the image to the registry, set it to true (required Docker login to your namespace done before running the script).
To update the browser versions matrix, you can run the following command:

To set your namespace for the images, you can set the environment variable NAME before running the script. For example:

After running the script, you will see list images with a full tag to pin specific Grid and browser version following Tagging Conventions
---
Upgrade browser version in the images  Copy Chapter
Selenium server, browser and driver are pre-installed in the image. In case you would like to remain on the same Selenium version and just upgrade the browser and its driver to the latest. You can follow below steps
Clone the repo and from the project directory root you can upgrade by running:

For example: VERSION=4.16.1 make chrome_upgrade_version
The new image has tag $VERSION_YYYYMMDD where YYYYMMDD is the current date.

You can refer to detail commands in the Makefile file.
---
Upgrade browser and driver versions in the images  Copy Chapter
| Image name                     | Support |
|--------------------------------|---------|
| node-chrome, standalone-chrome | ✅       |
There are two ways of usage this feature.
1. Upgrade Chrome and ChromeDriver later in runtime (when starting the container). Set the container environment SE_UPDATE_CHROME_COMPONENTS to true. For example:

Tradeoff:
    Note that after the container gets restarted, updated binaries will be lost unless you call the update script within the build container process (the second usage below).
2. Build your own image by reusing image layers with upgrading Chrome and ChromeDriver to the latest
   Create a simple Dockerfile as below

- Option 1: Build your own image tag

- Option 2: Use Dockerfile in docker compose

---
Waiting for the Grid to be ready  Copy Chapter
It is a good practice to check first if the Grid is up and ready to receive requests, this can be done by checking the /wd/hub/status endpoint.
A Grid that is ready, composed of a hub and two nodes, could look like this:

The "ready": true value indicates that the Grid is ready to receive requests. This status can be polled through a
script before running any test, or it can be added as a HEALTHCHECK
when the docker container is started.
Adding a HEALTHCHECK to the Grid HEALTHCHECK to the Grid')" title="Copy section prompt for LLMs"> Copy Section
The script check-grid.sh, which is included in the images, can be used to poll the Grid status.
This example checks the status of the Grid every 15 seconds, it has a timeout of 30 seconds when the check is done,
and it retries up to 5 times until the container is marked as unhealthy. Please use adjusted values to fit your needs,
(if needed) replace the --host and --port parameters for the ones used in your environment.

Note: The \ line delimiter won't work on Windows-based terminals, try either ^ or a backtick.
The container health status can be checked by doing docker ps and verifying the (healthy)|(unhealthy) status or by
inspecting it in the following way:

Using a bash script to wait for the Grid  Copy Section
A common problem known in docker is that a running container does not always mean that the application inside it is ready.
A simple way to tackle this is by using a "wait-for-it" script, more information can be seen here.
The following script is an example of how this can be done using bash, but the same principle applies if you want to do this with the programming language used to write the tests.
In the example below, the script will poll the status endpoint every second. If the grid does not become ready within 30 seconds, the script will exit with an error code.

Will require jq installed via apt-get, else the script will keep printing Waiting without completing the execution.
Note: If needed, replace localhost and 4444 for the correct values in your environment. Also, this script is polling indefinitely, you might want
to tweak it and establish a timeout.
Let's say that the normal command to execute your tests is mvn clean test. Here is a way to use the above script and execute your tests:

Like this, the script will poll until the Grid is ready, and then your tests will start.
___
Install certificates for Chromium-based browsers  Copy Chapter
By default, the based image is installed libnss3-tools and initializes /home/seluser/.pki/nssdb,
so you are able to add your certs with rootless.
If you need to install custom certificates, CA, intermediate CA,
or client certificates (for example, enterprise internal CA)
you can create your own docker image from selenium node image.
The Chromium-based browser uses nssdb as a certificate store.
You can then install all required internal certificates in your Dockerfile like this:
There is a utility script packaged in the image that can be used to add your certificates to the nssdb store and the bundle CA.
The script is /opt/bin/add-cert-helper.sh.
- Create a Dockerfile that uses the selenium node image as a base and copies the script to the container, and executes it.
For example, Dockerfile
- If you have to create a set of different certificates and node images. You can create a bootstrap script to do that in one-shot.
For example, bootstrap.sh
The above example can be tested with the following command:

You can find more information here
This way the certificates will be installed and the node will start automatically as before.
___
Alternative method: Add certificates to existing Selenium based images for browsers  Copy Chapter
As an alternative, you can add your certificate files to existing Selenium images. This practical example
assumes you have a known image to use as a build image and have a way to publish new images to your local
docker registry.
This example uses a RedHat-based distro as a build image (Rocky Linux) but it can be any Linux image of your choice.
Please note that build instruction will vary between distributions. You can check the instructions for Ubuntu
in the previous example.
The example also assumes your internal CA is already in /etc/pki/ca-trust/source/anchors/YOUR_CA.pem,
the default location for Rocky Linux. Alternatively, you can also provide these files from your host and 
copy them into the build image.
For Chrome and Edge browsers, the recipe is the same, just adapt the image name (node-chrome or node-edge):

Example for Firefox:

___
Debugging  Copy Chapter
This project uses x11vnc as a VNC server to allow users to inspect what is happening
inside the container. Users can connect to this server in two ways:
Using a VNC client  Copy Section
The VNC server is listening to port 5900, you can use a VNC client and connect to it. Feel free to map port 5900 to 
any free external port that you wish.
The internal 5900 port remains the same because that is the configured port for the VNC server running inside the container. 
You can override it with the SE_VNC_PORT environment variable in case you want to use --net=host.
Here is an example with the standalone images, the same concept applies to the node images.

Then, you would use in your VNC client:
- Port 5900 to connect to the Chrome container
- Port 5901 to connect to the Edge container
- Port 5902 to connect to the Firefox container
If you get a prompt asking for a password, it is: secret. If you wish to change this, 
you can set the environment variable SE_VNC_PASSWORD.
If you want to run VNC without password authentication you can set the environment variable SE_VNC_NO_PASSWORD=true.
If you want to run VNC in view-only mode you can set the environment variable SE_VNC_VIEW_ONLY=true.
If you want to modify the open file descriptor limit for the VNC server process you can set the environment variable SE_VNC_ULIMIT=4096.
Using your browser (no VNC client is needed)  Copy Section
This project uses noVNC to allow users to inspect visually container activity with
their browser. This might come in handy if you cannot install a VNC client on your machine. Port 7900 is used to start
noVNC, so you will need to connect to that port with your browser.
Similarly to the previous section, feel free to map port 7900 to any free external port that you wish.
You can also override it with the SE_NO_VNC_PORT environment variable in case you want to use --net=host.
Here is an example with the standalone images, the same concept applies to the node images.

Then, you would use in your browser:
- http://localhost:7900/ to connect to the Chrome container
- http://localhost:7901/ to connect to the Edge container
- http://localhost:7902/ to connect to the Firefox container
If you get a prompt asking for a password, it is: secret.
Disabling VNC  Copy Section

If You are running low on resources, or simply don't need to inspect running sessions, it is possible to not run VNC at all.
Just set

environment variable on the grid startup.
___
Tracing in Grid  Copy Chapter
In order to enable tracing in the Selenium Grid container, the following commands can be executed:

You can also refer to the below docker compose yaml files to be able to start a simple grid (or) a dynamic grid.
* Simple Grid v3 yaml file
* Simple Grid v2 yaml file
* Dynamic Grid v3 yaml file
You can view the Jaeger UI and trace your request.
By default, the tracing is enabled in Grid components. Without trace exporter endpoint, it will look up a local instance e.g. localhost/[0:0:0:0:0:0:0:1]:4117.
In container logs you can see few lines like below:

In this case, just simply set SE_ENABLE_TRACING=false to all components container to disable tracing (each component exports its own traces).
___
Troubleshooting  Copy Chapter
All output gets sent to stdout, so it can be inspected by running:

You can increase the log output by passing environment variable to the containers:

--shm-size="2g" ')" title="Copy section prompt for LLMs"> Copy Section
Why is --shm-size 2g necessary?
This is a known workaround to avoid the browser crashing inside a docker container, here are the documented issues for

Chrome and Firefox.
The shm size of 2gb is arbitrary but known to work well, your specific use case might need a different value, it is recommended
to tune this value according to your needs.

Headless  Copy Section
If you see the following selenium exceptions:
Message: invalid argument: can't kill an exited process
or
Message: unknown error: Chrome failed to start: exited abnormally
or
 [DriverServiceSessionFactory.apply] - Error while creating session with the driver service. Stopping driver service: java.util.concurrent.TimeoutException
The reason _might_ be that you've set the SE_START_XVFB environment variable to false, but forgot to 
actually run Firefox, Chrome or Edge in headless mode.
Mounting volumes to retrieve downloaded files  Copy Section
A common scenario is mounting a volume to the browser 
container in order to retrieve downloaded files. This
works well in Windows and macOS but not without 
workarounds in Linux. For more details, check this
well-documented issue.
For example, while using Linux, you might be starting a
container in the following way:

That will mount the host /home/ubuntu/files directory
to the /home/seluser/Downloads inside the container
(default browser's downloads directory). The
problem happens because the volume will be mounted as
root; therefore, the browser cannot write a file to
that directory because it is running under the user 
seluser. This happens because that is how Docker mounts
volumes in Linux, more details in this issue.
A workaround for this is to create a directory on the
host and change its permissions before mounting the volume. 
Depending on your user permissions, you might need to use 
sudo for some of these commands:

After doing this, you should be able to download files
to the mounted directory. If you have a better workaround,
please send us a pull request!
Mounting volumes to retrieve video files  Copy Section
Similar to mount volumes to retrieve downloaded files. For video files, you might need to do the same