Sick of messy Selenium setups? Docker it like a pro—fast, clean, done.
Docker for Testers isn’t just a fancy tech trend—it’s your new best friend if you’re tired of the “It works on my machine” circus. I’ve been in rooms where test environments collapsed minutes before a demo. Selenium Grid broke, browsers misbehaved, and we testers got blamed. Sound familiar?
Now imagine spinning up a clean, fully functional Selenium Grid in literally 10 minutes—on any machine, with zero setup drama. That’s what Docker brings to the table. And once you get the hang of it, you’ll wonder how you ever lived without it.
If you’re still running Selenium tests on your local Chrome like it’s 2013… stop. Just stop.
Docker lets you:
Test on any browser/version without installing anything
Spin up isolated test environments like magic
Avoid the “It works on my machine” crap
Wait—I almost forgot. Ever seen Jenkins scream in red because your dev used Chrome 122, and you have 117? Docker fixes that too.
I once spent 3 hours installing Selenium Grid manually for a demo. XML configs. Port conflicts. Firefox throwing tantrums. Felt like assembling IKEA furniture blindfolded.
Then Docker walked in like:
“Chill, I got this.”
Now I spin it up in under 10 minutes, coffee still hot.
This setup works on Mac, Linux, or Windows. Just install:
(Optional) VS Code with Docker extension
Basic command line skills (copy-paste counts)
Create a file called docker-compose.yml
and paste this in:
version: "3"
services:
selenium-hub:
image: selenium/hub:4.21.0
container_name: selenium-hub
ports:
- "4442:4442"
- "4443:4443"
- "4444:4444"
chrome:
image: selenium/node-chrome:4.21.0
shm_size: 2gb
depends_on:
- selenium-hub
environment:
- SE_EVENT_BUS_HOST=selenium-hub
- SE_EVENT_BUS_PUBLISH_PORT=4442
- SE_EVENT_BUS_SUBSCRIBE_PORT=4443
firefox:
image: selenium/node-firefox:4.21.0
shm_size: 2gb
depends_on:
- selenium-hub
environment:
- SE_EVENT_BUS_HOST=selenium-hub
- SE_EVENT_BUS_PUBLISH_PORT=4442
- SE_EVENT_BUS_SUBSCRIBE_PORT=4443
Open terminal, go to the folder with your YAML file, and run:
docker-compose up -d
Boom. No drivers. No config files. Just boom.
Go to:
http://localhost:4444/ui
You’ll see a slick Selenium Grid UI showing Chrome and Firefox nodes. Clicking stuff there? It actually feels good.
Yup. Misconfigured my Docker network. Ended up hitting PROD APIs with my test scripts running on Grid.
Lesson: always, always check your target URL before you run anything. Even if it’s 2AM and Jenkins is nagging you.
Bad Selenium Grid | Great Selenium Grid |
---|---|
Hardcoded paths | Dockerized setup |
Manual node add | docker-compose magic |
OS-specific | OS-agnostic |
Works once | Scalable & repeatable |
Eats RAM like cake | Controlled resource usage |
Set browser version tags (e.g., node-chrome:114.0
)
Avoid network name clashes
Use shared volumes only if needed
Clean up after yourself (docker rm -f $(docker ps -aq)
if things go south)
Use headless mode for CI—ALWAYS
docker-compose
over manual setupdocker logs -f selenium-hub
)4444
for your test scriptsDocker lets you package your environment, tools, and apps into containers. As a tester, that means you can say goodbye to “But it worked on my machine!” excuses. Consistency is king.
Yes! Docker Desktop supports Windows (with WSL 2). Just install Docker Desktop, enable WSL integration, and you’re good to go.
Use a pre-built docker-compose.yml
. In about 10 minutes, you can spin up a hub and multiple nodes (Chrome, Firefox). Your setup will look clean, versioned, and portable.
Because maintaining local browser versions is a nightmare. Docker isolates and manages everything. Plus, running parallel tests on multiple browsers? Docker makes that cakewalk.
Navigate to http://localhost:4444/ui
after running your docker-compose
file. The grid dashboard will show available nodes and browser sessions.
Hub: The central point where test scripts connect.
Nodes: Where the actual browser instances run.
Absolutely. That’s actually where it shines the most. Integrate it with Jenkins, GitHub Actions, or GitLab CI for full test automation on push or PR.
docker-compose down
docker system prune -f
The first stops/removes containers, the second cleans dangling images and networks.
Port conflicts (especially 4444)
Browser node crashes if you mismatch versions
Slow container startup on older machines
Chrome nodes silently failing due to missing memory or bad config
Check the official Selenium Docker GitHub repo. They maintain versioned hub and node images for Chrome, Firefox, Edge.
Yes. Just modify your docker-compose.yml
to add more Chrome/Firefox services and assign different container names/ports.
Yes. Tools like Selenoid offer a more lightweight and efficient Docker-based Selenium execution option. Great for resource-constrained machines.
Docker for testers isn’t “nice to have” anymore. It’s table stakes.
The next time someone says “But it worked on my machine,” throw a Dockerfile at their face.
This setup saved me HOURS and actually made me look smart in front of the devs. That never happens. 😅
Also Don’t forget to check our blogs.
Designed by ScriptNG
One Response