AxonASP brings Classic ASP to Linux with Apache FastCGI, no Windows Server needed

Classic ASP without the Windows server

Teams that still maintain Classic ASP applications usually need a separate Windows and IIS environment even when everything else they operate runs on Linux. According to a post on dev.to by Lucas Guimarães, the tool's creator, AxonASP removes that requirement: it is an open-source, cross-platform server that executes Classic ASP code natively on Linux. Guimarães, based in Brazil, built the project with more than ten active contributors, and the post walks through deploying it behind Apache.

A FastCGI process manager for ASP

The heart of the setup is AxonASP FPM, a FastCGI process manager whose name and design echo PHP's PHP-FPM. A manager process runs as root and spawns worker processes for each application; the permissions of each worker come from a per-application pool configuration file.

A pool file defines the site name, the Linux UID and GID the workers run under, the Unix socket the pool exposes, the application path, a memory ceiling (the post's example uses 256 MB), a maximum restart count, and a temporary directory. The post stresses that the UID and GID should match the account owning the application directory; this per-pool privilege separation is what makes the approach viable on shared machines.

Installation on Debian or Ubuntu uses a package, version 2.3.18 at the time of the post, which installs the binaries, the FPM manager and default configuration under /opt/axonasp. The service is then enabled and started through systemctl.

Connecting Apache

On the web server side, Apache's proxy and proxy_fcgi modules must be enabled. A ProxyPassMatch directive in the virtual host sends requests ending in .asp to the Unix socket created by the application's FPM pool, and Apache passes along the usual FastCGI environment variables, such as DOCUMENT_ROOT and SCRIPT_NAME, so path resolution inside the application behaves as expected. After an Apache restart, .asp files are served from the Linux host.

What the project claims

The post lists three operational benefits of routing ASP execution through FastCGI:

• Consolidation: a legacy ASP application can share a Linux host with modern services written in Go or PHP, under an Apache setup that already exists.
• Tenant isolation: each pool drops privileges to its own UID and GID, so one application cannot reach another's files or memory.
• Crash and memory handling: FPM enforces per-pool memory limits through cgroups and automatically restarts workers that fail.

Shared hosting platforms such as cPanel are named as a target scenario, since pools give each tenant an isolated slice of the machine.

Why it matters

Classic ASP was introduced in the 1990s and later superseded by ASP.NET, yet many business systems built on it are still in service. The teams responsible generally face two unappealing options: keep running a separate Windows Server purely to host one ageing application, or rewrite code that still works. AxonASP proposes a third route — move the application onto the Linux fleet, isolate it in its own process pool, and manage it like any other service on the host.

One caveat is worth stating plainly: these claims come from the project's own announcement, written by its creator. The post does not spell out how complete its VBScript coverage is, or how it handles Windows-specific dependencies that mature Classic ASP applications often rely on, so anyone with a complex codebase should test thoroughly before retiring their IIS servers. For simpler sites, though, the prospect of deleting a Windows VM from the infrastructure inventory is a real attraction.