You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: website_and_docs/content/blog/2026/selenium-grid-docker-images-are-now-mirrored-to-ghcr.md
+4-17Lines changed: 4 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ description: >
13
13
14
14
The request started with a simple question in [issue #2939](https://github.com/SeleniumHQ/docker-selenium/issues/2939): can we publish Selenium Grid Docker images to GitHub Container Registry as well as Docker Hub?
15
15
16
-
The answer is now yes.
16
+
The answer is now, Yes.
17
17
18
18
Official Selenium Grid Docker images are now available from **GitHub Container Registry (GHCR)** under:
19
19
@@ -27,16 +27,16 @@ This is a mirror, not a replacement. Docker Hub remains available, and existing
27
27
28
28
The original issue highlighted a problem many teams have run into over the last year: relying on a single public registry creates unnecessary friction.
29
29
30
-
For some users, Docker Hub rate limits are the main concern. For others, the issue is policy. Some companies no longer allow pulls from Docker Hub in CI or on developer machines. Others want to stay closer to GitHub-hosted infrastructure because their build pipelines already run in GitHub Actions.
30
+
Issue [#2939](https://github.com/SeleniumHQ/docker-selenium/issues/2939), opened on **August 27, 2025**, started with Docker Hub rate limits but quickly exposed a broader need. For some teams, Docker Hub is inconvenient. For others, it is restricted entirely by policy. The discussion also surfaced concrete use cases around GitHub Actions workflows, especially from forks, enterprise environments that disallow Docker Hub, and local development without Docker Hub authentication.
31
31
32
32
Publishing to GHCR improves that situation in a few practical ways:
33
33
34
34
- It gives users an official alternative registry for the same Selenium Grid images.
35
35
- It reduces dependency on a single distribution channel.
36
36
- It makes adoption easier for teams that already standardize on GitHub-hosted packages.
37
-
- It improves resilience when one registry is slow, restricted, or temporarily unavailable.
37
+
- It improves resilience during registry outages, service limits, or access restrictions.
38
38
39
-
This was not just a theoretical request. The discussion on the issue included examples from users who needed GHCR for local development, fork-based GitHub Actions workflows, and enterprise environments where Docker Hub access is restricted.
39
+
The result is a practical improvement to how Selenium Grid images are distributed: one image set, one familiar naming scheme, and more than one official place to pull from.
40
40
41
41
## What is available
42
42
@@ -95,19 +95,6 @@ This rollout is intentionally additive.
95
95
96
96
That matters because the goal here is flexibility, not churn. Teams that are happy with Docker Hub can stay where they are. Teams that need GHCR can move immediately without waiting for custom mirrors or maintaining internal rebuilds of Selenium Grid images.
97
97
98
-
## From request to delivery
99
-
100
-
Issue [#2939](https://github.com/SeleniumHQ/docker-selenium/issues/2939) was opened on **August 27, 2025** to propose dual publishing to Docker Hub and GHCR. The request was driven by Docker Hub rate limits, but the conversation quickly broadened into a more durable point: official images should be available from more than one registry.
101
-
102
-
That feedback held up. Contributors and users pointed to several real-world reasons for supporting GHCR:
103
-
104
-
- GitHub Actions workflows, especially from forks
105
-
- enterprise environments that disallow Docker Hub
106
-
- local development without Docker Hub authentication
107
-
- better resilience during registry outages or service limits
108
-
109
-
The result is a practical improvement to how Selenium Grid images are distributed: one image set, one familiar naming scheme, and more than one official place to pull from.
110
-
111
98
## Thank you
112
99
113
100
Thanks to everyone who raised the need, added concrete use cases, and helped push the rollout forward. Community feedback in issue [#2939](https://github.com/SeleniumHQ/docker-selenium/issues/2939) helped move this from a feature request into delivered infrastructure.
0 commit comments