Box resource limits: next build EAGAIN — can't spawn workers in 2GB RAM

[shtefcs]

Problem

Running `next build` inside an Upstash Box fails with `EAGAIN` (resource temporarily unavailable) during static page generation. The build tries to spawn Node.js worker processes but the 2GB RAM limit prevents process creation.

Error

```
Warning: Failed to load system CA certificates off thread: resource temporarily unavailable
uncaughtException [Error: spawn /usr/local/bin/node EAGAIN] {
errno: -11,
code: 'EAGAIN',
syscall: 'spawn /usr/local/bin/node'
}
```

This happens during `Generating static pages` — Next.js spawns worker processes (1 per CPU core) and the box runs out of memory/process slots.

Environment

• `@upstash/box`: 0.1.28
• Runtime: node
• Next.js: 15.1.7
• Build tool: @opennextjs/cloudflare (which calls `next build` internally)

Workaround

Setting `NODE_OPTIONS="--max-old-space-size=1536"` before the build limits each Node.js process's heap and prevents the EAGAIN crash. But this is fragile — larger projects may still exceed 2GB total.

Request

1. Documentation: What are the exact resource limits per box? (RAM, max processes, CPU cores, file descriptors)
2. Larger box tiers: Is there a plan for 4GB or 8GB boxes? Build tools like Next.js, Vite, and Webpack are memory-intensive — 2GB is tight for production builds.
3. Process limits: The EAGAIN error might also be caused by a process count limit (`ulimit -u`). What's the configured limit?

Steps to Reproduce

1. Create a box with `runtime: "node"`
2. Scaffold a Next.js project with 5+ pages
3. Run `next build` (or `npx opennextjs-cloudflare build`)
4. Build crashes during "Generating static pages" with EAGAIN

[shtefcs]

Update: Correct Workaround

The NODE_OPTIONS workaround listed above does NOT fix the issue. The EAGAIN error is a kernel-level fork() failure — not a V8 heap issue. Even with --max-old-space-size=512 and NEXT_PRIVATE_CPUS=1, the spawn still fails because the kernel can't allocate process structures within the 2GB cgroup after webpack compilation consumed most of the memory.

Working fix

Disable worker processes entirely in next.config.ts:

const nextConfig = {
  experimental: {
    workerThreads: false,
    cpus: 1,
  },
};

This makes Next.js generate static pages in the main process — no fork() needed. The build output is identical, just ~2-3 seconds slower for the static page step.

Root cause analysis

The build chain opennextjs → npm → next build already consumes ~1.5GB after webpack compilation. When Next.js tries to fork() a worker for static page generation, the Linux kernel needs to allocate process structures (page tables, etc.) which pushes past the 2GB cgroup limit → EAGAIN.

This is NOT a V8 heap issue (NODE_OPTIONS can't fix it) — it's the kernel failing to create a new process within the container's memory limit.

Still open questions

1. What are the exact cgroup limits? We found: memory.max: 2147483648 (2GB), pids.max: 512
2. Are larger box tiers planned? Modern build tools (Next.js, Vite, Webpack) routinely need 2-4GB during builds.