experimental deploy detects Next.js app as static Nginx website

Description

mw experimental deploy detects a Next.js application as a static website and generates an Nginx-based image instead of a Node/Next.js application image.

Environment

• @mittwald/cli: 1.24.1
• OS: macOS (darwin-x64)
• Node.js: 20.19.3
• Next.js: 16.3.5
• React: 19.2.8
• Package manager: npm with package-lock.json

The deployed directory contains package.json, package-lock.json, next.config.ts, and src/ at its root. There is no user-provided Dockerfile.

Relevant scripts:

{
  "scripts": {
    "build": "next build --webpack",
    "start": "node scripts/start-staging.mjs"
  },
  "dependencies": {
    "next": "16.3.5",
    "react": "19.2.8",
    "react-dom": "19.2.8"
  }
}

Steps to reproduce

1. Change into the Next.js application directory.
2. Run a deployment similar to:

mw experimental deploy \
  --wait \
  --wait-timeout 10m \
  --project-id <project-id> \
  --env-file <env-file> \
  --uri-prefix <prefix> \
  --service-name <service-name> \
  --image-name <image-name> \
  --image-tag staging

3. Observe the generated Dockerfile during the "Checking repository" step.

I reproduced this twice:

1. Directly from the application directory.
2. From a clean git archive export of the same directory, without node_modules, .next, or other local build artifacts.

Actual behavior

In both cases, the CLI generated this Dockerfile:

FROM nginx:alpine
COPY . /usr/share/nginx/html/

It then built an Nginx image, so the server-side Next.js application could not run.

Expected behavior

The presence of the Next.js package.json and lockfile should cause the deployment to be detected and built as a Node/Next.js application, or the CLI should report why Node detection did not apply.

Questions

• Why is the existing package.json not detected as a Node/Next.js project?
• Is CLI 1.24.1 the current supported path for Railpack/Zero Deploy?
• Can the intended provider/framework be selected explicitly?
• If this application shape is unsupported, is deploy-container-action the recommended alternative?

I can provide additional non-sensitive build output or a minimal reproduction if helpful.

Start at the experimental deploy command and reproduce the issue with the reported Next.js project shape, observing the Dockerfile produced during repository checking. Trace the project-detection path to determine why the package manifest and lockfile are classified as static content; done means the intended Node/Next.js path is selected or a clear unsupported-project diagnostic is emitted.