# A Minimal Docker Wrapper for Headless Chrome, Frozen in 2017 > This image packages Google Chrome in headless mode for Docker, but its last push was in 2017 and the maintainer now asks for paid support. Useful for legacy pipelines, not for new projects. **femtopixel/docker-google-chrome-headless** — Google Chrome Headless - Docker Image - Repository: https://github.com/femtopixel/docker-google-chrome-headless - Website: https://brands.jaymoulin.me/femtopixel/docker-google-chrome-headless/ - Stars: 22 · Forks: 4 - Language: Dockerfile - License: MIT - Published: 2026-08-22 · Updated: 2026-08-22 · Language: en - Canonical page: https://hysenlabs.com/projects/femtopixel-docker-google-chrome-headless ## What This Image Actually Provides This repository builds a Docker image that runs Google Chrome in headless mode. The README describes headless Chrome as a browser that can start without a graphical interface to perform tasks like PDF printing, performance measurement, and automation. The image is for developers who want a disposable, containerized Chrome instance that they can launch with a single docker run command and then connect to via the DevTools protocol on port 9222. It solves the problem of installing Chrome on a host machine or in a CI environment, which can be messy due to dependencies and sandboxing requirements. The intended user is someone who needs a quick, scriptable browser for testing or scraping, not a full browser automation framework. ## How the Image Works and What You Get The image runs Chrome with the --headless flag and exposes the debugging port. By default, Chrome listens on port 9222 inside the container, and you map that port to a host port using the -p flag. The README shows a basic command: docker run --rm --name chrome -it -p 9222:9222 femtopixel/google-chrome-headless . You can pass any Chrome command-line arguments before the URL, and the URL defaults to about:blank if omitted. The port can be changed by setting the CHROME_DEBUG_PORT environment variable, as shown in the example with -e CHROME_DEBUG_PORT=9000 and -p 9000:9000. The image is minimal, with no entrypoint script or complex logic visible in the README. It is essentially a wrapper that passes through arguments to Chrome. The 0.2.0 release notes say the image is multiarch and uses Chromium instead of Chrome, which is a notable shift, but the README still refers to Google Chrome throughout. ## Getting It Running: Commands and Configuration The README gives concrete commands. The simplest invocation is docker run --rm --name chrome -it -p 9222:9222 femtopixel/google-chrome-headless http://www.google.com, which starts the container and keeps it attached. To change the port, you set the environment variable: docker run --rm --name chrome -it -p 9000:9000 -e CHROME_DEBUG_PORT=9000 femtopixel/google-chrome-headless. For security, the README suggests two options. One is adding the SYS_ADMIN capability: --cap-add SYS_ADMIN, which grants the container additional privileges that Chrome may need for sandboxing. The other is using a seccomp profile from Jessie Frazelle's dotfiles repository, which you download to ~/chrome.json and then pass with --security-opt seccomp=$HOME/chrome.json. These are the only configuration keys mentioned. There is no mention of volumes, custom user IDs, or environment variables beyond CHROME_DEBUG_PORT. ## The Critical Limitation: It Is Abandoned The most significant limitation is that the repository has not been pushed to since November 30, 2017. The README contains a caution notice, added later, stating that as of 2021 the product does not have a free support team anymore, and that financial support is required for the product to be maintained. This means the image likely contains a Chrome version from 2017 or earlier, which has known security vulnerabilities and lacks modern web platform features. For any serious use, especially in a production or public-facing context, this is a dealbreaker. The image also has a note that it is auto-updated by a bot when a new Google Chrome release is unleashed, but the last push date contradicts that claim. Either the bot stopped working, or the maintainer turned off the automation. Either way, you cannot rely on this image to stay current. If you need a headless browser that supports modern JavaScript, TLS, or web standards, this image is the wrong tool. ## Security and Runtime Trade-offs The README acknowledges that running Chrome in Docker may require extra security context. The SYS_ADMIN capability is a heavy hammer, as it grants broad privileges that can undermine container isolation. The seccomp profile approach is more granular, but the profile is an external file from a third-party repository, and you have to trust that it is still compatible with the Chrome version in this image. The README does not explain why these are needed, only that you may need to add them. This is a real trade-off: you can run the container with default settings and hope the sandbox works, or you can add privileges that increase risk. For a 2017-era Chrome, the sandbox may not even function correctly in a modern Docker environment, so the seccomp profile might be outdated. The documentation is thin on this point, and the absence of any troubleshooting section makes it hard to diagnose failures. ## Alternatives and How They Differ A practical alternative is the official Chromium image from the Chromium project, or a maintained project like browserless, which provides a Docker image for headless Chrome with a REST API and WebSocket support. The key difference is that browserless is actively maintained, supports current Chrome versions, and offers a higher-level interface for common tasks like PDF generation and screenshots. Another option is to build your own Dockerfile that installs the latest Chrome from a trusted repository, giving you full control over the version and security updates. The femtopixel image is a single-purpose wrapper with no orchestration or management features. If you need to run many browser instances or integrate with a test framework, you would likely need to add your own tooling around this image. The alternative approaches give you more control over the browser version and update cadence, which matters for security and feature support. ## Maintenance Cost and License Implications The project is licensed under the MIT license, which is permissive and allows free use and modification. However, the README makes it clear that the maintainer is asking for financial support to continue development. This is not a legal restriction, but it signals that you should not expect fixes or updates unless you pay. The maintenance cost for you as an adopter is therefore high: you would need to fork the repository, update the Chrome version yourself, and rebuild the image. The last release, 0.2.0, mentions multiarch and using Chromium instead of Chrome, but there is no documentation on how to build the image from source or what base image it uses. The Dockerfile is the primary language, but the repository does not show the Dockerfile content in the README, so you would have to inspect the repository directly to understand the build process. For a project this old, the upgrade path is essentially a rewrite, not a minor tweak. ## Conclusion Adopt this image only if you need a quick way to run headless Chrome in a Docker container for an existing legacy workflow and you accept that it has not been updated since 2017. Do not use it for new projects, because the image uses an outdated Chrome version and the maintainer now requires paid support for continued maintenance. Before adopting, verify that the Chrome version inside the image meets your security and feature requirements, test the image on your target architecture (the 0.2.0 release claims multiarch support), and check whether the seccomp profile or --cap-add SYS_ADMIN is necessary in your environment. If you need a maintained headless browser in Docker, look at alternatives like browserless or the official Chromium images. ## FAQ ### What does headless Chrome mean in this image? It is the Chromium browser started without a graphical interface, which the README links to as accomplishing PDF printing, performance work and automation. In the container that means no display, no window manager and a browser reachable only through the remote debugging port. ### What is Docker used for with femtopixel/google-chrome-headless? It gives you a browser that starts from one docker run command and leaves nothing behind, since the documented invocation uses --rm. The image downloads a Chromium snapshot, runs it as an unprivileged user and exposes the debug port, defaulting to 9222. ### What are the disadvantages of running a headless browser in a container? Chrome's sandbox needs capabilities a default container withholds, so the README documents both --cap-add SYS_ADMIN and the Jessie Frazelle seccomp profile as workarounds. Both widen the browser process's permissions, and neither is enabled by the image. ## Sources - [Official documentation](https://brands.jaymoulin.me/femtopixel/docker-google-chrome-headless/) - [Official README](https://github.com/femtopixel/docker-google-chrome-headless#readme) - [Project repository](https://github.com/femtopixel/docker-google-chrome-headless) - [Release notes](https://github.com/femtopixel/docker-google-chrome-headless/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/femtopixel-docker-google-chrome-headless