Container app with isolated node_modules

• container-backed Node workflow
• source tree stays bind-mounted
• node_modules is isolated from the host tree
• native binaries like workerd and esbuild stay platform-correct inside the container

• it turns a repo pattern into something humans, CI, and agents can read the same way
• it makes the next command obvious instead of implied by README drift
• it keeps readiness, setup, and execution explainable in receipts and diagnostics

Use this when a Node app runs in a container context but the host checkout already has dependency artifacts that should not leak into the container runtime.

This example uses the shipped execution-topology contract surface to keep the source tree shared while isolating node_modules in Ota-managed storage.

version: 1project:  name: node-isolated-devexecution:  default_context: app  contexts:    host:      backend: native      requirements:        tools:          docker: "*"    app:      backend: container      lifecycle: persistent      container:        image: node:24-bookworm      attachments:        isolated_paths:          - node_modules      requirements:        runtimes:          node: ">=24.14.1"        tools:          pnpm: "*"tasks:  setup:    internal: true    context: app    run: pnpm install  dev:    context: app    runtime:      kind: service      listeners:        http:          protocol: http          bind:            address: 0.0.0.0            port:              mode: fixed              value: 3000          project:            host:              address: 127.0.0.1              port:                mode: auto              path: /    run: pnpm dev

Why this matters: the app can run against container-correct dependencies without asking every developer to delete host node_modules first.

What it fixes: native binaries stop crossing the host/container boundary, so tools like workerd and esbuild resolve against the platform they are actually running on.