Platform Support

Fast runs on Linux, macOS, BSD, and Windows, but not every feature is available on every platform, because some subsystems depend on fork. This page lays out exactly what works where so there are no surprises when you deploy.

The support matrix

On POSIX systems, everything works. WSL2 on Windows behaves like Linux, so it also gets the full stack. The nuance is entirely on native Windows.

Native Windows in detail

Native Windows has no fork, so Fast adapts. Which runtime you get depends on your worker count, and each covers a different slice of features.

Single-process (workers: 0 or 1) covers the non-subprocess surface plus in-process backends. That is a lot: routing, middleware, views, static files, live fragments and components, cookie sessions, CSRF, auth, validation, the KV store (and cache and rate limiting on top of it), Live Streams SSE push, and the database via a synchronous in-process PDO. For development and many small deployments on Windows, single-process is genuinely capable.

Proc pool (workers: 2 or more) gives real multi-core serving on native Windows. It serves the same surface as single-process plus the database (each worker opens its own PDO), but minus the in-process-only shared subsystems: the KV store, Live Streams, and the server-side store session driver. Those are refused with clear guidance rather than silently misbehaving.

The one feature that always needs fork is the server-side (store) session driver. On native Windows, use cookie sessions instead, or run under WSL2. Cookie sessions are stateless and work everywhere.

What runs anywhere

Not everything is the server. A large part of Fast is plain PHP that runs on any platform with no runtime concerns at all: the migrate.php migration runner, the query builder, migrations, validation, the encrypter, routing, and views. You can use these in scripts and tools without ever starting a server.

Choosing a Windows path

If you are on Windows and want the complete feature set, WSL2 is the smoothest answer: it is a real Linux environment, so you get prefork and every subsystem. If you must run native Windows, pick based on your needs: single-process if you want the shared in-process subsystems (KV, streams, store sessions) on one core, or the proc pool if you want multi-core serving and can live on the stateless surface plus the database.

Sizing descriptors

One operational note that applies everywhere: size your OS file-descriptor limit to the runtime. Prefork and single-process each need roughly maxConnections descriptors per worker. The proc master needs more, around workers × maxConnections × 2 plus listeners, control links, and subsystem descriptors. If you see connection failures under load, the descriptor limit is the first thing to check.

The final runtime topic pulls the security and deployment guidance together in Security & Deployment.