# danlynn/ember-cli: A Docker Image That Pins Your Ember Toolchain to Known Versions

> The danlynn/ember-cli image bundles ember-cli, Node, npm, bower, yarn, Chrome, and watchman into a single container. It is a practical way to keep an Ember development environment reproducible, but its value depends on how closely you track its version tags.

**danlynn/ember-cli** — ember-cli docker image providing a complete development environment

- Repository: https://github.com/danlynn/ember-cli
- Website: https://hub.docker.com/r/danlynn/ember-cli/
- Stars: 100 · Forks: 29
- Language: Dockerfile
- License: MIT
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/danlynn-ember-cli

## What This Image Solves for Ember Developers

The danlynn/ember-cli image addresses a specific pain: setting up a local Ember development environment that matches what your team or CI uses. Ember projects depend on a specific ember-cli version, and that version in turn expects a certain Node major version. On a developer laptop, you might have Node 20 installed while the project needs Node 24, or you might have a global ember-cli that is newer than the project's. This image bundles ember-cli, Node, npm, bower, yarn, Chrome, and watchman into one container, so you can run `ember` commands inside a container that has the right versions. The README states the container's working directory is /myapp, and you map your project directory to that path. The intended user is someone who works on multiple Ember projects with different toolchain requirements, or who wants to avoid installing Chrome and watchman on their host machine just to run tests.

## The Version Matrix: How the Tags Work

The image is organized around ember-cli versions, and each version has one or more Node variants. For example, the 7.1.0 tag includes ember-cli 7.1.0, node 24.18.0, npm 11.16.0, bower 1.8.8, yarn 1.22.22, chrome 150.0.7871.128, and watchman 4.9.0. There is also a 7.1.0-node_26.5 tag that uses node 26.5.0. The README lists tags for ember-cli 6.11.0, 6.10.0, 6.8.0, and many older versions, each with Node variants. This matrix means you are not stuck with a single Node version for a given ember-cli release. The `latest` tag points to 7.1.0, which is useful for quick experiments but risky for production work because it will change when a new ember-cli version is released. The version-specific tags are the ones you should use if you want reproducibility.

## What Is Inside the Container and Why It Matters

The README lists the exact versions of each tool in the 7.1.0 image. That level of detail is unusual and valuable. Knowing that Chrome is at 150.0.7871.128 means you can predict what your tests will run against, which is important because Chrome updates frequently and can change behavior. Watchman 4.9.0 is included, which Ember CLI uses for file watching; without it, some setups fall back to polling, which is slower. The image also includes bower and yarn, which are legacy tools but still present in some Ember projects. The presence of both npm and yarn means you can choose your package manager without installing it yourself. The trade-off is that the image is large, because it includes a full Chrome browser and watchman. You are not told the image size in the README, but a container with Chrome is typically several hundred megabytes.

## Getting Started: Commands and Configuration

The README does not show explicit run commands, but the working directory and volume mapping are described. Based on the Docker Hub page, the typical usage is to run `docker run -it -v $(pwd):/myapp danlynn/ember-cli:7.1.0 ember new my-app` to create a new project, or `docker run -it -v $(pwd):/myapp danlynn/ember-cli:7.1.0 ember test` to run tests in an existing project. The working directory being /myapp means you must mount your project there. If you do not mount a volume, the container will start with an empty /myapp directory, and any files you create inside the container will be lost when the container exits. You should also ensure that your project's package.json and ember-cli-build.js are present in the mounted directory. The README does not mention environment variables or entrypoint scripts, so the image likely uses the default entrypoint, which runs the command you pass to `docker run`.

## A Real Limitation: Version Drift and Legacy Tools

