How to Run Classic ASP on Linux: A Step-by-Step Guide to Installing AxonASP on Ubuntu & Debian

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 sudo privileges.
• wget or curl installed 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.

Comments

[Gilder Miller]

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.

[Lucas Guimarães]

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.

[Gilder Miller]

Thanks for clarifying.

[Alexandre Féron]

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 ?

[Lucas Guimarães]

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!

[Alexandre Féron]

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:

• Chilkat: This one is widely used. Although AxonASP now integrates cryptographic functions and JSON, the Chilkat component offers a multitude of libraries that are very popular in enterprise ASP applications.
• Persits ASPJPEG + AspHEIF: This library allows to manage recent image formats. This could be an idea point to implement them in G3IMAGE.
• Persits AspPDF: This one is essential for most ASP projects that have survived over time until now. Companies with an ASP Classic platform use it to generate numerous documents. The most frequently used function is .ImportFromURL(), which converts an HTML file to PDF. I looked for an equivalent in AxonASP, but I lacked details on the .WriteHTML() method. Is it equivalent, or is it something else entirely?

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

[Lucas Guimarães]

Hi there! Thank you so much for the incredible feedback and your support for the project.

I apologize for the delay in responding! I'm 38 years old and work as a medical radiologist, so AxonASP is essentially a side project for me, and I have to balance my time between the two. I created this server because I simply loved "playing" with ASP. I have great memories of using Personal Web Server (PWS) on my old Windows 98 computer. Also, when I was younger, I used to go to my bank and see their entire system running on ASP, which I found absolutely fascinating. By the way, I saw that petition asking Microsoft not to kill ASP; I actually signed it in the past, but unfortunately, I don't know anyone at MS who could help push it forward!

Regarding COM components and Go, even though Go might seem difficult at first glance, it is actually as easy as Visual Basic. Based on your suggestions, I've added a manual page explaining how to create a library that interacts directly with COM objects: g3pix.com.br/axonasp/manual/?page=.... However, ideally, you should implement the object as a native GoLang library. By utilizing AI, converting legacy COM code into high-performance, cross-platform GoLang code is fast and straightforward. This modern approach is safer, much more performant, and cross-platform.

I also took the time to improve the documentation for both G3DB and ADODB to better show how database connections (like MySQL and others) can be implemented in your code. You can check the updated examples here:

• g3pix.com.br/axonasp/manual/?page=...
• g3pix.com.br/axonasp/manual/?page=...

Now, regarding your biggest concern about hosting architecture: AxonASP is not a direct replacement for IIS; it is a Classic ASP runtime. It operates on a modern, application-centric architecture—structurally identical to how modern .NET Core, Node.js, or Docker applications are deployed. This means all your existing IIS configurations remain entirely valid. To properly orchestrate AxonASP within IIS, you must use the HttpPlatformHandler v1.2+ module. You can read more about the setup here:

• g3pix.com.br/axonasp/manual/?page=...
• g3pix.com.br/axonasp/manual/?page=...

For example, in the axonasp.toml file, you can set the root directory to match your default IIS site directory. This allows you to serve your static files through IIS natively while AxonASP handles the application logic. The whole idea is to universalize and implement modern administration practices for ASP so it can run on any platform or server. This way, if one website runs out of control, it won't crash the other applications or the main server, because every application runs its own distinct instance of axonasp-http.exe. This setup also allows you to run ASP inside Docker containers, significantly reducing the costs associated with Windows servers. It might seem a bit complicated at first, but it is definitely worth migrating to this approach—it is more secure, highly distributable, cheaper, and ultimately easier to manage.

I will definitely take a look at the libraries you suggested. Keep in mind that we already have internal libraries that do a lot of these things, so sometimes it's just a matter of creating aliases. For instance, regarding PDF creation, our G3PDF library already supports generating PDFs directly from HTML via .WriteHTML(). You just need to pass the HTML content, and it generates the file! Check out the ./www/tests/ directory in our GitHub repository to see exactly how to implement the HTML part.

As for the ljw-serversuite, since you already have updated and tested .NET code, converting it to GoLang using AI is incredibly easy. Once converted, integrating it directly into the server would be a breeze just by porting the logic.

Oh, one last detail! For servers like Nginx, Apache, or Caddy that natively support FastCGI, you can actually run ASP pages exactly like you run PHP scripts. This allows you to run "shared" environments simply and without needing to start a unique, dedicated instance of AxonASP for every site (though keep in mind that Global.asa support is compromised in this specific model).

Thanks again for the support!