In Selenium's Docker images, why is --shm-size=2g recommended for browser containers?
answer
- The browser needs room the container withholds
- Look at a shared-memory filesystem
- The browser crashes rather than slowing down
- A docker run flag sized in gigabytes
- shm_size: 2gb in compose
basics
~20 sBrowsers put rendered content in the shared-memory filesystem /dev/shm, and Selenium's image docs say Chrome crashes on the small 64 MB allocation a container gets by default. Passing --shm-size=2g, or shm_size: 2gb in compose, gives it room.
solid answer
~40 sSelenium's browser images run a real Chrome, Edge or Firefox inside the container, and those browsers pass rendered content between their processes through `/dev/shm`. Selenium's own image documentation states that Chrome will crash on the default 64 MB `/dev/shm`, which is why every `docker run` example for `selenium/standalone-chrome` and `selenium/node-chrome` carries `--shm-size="2g"` and every browser service in the project's compose files sets `shm_size: 2gb`. Selenium calls 2 GB arbitrary but known to work well and recommends tuning it — the all-browsers images are documented at `3g`. The alternative lever the images ship is the `SE_BROWSER_ARGS_` prefix, which appends a browser argument such as `--disable-dev-shm-usage`; Selenium's own Helm chart injects exactly that when a node has no shared-memory volume size configured.
code
bash · 4 linesdocker run -d --name loan-renewal-browser \
-p 4444:4444 -p 7900:7900 \
--shm-size="2g" \
selenium/standalone-chrome:4.48.0-20260905go deeper
Be ready to name the symptom and the fix: browsers inside Selenium's images crash when the container's /dev/shm is too small, and --shm-size=2g, or shm_size: 2gb in a compose file, is the documented remedy.
Explain why a multi-process browser needs shared memory at all, why a container's allocation is small, and what the second lever is — the SE_BROWSER_ARGS_ prefix that appends --disable-dev-shm-usage so the browser writes to disk instead.
Show that you would recognise this from the outside: sessions dying mid-run on the heaviest pages, worse on the most loaded containers. Then size shared memory per browser rather than copying 2 GB everywhere in the fleet.
Own it as fleet policy. Decide whether shared memory is sized in the container specification or worked around with a browser argument, apply one choice everywhere, and make sure nobody on the team debugs the same crash twice.
## What `/dev/shm` is doing for a browser `/dev/shm` is a shared-memory filesystem: a directory backed by RAM that separate processes can use to hand each other large blocks of data without copying them through a pipe. Modern browsers are multi-process by design — a browser process, one or more renderer processes, a GPU process — and they use exactly that filesystem to pass rendered content between those processes. On a desktop the allocation is generous and nobody thinks about it. Inside a container it is a small fixed size, and Selenium's own image documentation is blunt about the consequence: **Chrome will crash on the default 64 MB `/dev/shm`**. That is why every browser-image example the project publishes carries the size flag, and why the recommendation appears at the very top of the Quick Start rather than buried in a troubleshooting note. ## The symptom, and why it reads as flake - The session **starts cleanly**. The remote end accepts the new session, the client gets a driver back, and the first navigations work. - The browser dies **part-way through a page**, so the client sees the browser exiting or the connection dropping mid-command, not a capacity error. - It hits **heavier pages first**. A loan-renewal page with a long borrowed-items table, an embedded date picker and a cover-image grid is far more likely to trip it than the catalogue search that precedes it. - It looks **intermittent**, because whether the allocation runs out depends on what the page happened to render, so the first instinct is usually to add a wait rather than to look at the container. Selenium's FAQ describes the size flag as a known workaround for the browser crashing inside a container, and links the upstream Chrome and Firefox reports that document it. Treating this as a test-code problem is the classic wrong turn. ## The documented fix, in each place a container starts | Where you start it | What you set | Example value | |---|---|---| | `docker run` | `--shm-size` | `--shm-size="2g"` | | The project's compose files | `shm_size` on each browser service | `shm_size: 2gb` | | Selenium's `selenium-grid` Helm chart | `dshmVolumeSizeLimit` on a node | `"2Gi"`, mounted as a memory volume at `/dev/shm` | The value is not magic. Selenium calls 2 GB **arbitrary but known to work well** and recommends tuning it to your use case — and applies the same reasoning upward, documenting `--shm-size="3g"` for the `selenium/standalone-all-browsers` and `selenium/node-all-browsers` images because one container is holding more browsers. ## The other lever: keeping the browser off shared memory Chromium-family browsers accept an argument that makes them write to a temporary directory on disk instead of `/dev/shm`. Selenium's Chrome, Chromium and Edge node images expose a way to append arbitrary browser arguments: **any environment variable whose name begins with `SE_BROWSER_ARGS_`** has its value appended to the browser's command line, with the suffix chosen by you. The project's own Helm chart uses this as the fallback path — when a node has no `dshmVolumeSizeLimit` configured, the chart injects `SE_BROWSER_ARGS_DISABLE_DSHM` carrying `--disable-dev-shm-usage` so the browser never depends on the small allocation in the first place. The two levers are alternatives, and worth being deliberate about: 1. **Enlarge `/dev/shm`** when you want the browser running the way it does on a desktop and can afford the RAM. 2. **Move the browser off `/dev/shm`** when you cannot control the container's shared-memory size — the browser then pays disk I/O instead of memory. ## Sizing it for a real fleet - Size **per browser**, not per fleet. A container holding one Chrome and a container holding three need different numbers, and copying 2 GB everywhere is how a fleet ends up both wasteful and still crashing. - Remember the allocation is **shared inside the container**. Raising the sessions a node offers without raising this number moves the crash rather than fixing it. - Firefox images get the same treatment in Selenium's own compose files and `docker run` examples, so do not treat this as a Chrome-only ritual. - Make it **uniform**. Whichever lever you pick, apply it in one place for every browser container you run, so nobody on the team debugs the same crash twice. The short version to carry into an interview: browsers put rendered content in shared memory, containers hand out very little of it, Selenium's images document the crash and the fix, and the fix lives in the container specification — `--shm-size`, `shm_size`, or the chart's `dshmVolumeSizeLimit` — not in your test code.
- What does the failure actually look like from the test's side?Not a clean error. The session starts, the first navigations work, and then the browser dies part-way through a page, so the client reports the browser exiting or the connection dropping mid-command. It shows up on heavier pages first, which makes it look like an intermittent test rather than a container that was sized wrong.
- Does Firefox need the same treatment as Chrome?Selenium's own compose files set `shm_size: 2gb` on the Firefox node service and its `docker run` examples pass `--shm-size="2g"` for `selenium/standalone-firefox`, so the project applies it to Firefox too. The upstream crash reports the FAQ links cover both browsers, so this is not a Chrome-only ritual.
- Is 2 GB a required value?No. Selenium's documentation calls 2 GB arbitrary but known to work well and recommends tuning it to your use case. The same reasoning is applied upward: the `selenium/standalone-all-browsers` and `selenium/node-all-browsers` images are documented with `--shm-size="3g"` because one container holds more browsers.
Shared memory is the browser's scratch bench. On a desktop it is a full workshop table, but a container hands the browser a bench barely wide enough for one page, so it runs out of room mid-render and falls over rather than tidying up.
saying these in an interview costs you the question
- Says the browser only slows down when shared memory runs short
- Looks for an SE_ environment variable that sets the shared-memory size
- Blames flaky waits when the browser is dying from shared memory
- Assumes headless mode removes the browser's need for shared memory
- Treats 2 GB as a fixed requirement rather than a tunable starting point