Hi Robert, welcome to Wappler!
I had a similar setup (Windows 2019 with MSSQL) for one of my NodeJS web app, which I later changed to a Docker with MSSQL setup. When I set it up as Node web app on a Windows Server, I had to install NodeJS on the server locally, with PM2 Node package to keep node server running/connection alive on the Windows server. This setup also required setting up Reverse Proxy on the Windows IIS web server to access NodeJS server port, generally 3000 (Apache and nginx may be better options to set up reverse proxies if you’re familiar with these).
To develop and run a Wappler project with NodeJS server model (on Mac), you will need to install NodeJS locally (unless Wappler itself is being installed with NodeJS, which I don’t think is the case). But you don’t need Docker locally to run your project, as Wappler will run a Node server internally on local port: 3000. As the published project is going to be run on a Windows server, you can run it locally without Docker and via IIS as mentioned above on the server.
To run a NodeJS project without Docker, create the project with this option Project Settings -> Targets -> Server Type: Wappler Local Server. To publish the project on a Windows Server, create another target and select Access Type: FTP under WEB with FTP credentials. This is the target that you will select to upload/publish files/assets etc. on the web server. Multiple targets can be setup for Dev, Staging, Prod etc. and each of these targets can point to different Remote Folders under the FTP connections.
When multiple targets are created, Wappler creates separate sets of database connection details (check here by showing hidden files, then under .wappler → targets → folders with target names) etc. to keep various information points separately. e.g. the database connection details are going to be different for Test & Prod MSSQL databases. So, when you select a specific target, you are also applying the DB connection details for that target. Similarly, when a target is published, it will contain its own set of config details.
My recommendation/approach for this would be to publish the websites by using subdomains for test sites and running IIS reverse proxies for each subdomain to the node assigned port 3000, e.g. test1.yoursite.com or test2.yoursite.com, rather than setting up different ports.
Hope this information will assist you in setting up your projects.
