Why OPSQAI ships as native Windows services — not Docker

Early builds of OPSQAI shipped as a Docker Compose stack. It worked on Linux, it worked in WSL, and it worked for us — but it did not work for the customers we actually sell to. Logistics operations, freight forwarders and 3PLs run dedicated Windows Servers, not container hosts. Requiring Docker Desktop, WSL2 or a separate Linux VM was a hard sell for their IT teams.

We rewrote the deployment stack. OPSQAI now installs from a single Authenticode-signed OPSQAI-Setup.exe and runs as five native Windows services managed by WinSW: OpsqaiCaddy, OpsqaiPlatform, OpsqaiWorker, OpsqaiDatabase (Portable PostgreSQL 16), and OpsqaiUpdater. No Docker. No Hyper-V. No WSL. No IIS. No .NET.

What the customer sees

• Right-click the installer, verify the Authenticode signature, install.
• Program files land under C:\Program Files\OPSQAI\, mutable state under C:\ProgramData\OPSQAI\.
• Services are set to Automatic (Delayed Start) and boot on reboot.
• Caddy terminates TLS on 443, obtaining an internal certificate from the customer's own CA or a Let's Encrypt certificate when the server is reachable.

What we kept

The application, worker, and database are the same code. Only the runtime substrate changed. That means the RAG pipeline, the AI adapter contract, and the licence / heartbeat design carry over unchanged from the container era.