Prisma cannot run in webapp Docker runner stage

[seansica]

prisma db push is executed by init.sh in the webapp runner stage (at container runtime) but it will fail (without crashing)

This is because node_modules is not available in the runner stage, since we are copying from the builder stage which generates a production build via npm ci.

Instead, we should run prisma db push in the db-init stage. That stage already has node_modules available, and it keeps database operations in the db-init stage where Prisma CLI is available. It also keeps the production container minimal and focused, and voids the Next.js routing issues.

Additionally, we should reference all binaries through node_modules (not npx). Tool calling through npx may result in version mismatches.

[seansica]

@hijohnnylin Just so you know, the make webapp-localhost-dev workflow does not work. It hasn't worked since we refactored the webapp's Dockerfile a while back.

The workflow tries to use the production runner Docker stage (which has no node_modules) while mounting local dev files into the container for hot-reloading and running npm run dev (which includes prisma generate && next dev).

This fails because the runner stage is minimal and only contains the Next.js standalone build. When you mount local files, you're overriding the container's filesystem, but npm run dev needs the Prisma CLI to run prisma generate - which the production container doesn't have since it lacks node_modules.

The volume mounts in compose.webapp.dev.yaml attempt to work around this by mounting local node_modules, but the paths don't align correctly with where the container expects them (/app vs /app/apps/webapp).

The Docker dev workflow is essentially trying to hybrid local development files with a production container, creating path mismatches and missing dependencies.

I'm proposing we abandon this approach and delete the corresponding Makefile recipe and compose.webapp.dev.yaml file in favor of just running npm run dev:localhost locally - much cleaner and simpler. The production workflow (make webapp-localhost-run) works fine because it uses the purpose-built production container that just serves the app.

If you're onboard, I can remove compose.webapp.dev.yaml and the webapp-localhost-dev makefile recipe in this PR. Just let me know.

[hijohnnylin]

Interesting, thanks! We should unbreak this immediately, even if it’s not the “cleanest” solution. If we remove the local docker webapp, does this basically remove our ability to bring up the whole environment (including postgres, etc) with docker locally?

…

On Fri, Sep 26, 2025 at 9:56 AM Sean Sica ***@***.***> wrote: *seansica* left a comment (hijohnnylin/neuronpedia#173) <#173 (comment)> @hijohnnylin <https://github.com/hijohnnylin> Just so you know, the make webapp-localhost-dev workflow does not work. It hasn't worked since we refactored the webapp's Dockerfile a while back. The workflow tries to use the production runner Docker stage (which has no node_modules) while mounting local dev files into the container for hot-reloading and running npm run dev (which includes prisma generate && next dev). This fails because the runner stage is minimal and only contains the Next.js standalone build. When you mount local files, you're overriding the container's filesystem, but npm run dev needs the Prisma CLI to run prisma generate - which the production container doesn't have since it lacks node_modules. The volume mounts in compose.webapp.dev.yaml attempt to work around this by mounting local node_modules, but the paths don't align correctly with where the container expects them (/app vs /app/apps/webapp). The Docker dev workflow is essentially trying to hybrid local development files with a production container, creating path mismatches and missing dependencies. I'm proposing we abandon this approach and delete the corresponding Makefile recipe and compose.webapp.dev.yaml file in favor of just running npm run dev:localhost locally - much cleaner and simpler. The production workflow (make webapp-localhost-run) works fine because it uses the purpose-built production container that just serves the app. If you're onboard, I can remove compose.webapp.dev.yaml and the webapp-localhost-dev makefile recipe in this PR. Just let me know. — Reply to this email directly, view it on GitHub <#173 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH6NERAIXGRBW3V3A4R2K33UVV3PAVCNFSM6AAAAACHTMWFSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMZZGYZDIMRQGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[seansica]

If we remove the local docker webapp, does this basically remove our ability to bring up the whole environment (including postgres, etc) with docker locally?

Not quite. To clarify, I'm only talking about the dev workflow for the Docker webapp. The prod workflow is unaffected.

• make webapp-localhost-run: works!
• make webapp-localhost-dev: not working

As I understand it, the dev workflow only differentiates itself from the prod workflow by adding the following properties to the webapp service:

    environment:
      - NODE_ENV=development
      - WATCHPACK_POLLING=true
    volumes:
      - ../apps/webapp:/app/apps/webapp
      - ../apps/webapp/node_modules:/app/apps/webapp/node_modules
    command: >
      sh -c "npx prisma migrate dev && npm run dev"

Otherwise it is the exact same workflow as prod.

These properties are entirely optional. It looks like the intention behind this workflow was to enable hot-reloading inside the webapp container for changes made to the app locally. It's a nice-to-have, not a need-to-have. It would be much cleaner (and easier) to just relegate support for hot-reloading to local development; developers can rebuild the prod image when they are ready for docker testing & deployment.

In any case, I think I found a solution:

We should be able to remove the prisma migrate and prisma generate steps from the dev workflow, since those steps are handled by the db-init container (or at least they will be if this PR is accepted):

• In apps/webapp/package.json:
  

• In docker/compose.webapp.dev.yaml:
  

Finally, in Makefile we would have:

• webapp-localhost-prod-build --> builds the full image (which ends with the runner stage)
• webapp-localhost-prod-run --> runs the webapp in the runner stage
• webapp-localhost-dev-build --> builds up to (and including) the builder stage
• webapp-localhost-dev-run --> runs the webapp in the builder stage

To clarify what's going on here, the Dockerfile is configured as a multi-stage Docker build:

Stages:

• base
• deps
• builder <-- contains the non production-optimized webapp
• db-init
• runner <-- contains the production-optimized webapp

That's the only solution I can think of that doesn't involve reverting the webapp to its original chonk (which really would not be worthwhile, given that the dev workflow is not outright required, and because hot-reloading can be done locally)

I just tested this workflow and it appears to be working—the webapp is starting with hot-reloading enabled:

[seansica]

The latest commit should resolve the issue. It does so exactly as described in the previous comment—by breaking the webapp-localhost- make recipe into 2 dimensions:

1. build and run
2. dev and prod

Thus, there will be four distinct recipes:

• webapp-localhost-prod-build --> builds the full image (which ends with the runner stage)
• webapp-localhost-prod-run --> runs the webapp in the runner stage
• webapp-localhost-dev-build --> builds up to (and including) the builder stage
• webapp-localhost-dev-run --> runs the webapp in the builder stage

In addition, all prisma related steps (generating, pushing, etc.) are now isolated to the db-init stage/container!