The most obvious limitation is that the image packages bower and yarn, which are no longer the default package managers for new Ember projects. Bower is deprecated, and yarn 1.22.22 is an older version. If your project uses npm only, having bower and yarn in the image is harmless but adds bloat. A more serious limitation is that the image version tags are tied to ember-cli releases, but the Node versions are specific patch versions. If your project requires a Node version that is not listed for your ember-cli version, you cannot use this image without modifying it. For example, if you need ember-cli 6.11.0 with Node 24.13, the tag exists, but if you need Node 24.14 specifically, you are out of luck. The image also does not include a database or a backend, so it is not a full development environment for an Ember app that talks to a separate API. You would need to run that API separately, either on your host or in another container.

## How It Compares to a DIY Dockerfile or npx

The alternative to this image is to create your own Dockerfile that installs the exact Node version, ember-cli, Chrome, and watchman you need. That approach gives you full control over each tool's version and lets you omit bower and yarn if you do not need them. The cost is that you must maintain the Dockerfile and update it when you upgrade your project. Another alternative is to use `npx ember-cli` on your host machine, which downloads and runs the ember-cli package without a global install. However, `npx` does not solve the Node version mismatch problem, and it does not provide Chrome or watchman. The danlynn image is a middle ground: it provides a known-good combination of tools, but you are limited to the combinations the maintainer publishes. If you need a custom combination, you are better off writing your own Dockerfile.

## Maintenance, Licensing, and Upgrade Path

The repository is MIT licensed, so you can use and modify the Dockerfile freely. The README shows a long history of version tags, from 5.12.0 up to 7.1.0, which suggests the maintainer keeps the image updated when new ember-cli versions are released. However, the last push date is unknown, and there are no recent releases listed. That means you cannot confirm how quickly the image is updated after a new ember-cli version. When you upgrade your Ember project, you will likely need to upgrade the image tag as well, and you should check the Dockerfile for the new tag to see if the tool versions changed. The image does not include a mechanism for auto-updating, so you are responsible for pulling new tags and testing your project against them. The MIT license means you can fork the repository and build your own image if the published tags do not meet your needs.

## Conclusion

Adopt danlynn/ember-cli if you need a reproducible Ember development environment without managing Node, Chrome, and watchman yourself, and if you can align your project with one of the published version tags. Do not use it if you need a custom toolchain combination, if you must stay on a Node version not offered in the tags, or if you prefer to control each tool separately. Before adopting, verify that the tag you plan to use matches the ember-cli and Node versions your project requires, and check the Dockerfile for that tag to see how the image is built. The image is MIT licensed, but you are responsible for keeping your own project dependencies in sync with the container's versions.

## FAQ

### how to install ember cli with this repository

Pull the published image from hub.docker.com/r/danlynn/ember-cli and map your project directory onto /myapp in the container, because that is the working directory the image is built around. Tags exist per ember-cli version and Node version, and latest points at 7.1.0 on Node 24.18.

### what is ember cli in this repository

The repository is not ember-cli itself. It is a Docker image providing a complete development environment for ember-cli, bundling ember-cli 7.1.0, Node, npm, bower, Chrome, and watchman on top of node:24.18.0-bullseye.

### Which ports does the danlynn ember-cli image expose?

Port 4200 for the ember server, port 7020 for the livereload server, which changed from 49153 in v2.17.0, and port 7357 for the test server. The container's default command is ember server.

### Why does the image install Chrome with the sandbox disabled?

Chrome is installed from Google's apt repository for the default testem config, and then the launcher at /opt/google/chrome/google-chrome is patched with sed to add --no-sandbox, which is what allows it to run as root inside the container.

### How is watchman installed in the ember-cli image?

It is compiled from source rather than installed as a package. The Dockerfile installs python-dev, clones watchman at branch v4.9.0 with depth 1, runs autogen.sh, configures with CXXFLAGS=-Wno-error, then make and make install. A README note covers raising fs.inotify.max_user_watches.

## Sources

- [Official documentation](https://hub.docker.com/r/danlynn/ember-cli/)
- [Official README](https://github.com/danlynn/ember-cli#readme)
- [Project repository](https://github.com/danlynn/ember-cli)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/danlynn-ember-cli