Tatsuhiko Miyagawa's Blog

Which should I use: Starman or Starlet?

May 14, 2015

A discussion came up on #plack IRC channel earlier, and we realize that there’s no good (official) documentation available to address the differences between the two popular Plack HTTP servers, Starman and Starlet.

Besides the similarity in their names, they are actually similar in what they do: they do serve HTTP requests, and the process model is pre-forked (i.e. fork off a number of HTTP worker processes to serve requests).

Starman and Starlet are both great at serving HTTP requests behind the frontend proxy (i.e. nginx, Apache mod_proxy).

Then what’s the difference?


Starman is written by me (miyagawa) and is based on a separate module Net::Server. The original code base is stolen from Catalyst’s standalone HTTP server and modified to adapt to the PSGI server specification.

Because it’s based on Net::Server, it has all sorts of customizable options, such as log rotations, managing processes via signals, UNIX sockets, binding to multiple hosts, etc.

The recent release also includes passing options directly to Net::Server, which will unleash the whole flexibility of the backend, as well.


Starlet is written by Kazuho Oku — he is known as an author of many software, including H2O and the C-based HTTP parser implementation for Plack.

Unlike Starman, Starlet implements its own process management and TCP socket handling, using separate set of modules also written and maintained by the author himself. At the time of writing Starman, I considered them being experimental, but given the record of his software, and the fact that many Plack based HTTP servers rely on its ecosystem, I’d say Starlet is pretty mature.

A blog post by kazeburo, another active contributor to Plack and Stralet, shows that Starlet scales better than Starman when you increase the number of worker processes to handle massive amount of HTTP requests. Starman doesn’t seem to scale as well as Starlet, after having 8 processes of workers with his specific benchmark. Note that the benchmark was against a simple Hello World application, and real web applications won’t likely be suffered from this.

On the other hand, Starlet doesn’t support listening on UNIX sockets, nor binding to multiple hosts/ports by itself — these features, along with zero downtime restarts, are available if you put it behind Server::Starter.


Starman is a fully featured standalone HTTP server, that supports many features provided by Net::Server family itself.

Starlet is much simpler, and uses slightly less memory, albeit not supporting all the features you may or may not need.

If you want to control the number of processes dynamically, or want to use UNIX sockets, or want to use the feature XYZ of Net::Server, use Starman.

If you want to deploy on a resource restricted environment, or serve millions of requests per second and any slight performance and resource improvements count, use Starlet.

Using either of those, you’re recommended to put it behind a frontend proxy such as nginx. For zero-downtime deployments using TCP sockets, combine it with Server::Starter or SO_REUSE_PORT.