Introduction
Hosting Classic ASP (Active Server Pages) has traditionally meant being tethered to Windows Server and IIS. For developers maintaining legacy applications or looking to migrate older VBScript systems to modern, cost-effective infrastructure, finding a native Linux alternative has always been a significant challenge.
Enter AxonASP, an open-source, multi-platform runtime built in GoLang. It is designed specifically to host Classic ASP applications natively on modern systems like Linux and macOS. Instead of relying on heavy virtual machines, emulators, or complex workarounds, AxonASP provides a streamlined environment to run your VBScript files directly.
In this tutorial, we will walk through the process of installing the AxonASP runtime on an Ubuntu or Debian server using the pre-compiled .deb package.
Prerequisites
- A server running an Ubuntu or Debian-based Linux distribution.
- Command-line access with
sudoprivileges. -
wgetorcurlinstalled for downloading the package.
Step 1: Download the Release Package
The easiest way to install AxonASP on Debian-based systems is via the official .deb packages provided in the project's GitHub repository.
Navigate to your terminal and use wget to download the target release. (Note: The URL below uses version 2.1.7 as an example. Always check the repository for the latest version).
wget https://github.com/guimaraeslucas/axonasp/releases/download/v2.1.7/axonasp_2.1.7_amd64.deb
Step 2: Install the .deb Package
Once the download is complete, use the dpkg command to install the package onto your system.
sudo dpkg -i axonasp_2.1.7_amd64.deb
Tip: If you encounter any dependency errors during installation, you can easily resolve them by running sudo apt-get install -f.
Step 3: Understand the Directory Structure
After a successful installation, the runtime is neatly unpacked into the /opt/axonasp/ directory. It is helpful to understand the core components included in this path:
-
/opt/axonasp/- The main installation directory. -
/opt/axonasp/axonasp-http- The standalone HTTP web server binary, perfect for quick deployments, testing, or development. -
/opt/axonasp/axonasp-fastcgi- The FastCGI application server binary, ideal for production environments when integrating with reverse proxies like Nginx or Apache.
Step 4: Install and Enable the Background Service
To ensure that the AxonASP runtime runs continuously and starts up automatically whenever your server reboots, you need to configure it as a systemd service. The installation package includes a handy bash script to automate this exact process.
Navigate to the installation directory and run the service installation script:
cd /opt/axonasp
sudo bash install-service.sh
Next, start the service and enable it so it persists across reboots:
sudo systemctl start axonasp
sudo systemctl enable axonasp
Step 5: Verify the Installation
To confirm everything is running smoothly, check the status of the service using systemctl:
sudo systemctl status axonasp
You should see an output indicating that the service is "active (running)". From here, your Linux server is officially ready to process .asp files and execute VBScript natively!
Conclusion
Running Classic ASP doesn't mean your infrastructure is permanently locked into legacy operating systems. By utilizing a modern runtime like AxonASP, you can breathe new life into older web applications, leveraging the stability, security, and performance of Linux environments.
For more advanced configurations—including setting up Nginx as a reverse proxy, configuring virtual hosts, or exploring the FastCGI implementation—check out the official AxonASP documentation.
Top comments (6)
Pretty clean setup and easy to follow.
The install + systemd flow fits Linux standards well.
Big question is how close VBScript behavior stays to real IIS cases, especially older edge stuff and COM usage.
FastCGI will need load testing to make sure it holds up.
Overall, solid way to keep Classic ASP running without Windows.
Hi Gilder, thanks for the feedback! I'm glad the Linux setup and systemd flow made sense.
Regarding VBScript compatibility, AxonASP aims for maximum parity with IIS. So far, all the legacy code we’ve tested—including a solid list of known VBScript quirks—has run exactly as expected. That said, we know the Classic ASP ecosystem has some wild edge cases out there. When those inevitably pop up, community help through GitHub issue reports is fundamental for us to track them down and continuously improve the engine.
As for COM usage, you hit on the biggest hurdle. Direct COM support doesn't exist out of the box, with the sole exception of our ADODB implementation for MS Access on Windows. To bridge the gap, AxonASP libraries implement aliases for the most popular native implementations.
If a legacy application relies on highly specific or custom COM components, the developer will need to take one of two routes:
Native GoOLE Contract: You can download the AxonASP source code and compile a custom library that interfaces via a GoOLE contract. With the help of AI, writing this contract is actually quite fast, though this approach will strictly limit that specific functionality to Windows environments.
Logic Conversion: The alternative is to completely rewrite or convert the specific COM component's logic into Go, VBScript, or modern JavaScript so it can run natively within the engine across any platform.
And yes, spot on regarding FastCGI load testing—it's something we are keeping a close eye on, and the VM pools have been holding up great under pressure! Thanks again for checking out the project.
Thanks for clarifying.
As a long-time specialized Classic ASP developer, and maintainer of dozens of enterprise systems and ASP apps, this platform is stunning and looks very promising. I know that COM components can't be used under Linux, but what if we install AxonASP under Windows ?
Hi there, and thank you so much for the kind words! Getting that kind of feedback from a specialized developer who actively maintains dozens of enterprise Classic ASP systems means a lot to us.
Regarding COM components on Windows: unfortunately, the core limitation remains mostly the same as on Linux. Even when installing AxonASP under Windows, direct, out-of-the-box support for generic COM objects doesn't exist (with the exception of our ADODB implementation for MS Access).
The technical reality is that implementing full, dynamic COM support in GoLang without explicitly working with each individual object is highly complex due to the limitations of the GoOLE package.
However, you still have two viable paths for Windows environments:
Custom GoOLE Libraries: You can download the AxonASP source code and compile a specific library that creates a contract via GoOLE for the exact COM objects your app needs. With the help of AI, writing these specific contracts is actually quite fast.
Component Conversion: Alternatively, you can rewrite the specific COM component's logic into Go, VBScript, or JavaScript so it runs natively.
The most important takeaway is the massive reduction in effort. While dealing with legacy COM components does require some manual intervention, being able to retain the vast majority of your existing Classic ASP codebase and only rewriting a few specific integrations is still exponentially easier, faster, and more cost-effective than rewriting an entire enterprise system from scratch.
We would love to hear how it goes if you decide to test drive some of your apps on the platform!
Hi Lucas,
As a 44-year-old who has been developing on ASP since I was 16, I'm here to stay with this platform for at least the upcoming next 25 years!
There's so much to maintain, so much to develop for so many clients!
Regarding COM components, I understand the gist of your explanation about using GoOLE. I don't know Go, and the reality is that I cruelly lack the time to delve into implementing certain COM objects. I simply wouldn't know how to. A code example for a simple COM component could one day prove useful in helping other developers in implementing more complex COM objects.
You've already made an incredible effort by implementing many features directly in AxonASP, which eliminate the need for some COM objects (G3JSON, G3CRYPTO, etc.)! For sure this IS a real massive reduction in effort.
Based on my extensive experience with the ASP Classic platform, which I maintain and work on daily, I believe there are only a few components that are truly indispensable:
I've reviewed the documentation and still have some questions about how to connect to MariaDB and SQL Server databases. The example for the Connection.Open() method is relatively short, so I'm still a bit confused about this.
Regarding date and time zone management, I developed a COM component for this: lejusteweb.com/com/ljw-serversuite.... It is based on .NET 4.
I haven't found a library in AxonASP that would provide the equivalent functionality. I'm pretty sure that AI could help me convert this component in Go in a hypothetical G3DATE lib...
Finally, my hosting servers manage dozens of websites. This is the main concern. Since I'm used to the IIS architecture, I haven't quite figured out how to start multiple websites and FTP accesses with AxonASP, which listen on the same ports (80, 443, 21, etc.). IIS allows for clear separation of sites and application pools thanks to Windows Accounts. Managing isolation on AxonASP is one of the most important things for me to understand. Managing TLS/SSL certificates is also a concern. URL Rewriting too.
Lucas, you're doing all this in your free time, and I don't know why you became interested in this platform (and I'm curious about it), but your initiative is TRULY crucial for the future of thousands of businesses of all sizes. I know that even Microsoft still uses ASP Classic for some of its services (#irony) :-o