Lest you think that my previous reply was “dismissive,” perhaps the following stage-setter might be useful...

Any Plack application can be thought of as encompassing four levels, which would be (from innermost to outermost) as follows:

1. The legacy application:   It has never heard of Plack.   It can’t even spell the name.   It was written for mod_perl or for CGI, and anytime you talk to it about “the future,” all you ever hear in response begins with... “harumph, these kids today.   Why, back in my day...”   You really don’t want to piss-off such a massive and mission-critical geriatric monolith ... especially since it is the Old Phart that makes all the money for the whole damm company.   Smile when he starts talking about how great punched paper tape was, and pretend you have never heard that story before.   Honest, you just want to fool it into thinking that “the present” is “the past.”   :-}   Perhaps just wedge a small alternate entry-point into it for Stage 2 to use, then tiptoe quietly away.
2. The wrapper:   A new program, usually named app.psgi (since this is what plackup automatically looks for...) which is actually the routine that gets invoked when a new request comes in.   This module expects to be invoked by a “Plack Handler” (see #3 below) by means of a subroutine call.   Usually, Plack::Builder is used here.   Even though the old crotchety application thinks it’s still talking to the legacy environment that it’s used to, it’s actually talking to this wrapper and no one else.
3. The handler:   When the application is invoked by a “real” web-server (as opposed to plackup), this defines the actual application that gets control.   (If you are using plackup, this layer is never used, because in that case plackup is “the handler.”)   One of the Plack::Handler modules are used here, depending on exactly what server is being used and exactly how the server is invoking the program.   The whole idea of Plack is that, if this arrangement should ever change, this is the one and only module that must be different:   you merely have to substitute a different ::handler.
4. Server modules (maybe):   Modular servers, such as Apache, might require extension modules such as mod_fastcgi or mod_fcgid to transfer control to the handler in the appropriate way.   Once again, the whole idea of Plack is that you have a genuine choice here.   You can invoke a Plack program by means of, say, mod_perl or even “good ol’ CGI” as long as you use a corresponding “handler” in Stage 3.

No matter what necessary combination of software you choose in Stages 3 and 4 (and no matter how often in the future you may change it), the software in Stages 2 and 1 is unchanged.   Even if you decide to substitute a completely different server (nginix, anyone?), once again, Stages 2 and 1 are unchanged.   (And that’s huge...)

The plackup command-line utility is perhaps the best demonstration of Plack’s power.   plackup provides a command-line based “handler” environment (Stage 3, thus Stage 4 is N/A...) that is indistinguishable from what any web-server would provide.   Therefore, your Plack-compatible application runs exactly as it ordinarily would, since it is (not quite...) incapable of detecting the difference, and certainly does not care about it.