Invoice Ninja IIS setup


I just wanted to know whether invoice ninja can be setup on IIS? I was able to setup PHP on IIS and created a website for invoice ninja and hosted the PHP code there , but when i try to access the PUBLIC folder , i get the 404 NOT FOUND error. Surprisingly , when i access the server.php file, the invoice ninja setup opens but no CSS assets are accessed and their are alot of errors.

Has anyone been able to successfully setup Invoice Ninja on Windows IIS?


Sharing my experience… I’ve been evaluating the self hosted version and I did considered hosting it on IIS, but concluded there would be too many unknowns to bother with when it comes to resolving issues as from its requirement list it is clear that it was not developed specifically for IIS. I’m not exactly a linux box guru so i settled for a middle ground with XAMPP. With one install you get Apache, php and MariaDB so you only need to copy the self hosted ninja folder version to C:\xampp\htdocs
and you’ll be all set to start the configuration. If you decide to try out this route, the make sure the XAMPP install file is the one for PHP version 7.2… no mater how tempting it is to go with the latest version. :slight_smile:

Hope this helps.

Here are some IIS related comments I found on our repo:

Hi Cadmium ,

Thank you for your quick reply, i think cadmium is right saying that there would be a lot of unknowns if i go ahead with IIS setup as Invoice Ninja wasn`t build for that purpose as the Dev Guide suggests , so i shall try the XAMPP approach and see if it works out for me.


I tried both of these but still can`t get it to work :frowning:

Thank you

Wait a sec, i just noticed that i have PHP 7.3 running. Would that cause an issue as i see that the app supports till PHP 7.2

As I recall, interface wise I didn’t perceive any errors, but it did interfere with some part of the recurring billing and notification process. Unfortunately, I don’t recall the exact error nor if came up during the configuration or later, but I do remember it was along the lines of a change in a php method signature or a deprecated method. I didn’t check to see if it affected anything else. Overall IN has exceeded my expectations.

There aren’t any user-land errors when using 7.3, but things do go a bit pear-shaped on the back end.

However, you don’t have to completely remove it. Just install PHP 7.2 and make that the system-default version for now. Then when IN supports 7.3 (should be the next release, IIRC) you can just switch it back over.