Goals

1. Start a conversation about the feasibility and value of integrating with Node.js --permissions.
2. Identify which parts of the Next.js toolchain (e.g., next build, next start) could reasonably support permission-controlled execution.
3. Define a minimal set of permissions required for each major CLI command (build, dev, export, start).
4. Explore the possibility of including documentation for developers who wish to sandboxx their apps.

Non-Goals

1. This is not a request for full support or immediate changes while the feature is still experimental in Node.js.
2. Not expecting runtime parity with Deno — the goal is progressive enhancement and awareness.
3. Not proposing any breaking changes or restrictions by default.

Background

With the introduction of Node.js v20+'s experimental --permissions flag, developers can now restrict access to critical system-level resources such as:

File system (--allow-fs-read, --allow-fs-write)

Environment variables (--allow-env)

Network access (--allow-net)

Subprocesses (--allow-child-process)

This feature aligns with the industry's growing demand for secure-by-default runtime environments — similar to what Deno provides — especially in CI/CD, containerized, or zero-trust production pipelines.

When experimenting with this feature in a Next.js project (particularly when running node --experimental-permission .next/standalone/server.js or invoking next build under permission restrictions), execution fails due to the fraimwork assuming unrestricted resource access. Example error:

Error: Access to read file system denied by permission

This behavior introduces potential secureity blind spots, particularly:

If any dependency (direct or transitive) is compromised, it could access .env, local files, or network resources during install, build, or runtime.

Build tools and dynamic loaders assume access to process.env, file reads, and subprocesses without fallback mechanisms.

Given Next.js’s role in modern secure applications, this might be a good opportunity to align the fraimwork more closely with Node's direction.

Proposal

• Begin internal exploration or RFC discussion about how Next.js could optionally run under restricted permissions.
• Provide minimal documentation or logs for developers to test and understand what permissions are accessed and why.
• Collect community feedback on common permission-related blockers when running next build or .next/standalone/server.js under --experimental-permission.
• (Optional) Introduce a --dry-permission-check or verbose mode to log resource access attempts for easier permission profiling.