Modern alternatives to CGI: FastCGI, WSGI, PSGI, and serverless

FastCGI: persistent processes for CGI scripts

FastCGI keeps the interpreter process alive between requests. Instead of forking a new Perl or Python process for every HTTP request, the web server sends each request to a long-running FastCGI process through a socket. The process handles the request and remains available for the next one. This eliminates the interpreter startup overhead that is CGI's biggest performance cost.

Migrating a CGI script to FastCGI typically requires adding a FastCGI loop around the request-handling code (using FCGI.pm in Perl or flup in Python), changing the web server configuration to use fastcgi_pass (Nginx) or a FastCGI handler (Apache), and ensuring any per-request state is reset between iterations of the loop. Global state that was safe in CGI (where it disappeared with the process after each request) must be explicitly managed in a persistent FastCGI process.

WSGI and PSGI: framework standards for Python and Perl

WSGI (PEP 3333) defines a standard callable interface between Python web frameworks and web servers. A WSGI application is a Python callable that takes environ (like CGI environment variables) and start_response (a function to send the status and headers), and returns the response body as an iterable. Any WSGI-compatible server (Gunicorn, uWSGI, mod_wsgi) can run any WSGI application (Flask, Django, Bottle, Pyramid) without the application knowing which server it is running on.

PSGI is the Perl equivalent: a Plack application is a code reference that takes a $env hash and returns an array reference of status, headers, and body. The Plack server (Starman, Twiggy, or Apache's mod_psgi) handles the HTTP layer. Dancer2, Mojolicious, and Catalyst all run as PSGI/Plack applications. Migrating a CGI script to a Dancer2 route is straightforward and gives you a persistent process, a routing layer, and the full Perl ecosystem without the CGI restart overhead.

When CGI is still the right choice

CGI remains the right choice when the deployment environment only supports CGI (many traditional shared hosts), when the script is called infrequently enough that startup overhead is not a problem, when simplicity and lack of dependencies matter more than performance, or when you are maintaining an existing CGI codebase where a full migration is not justified. A contact form that handles a few dozen submissions per day has no meaningful performance problem with CGI startup overhead.

The reason to move away from CGI is sustained traffic where startup overhead adds latency, and the reason to stay with CGI is simplicity and compatibility. Both are legitimate engineering decisions. If your shared host supports only CGI and your traffic is low, CGI is entirely adequate. If you are on a VPS and need to handle hundreds of requests per second, FastCGI or a WSGI/PSGI framework is the appropriate next step.