Introduction

sh: 1: react-scripts: not found inside Docker usually means the container does not have the package installed where the runtime expects it. In Create React App projects, react-scripts normally comes from node_modules, so the error usually points to a dependency install problem, a bad copy order in the Dockerfile, or a bind mount that hides the installed dependencies.

Why the command fails

A CRA project typically runs scripts from package.json, such as:

1{
2  "scripts": {
3    "start": "react-scripts start",
4    "build": "react-scripts build"
5  }
6}

When Docker runs npm start or npm run build, Node looks for react-scripts in the project's local node_modules/.bin. If that directory does not exist in the container, or if the package is missing from dependencies, the shell reports that it cannot find react-scripts.

A correct Dockerfile pattern

The usual fix is to copy dependency manifests first, install dependencies, then copy the rest of the source.

1FROM node:20-alpine
2
3WORKDIR /app
4
5COPY package.json package-lock.json ./
6RUN npm ci
7
8COPY . .
9
10EXPOSE 3000
11CMD ["npm", "start"]

This pattern matters because Docker layer caching lets dependency installation be reused unless the manifest files change. More importantly, it ensures node_modules is installed inside the image before the application runs.

Make sure react-scripts is really a dependency

Check package.json and confirm that react-scripts is listed under dependencies or devDependencies, depending on how the image is built.

npm ls react-scripts

If the project does not actually include react-scripts, Docker cannot fix that for you. The image is only as correct as the application metadata you copy into it.

Watch out for bind mounts in development

One of the most common Docker Compose problems is mounting the source directory into the container and accidentally hiding the node_modules installed during the image build.

For example, this can cause trouble:

1services:
2  web:
3    build: .
4    volumes:
5      - .:/app

If the host machine does not have compatible node_modules, or if the mount replaces the directory structure the image created, the container may lose access to its installed packages.

A common mitigation is to preserve container-side node_modules with a separate volume:

1services:
2  web:
3    build: .
4    volumes:
5      - .:/app
6      - /app/node_modules

That keeps the host source mount while preventing node_modules from being overwritten by the bind mount.

npm ci versus npm install

For reproducible container builds, npm ci is generally the better choice when you have a lockfile. It installs exactly what the lockfile specifies and fails if the dependency metadata is inconsistent.

That helps avoid "works on my machine" container behavior where a local dependency tree differs from the image dependency tree.

Common Pitfalls

The biggest mistake is copying the whole source tree before running dependency installation and then blaming Docker when the dependency layer is invalid or inefficient.

Another issue is bind-mounting the project directory in development and unintentionally hiding container-installed node_modules.

Developers also forget that production-oriented installs can omit dev dependencies. If react-scripts is stored where the current install mode skips it, the runtime command will fail.

Finally, check the working directory. If the container runs in the wrong folder, npm start may execute outside the actual project directory and fail to resolve local binaries.

Summary

• The error usually means react-scripts is missing from the container's local dependency path.
• Copy dependency manifests first, then run npm ci, then copy source files.
• Confirm react-scripts is actually listed in the project dependencies.
• Bind mounts can hide node_modules and cause the command to disappear.
• Verify the working directory and install mode match how the container is supposed to run.