Problem

Running PHPStan in parallel inside Docker on macOS (Docker for Mac, Orbstack, etc.) on large codebase suffers from two I/O bottlenecks caused by bind-mounted volumes:

1. Parallel worker contention — Multiple PHPStan worker processes simultaneously read the same ~25 MB phar archive through the slow macOS ↔ Linux virtualization layer.
2. Cache I/O overhead — PHPStan's result cache lives on the same slow bind mount. The cache is read at the start of every run and incrementally updated for changed files, so both reads and writes are affected by the slow virtualization layer.

Solution

All PHPStan file I/O is moved from the bind mount to RAM through a three-layer caching strategy:

Layer 1: RAM-Backed Filesystem

A Docker tmpfs volume (512 MB) shadows the bind-mounted PHPStan directory. On container start, the entrypoint script performs a one-time copy from the host bind mount into RAM. From that point on, all file access — phar reads, cache reads, cache writes — hits RAM instead of the virtualization layer.

PHPStan's tmpDir is explicitly configured to reside within this tmpfs, ensuring the result cache benefits from the same optimization.

Layer 2: PHP Process Memory

The phar archive is pre-loaded into PHP's process memory at startup via phar.cache_list. When PHPStan spawns parallel workers, each worker already has the deserialized phar in memory — no filesystem access needed at all.

Layer 3: Safety Net

A Makefile dependency target verifies the tmpfs is populated before every PHPStan invocation, handling edge cases where the entrypoint didn't run.

Data Flow

Host bind mount (slow)
→ one-time copy on container start →
→ tmpfs RAM volume (fast)
→ phar.cache_list on PHP startup →
→ PHP process memory (fastest)

Each layer eliminates a class of I/O: