Server Runtimes

Fast can run your application in three different ways, called runtimes. You rarely choose one explicitly, Fast picks the right one for your platform and worker count, but understanding the three helps you reason about performance, resilience, and what works where.

The three runtimes

Prefork is the default on POSIX systems (Linux, macOS, BSD) and the full production model. A master process binds the listening socket and forks a pool of workers that share it, using pcntl_fork and signals. Subsystems like the database, KV store, and session store run in their own subprocesses that the workers talk to over Unix sockets. This is what you want in production.

Single-process runs the entire server in one process, with no forking at all. It runs the event loop over TCP, so it works literally anywhere PHP's stream_select does, including native Windows. It is great for development and for platforms where fork is not available. The trade-off is no self-recycling and no crash respawn, because there is no master to do it.

Proc pool is for native Windows when you want multiple workers. A master binds the public port and byte-proxies each connection to one of several proc_open-launched worker processes, each on its own loopback port. It gives Windows real multi-core serving with worker recycling and respawn, but it only serves the stateless surface (more on that in Platform Support).

How Fast chooses

You do not select a runtime by name. Instead, Fast infers it from your platform and the workers argument to serve():

  • On POSIX, serve(workers: 1) or more always preforks, with crash respawn and

recycling. serve(workers: 0) explicitly opts into single-process.

  • On native Windows, serve(workers: 0) or serve(workers: 1) runs

single-process, while serve(workers: 2) or more runs the proc pool.

So the same serve() call does the sensible thing on each platform.

serve(port: 8080, workers: 4);   // prefork on Linux/macOS; proc pool on native Windows
serve(port: 8080, workers: 0);   // single-process everywhere

Choosing worker count

More workers means more parallelism, up to a point. A good starting point is roughly one worker per CPU core, then measure. Remember that some resources multiply by worker count:

Your total database connections are about workers × poolSize, so size them together against your database's connection limit. The same goes for file descriptors: prefork and single-process each need roughly maxConnections descriptors per worker, so raise the OS descriptor limit to match your configuration.

Resilience

The reason to prefer prefork (or the proc pool) over single-process in production is resilience. Those runtimes have a master that supervises workers: if one crashes, it is respawned, and workers recycle themselves after a configurable number of requests or a memory ceiling. Single-process has none of that safety net, because it is just one process. Use it for development and constrained platforms, not for a production deployment you need to stay up.

The next page digs into that worker recycling and the lifecycle hooks around it, in Workers & Lifecycle.