Deploying VigilSOC on Windows 11: Architecture, Pitfalls, and Hardening

VigilSOC 1.0.0, a cloud-native, Linux-first autonomous security operations center, was test-deployed on a dedicated Windows 11 virtual machine, with internal containers bound strictly to 127.0.0.1 behind native Windows Nginx and more than 2 GB of consumer bloatware stripped from the OS. The deployment ran the stack — PostgreSQL, Redis, the Bifrost LLM gateway, FastAPI backend services, autonomous agent worker runtimes, and a Vite-based console — inside WSL 2 on Ubuntu 22.04 LTS with systemd enabled, requiring nested virtualization when the Windows 11 host itself ran under Proxmox VE or QEMU/KVM. The write-up documents the architecture and pitfalls for teams whose corporate device policies block local configuration changes, forcing a remote virtual machine.

This is the lesson from the realm of running a workshop and not expecting participants to show up with Windows laptops. We cover a few lessons learned from the event, and go a bit further for the sake of sharing pain points from the task of deploying VigilSOC on Windows for the first time. VigilSOC was architected as a cloud-native, Linux-first autonomous security operations center. In production, our deployments typically run on bare-metal Linux servers or containerized Kubernetes clusters managed by Helm. For development purposes the scope of deployments will vary but most development and testing originates from end users with Linux based or MacOS systems. Taking an AI-driven SOC stack—featuring PostgreSQL, Redis, the Bifrost LLM gateway, FastAPI backend services, autonomous agent worker runtimes, and a Vite-based console—and running it reliably on a Windows 11 virtual machine sounds daunting. Between hypervisor virtualization boundaries, Windows Subsystem for Linux WSL 2 quirks, process lifecycle nuances, and consumer OS background noise, the potential failure modes are numerous. We recently completed a test deployment of VigilSOC 1.0.0 on a dedicated Windows 11 VM. In this post, we document the entire architectural design, the technical hurdles encountered, why we bound our internal containers strictly to localhost behind native Windows Nginx, and how we stripped over 2 GB of consumer bloatware out of the OS to turn Windows into a lean, hardened SOC appliance. 1. Virtualization & Subsystem Architecture Deploying modern containerized workloads on Windows 11 hinges on WSL 2. For some workshop participants they were not able to make local modifications to their devices given company policy. This meant a remote virtual machine would be required. When the Windows 11 host is itself a virtual machine running under a hypervisor such as Proxmox VE or QEMU/KVM, the first hurdle is nested virtualization. For the participants who were able to modify their local configurations the nested virtualization modifications were not required. +--------------------------------------------------------------------------+ | Physical Hypervisor Proxmox VE / KVM | | Virtual CPU: "host" exposes VT-x / AMD-V flags | +--------------------------------------------------------------------------+ | v +--------------------------------------------------------------------------+ | Windows 11 Guest VM | | - Hyper-V & VirtualMachinePlatform Enabled | | - Native Nginx C:\nginx - Binds 0.0.0.0:80 / 0.0.0.0:443 | | - OpenSSH Server sshd for Headless Remote Management | | - Stripped Consumer Services ~2.5 GB RAM Reclaimed | +--------------------------------------------------------------------------+ | Localhost Forwarding v +--------------------------------------------------------------------------+ | WSL 2 Subsystem Ubuntu 22.04 LTS / Jammy | | - Native Linux Docker Engine docker.io, docker-compose-v2 | | - systemd=true /etc/wsl.conf | | - Systemd Unit: /etc/systemd/system/vigil.service | | | | Containers & Daemons Bound strictly to 127.0.0.1 : | | - Frontend Web Console Vite : 127.0.0.1:6988 | | - Backend API Uvicorn / FastAPI : 127.0.0.1:6987 | | - Bifrost LLM Gateway: 127.0.0.1:8080 | | - PostgreSQL: 127.0.0.1:5432 | | - Redis: 127.0.0.1:6379 | | - SOC Daemon & Agent Layer: services/daemon, worker, agent | +--------------------------------------------------------------------------+ Enabling Nested Virtualization If Windows 11 is launched with a generic virtualized CPU model such as kvm64 or qemu64 , attempting to register or launch any WSL 2 distribution fails immediately: WSL2 is unable to start since virtualization is not enabled on this machine. Please ensure the "Virtual Machine Platform" optional component is enabled... Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS E HYPERV NOT INSTALLED In PowerShell, Get-CimInstance Win32 Processor .VirtualizationFirmwareEnabled will report False . To fix this: 1. In the underlying hypervisor, configure the VM processor type to host e.g., qm set <VMID --cpu host in Proxmox so Intel VT-x vmx or AMD-V svm extensions pass through to the Windows guest. 2. Inside Windows, enable the Hyper-V hypervisor stack and WSL components via elevated PowerShell: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -All -NoRestart Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -All -NoRestart bcdedit /set hypervisorlaunchtype auto 3. Reboot the host and confirm VirtualizationFirmwareEnabled returns True . Provisioning the WSL 2 Subsystem Rather than relying on store-based interactive distribution installers that require a desktop user session, import the official Ubuntu 22.04 LTS Jammy rootfs directly: curl.exe -L -o C:\Ubuntu\ubuntu-jammy.tar.gz https://cloud-images.ubuntu.com/wsl/jammy/current/ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz New-Item -ItemType Directory -Path 'C:\WSL\Ubuntu' -Force wsl.exe --import Ubuntu 'C:\WSL\Ubuntu' 'C:\Ubuntu\ubuntu-jammy.tar.gz' --version 2 Configure /etc/wsl.conf to enable systemd init support: boot systemd=true 2. Docker Architecture: Headless Daemon vs. Docker Desktop One of the most consequential decisions when running Vigil on Windows is how to host Docker. The Pitfall of Docker Desktop Docker Desktop on Windows is architected as an interactive GUI desktop application. Its backend process com.docker.backend.exe is tied to the interactive user desktop session Session 1 . If you manage your server headlessly over OpenSSH sshd or via automated CI/CD tooling Session 0 : - com.docker.service is merely a Windows helper service; the container engine does not boot until a user logs in interactively at the graphical console. - Closing a desktop session or managing the VM remotely leaves the Docker daemon stopped. The Solution: Native Linux Docker Inside WSL 2 By enabling systemd inside WSL 2, we bypass Docker Desktop entirely and run native Linux Docker Engine directly within the Ubuntu distribution: sudo apt-get update sudo apt-get install -y docker.io docker-compose-v2 sudo systemctl enable --now docker Native dockerd starts automatically whenever the WSL distribution initializes. It runs autonomously in the background, requires zero Windows GUI sessions, and consumes significantly less RAM than Docker Desktop. 3. Filesystem Performance & Security Exclusions Avoid the Cross-Filesystem DrvFs Trap A common mistake on Windows is checking out the repository on the Windows C: drive e.g., C:\Users\...\vigil and accessing it inside WSL via /mnt/c/ . Cross-filesystem translation via DrvFs introduces severe performance bottlenecks: - File metadata and permission mappings chmod , POSIX ownership are simulated. - Linux inotify kernel events do not reliably propagate across the Windows NTFS boundary, breaking frontend hot reloads and log file watchers. - Docker bind mounts into /mnt/c suffer 5x to 10x I/O latency. Always clone and execute Vigil directly inside the native Linux ext4 filesystem e.g., /root/vigil or /home/analyst/vigil . Taming Windows Defender I/O Saturation During Docker image layer extraction, Python package installations via uv , and Node package dependency builds, Windows Defender Antivirus MsMpEng.exe can peg the CPU at 100% scanning the WSL virtual disk ext4.vhdx . Configure exclusions for your WSL virtual disk path and project directories: Add-MpPreference -ExclusionPath 'C:\WSL\Ubuntu' Add-MpPreference -ExclusionPath 'C:\Ubuntu' 4. Key Engineering Fixes from the Windows Trenches Deploying VigilSOC 1.0.0 on Windows uncovered several subtle edge cases spanning system clocks, process trees, and line endings. Here are the core issues resolved: 1. Clock Steps & Premature Healthcheck Timeouts During initial boot and parallel container build phases, systemd-timesyncd synchronized the WSL guest clock with NTP and the host RTC, stepping the guest clock forward by up to two hours. In scripts/lib.sh , startup healthchecks tracked elapsed time using bash’s $SECONDS variable: Vulnerable to wall-clock steps: start=$SECONDS while $ SECONDS - start -lt "$timeout" ; do ... done Because $SECONDS is calculated from time NULL - shell start time , an NTP step of +2 hours caused SECONDS - start to instantly evaluate to 7200 300 , causing wait for backend to abort prematurely even though the service had started cleanly seconds earlier. The Fix: Transition all healthcheck loops to monotonic iteration counters elapsed=0; sleep 1; elapsed=$ elapsed + 1 , ensuring immunity to NTP jumps. 2. Headless SSH Process Teardown & WSL Session Cgroups When executing startup scripts like ./start.sh -d over remote SSH, background daemons uvicorn , services/daemon/main.py , services.worker , vite would pass initial health checks but terminate immediately when the SSH connection closed. In WSL 2, commands executed via wsl.exe <command run inside an ephemeral session cgroup attached to the Windows client IPC pipe. When the calling process closes, WSL /init cleans up all child processes in that session scope. The Fix: 1. Enable systemd lingering for the user: loginctl enable-linger root and set KillUserProcesses=no in /etc/systemd/logind.conf . 2. Ensure all background spawns decouple stdin and disown processes: nohup "$VENV UVICORN" ... </dev/null logs/backend.log 2 &1 & disown "$ " 3. Wrap the stack in a dedicated systemd service /etc/systemd/system/vigil.service : Unit Description=Vigil SOC Daemon Stack After=network.target docker.service Requires=docker.service Service Type=oneshot User=root WorkingDirectory=/root/vigil Environment="HOME=/root" Environment="PATH=/usr/local/bin:/usr/bin:/bin" ExecStart=/root/vigil/start.sh -d ExecStop=/root/vigil/shutdown all.sh RemainAfterExit=yes TimeoutStartSec=360 Install WantedBy=multi-user.target Enabling this unit systemctl enable --now vigil moves the entire stack into systemd’s persistent system.slice , surviving SSH logouts and reboots. 3. CRLF Line Endings in Agent Skills If the repository was cloned on Windows with Git’s default core.autocrlf = true , Windows CRLF \r\n line terminators were introduced into markdown skill manifests core/skills/library/ /SKILL.md . In services/agent/plugins/registry.ts , skill frontmatter extraction used a regex expecting \n--- . Because of the \r , the trailing carriage return was captured into the YAML block. Strict YAML 1.2 parsing choked on the bare \r immediately following quoted scalar strings: YAMLParseError: Unexpected scalar at node end at line 4, column 43: vigil-origin: "epic 882 slice 2, 1077" ^ Because loadSkills reads all skills alphabetically upon initialization, the very first skill attack-mapping/SKILL.md aborted all agent turns. The Fix: 1. Update parseSkill and parsePlugin in services/agent/plugins/registry.ts to explicitly normalize text.replace /\r\n/g, "\n" prior to regex matching. 2. Enforce git config core.autocrlf false and strip carriage returns across the codebase: find core services tools scripts clients -type f \ -name " .md" -o -name " .yaml" -o -name " .json" -o -name " .py" -o -name " .ts" \ -exec sed -i 's/\r$//' {} + 4. Dynamic Model Discovery for External Ollama Instances When Ollama runs on an external LAN server rather than localhost:11434 , Bifrost’s health check passes because it validates the custom key URL. However, the UI’s model assignment panel queried GET /api/ai/models , which relied on core/llm/bifrost/admin.py list ollama models . list ollama models originally checked only the static OLLAMA URL environment variable. By updating it to dynamically query Bifrost’s registered key endpoints GET /api/providers/ollama/keys , Vigil discovered and synchronized all pulled models e.g., hermes3:8b , qwen2.5:7b with full token limits and tool support metadata into PostgreSQL. 5. Network Architecture: Secure Reverse Proxy with Windows Nginx A cornerstone of our production deployment is network isolation. Why Vigil Containers Bind Strictly to Localhost In .env , we configure: BIND HOST="127.0.0.1" All Vigil backend services and Docker containers bind exclusively to 127.0.0.1 : - Vigil Web Console Vite : 127.0.0.1:6988 - Backend API Uvicorn : 127.0.0.1:6987 - Bifrost AI Gateway: 127.0.0.1:8080 - PostgreSQL Database: 127.0.0.1:5432 - Redis Cache: 127.0.0.1:6379 None of these ports are directly exposed on external network adapters. If an attacker scans the host’s physical IP address, database and API ports remain completely invisible. Native Windows Nginx vs. WSL Mirrored Networking To securely expose the web console to analysts over TLS, we evaluated two architectures: 1. WSL 2 Mirrored Networking networkingMode=mirrored : Under nested virtualization on Proxmox, Hyper-V NDIS filter drivers conflict with Docker bridge network virtual ethernet pairs veth , causing virtual switch resets. 2. Native Windows Nginx C:\nginx : Running Nginx directly on the Windows 11 host. Native Windows Nginx proved overwhelmingly superior: - It binds directly to 0.0.0.0:80 and 0.0.0.0:443 across Windows network adapters. - Windows 11’s built-in WSL 2 localhost forwarder automatically connects 127.0.0.1:6988 into WSL 2. Zero complex netsh interface portproxy rules or dynamic IP tracking scripts are required. - TLS certificates and HTTPS termination are handled cleanly on the Windows host using standard Nginx syntax. Nginx Configuration C:\nginx\conf\nginx.conf worker processes 2; events { worker connections 1024; } http { include mime.types; default type application/octet-stream; sendfile on; keepalive timeout 65; Redirect all HTTP traffic to HTTPS server { listen 80; server name ; return 301 https://$host$request uri; } Terminate TLS and proxy to localhost Vite / Vigil console server { listen 443 ssl; server name ; ssl certificate C:/nginx/ssl/vigil.crt; ssl certificate key C:/nginx/ssl/vigil.key; ssl protocols TLSv1.2 TLSv1.3; ssl ciphers HIGH: aNULL: MD5; ssl prefer server ciphers on; location / { proxy pass http://127.0.0.1:6988; proxy http version 1.1; WebSocket support for live case updates and agent streaming proxy set header Upgrade $http upgrade; proxy set header Connection "upgrade"; proxy set header Host $host; proxy set header X-Real-IP $remote addr; proxy set header X-Forwarded-For $proxy add x forwarded for; proxy set header X-Forwarded-Proto https; Extended timeouts for long-running LLM investigation turns proxy read timeout 300s; proxy send timeout 300s; } } } Only TCP ports 80 and 443 are allowed through the Windows Firewall: New-NetFirewallRule -DisplayName "Vigil HTTPS 443 " -Direction Inbound -LocalPort 443 -Protocol TCP -Action Allow New-NetFirewallRule -DisplayName "Vigil HTTP 80 " -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow The Nginx process is registered as an automatic Windows Scheduled Task under NT AUTHORITY\SYSTEM with PT0S infinite execution limits, guaranteeing continuous uptime across reboots. 6. Transforming Windows 11 into a Hardened SOC Appliance Out of the box, a standard Windows 11 installation runs dozens of consumer background processes: OneDrive syncing, News and Widgets feeds, Spotlight wallpaper downloads, Xbox game recording hooks, Edge pre-launch engines, and telemetry services. On a dedicated server hosting an AI security platform, these components represent unacceptable resource contention, CPU wakeups, disk I/O, and unnecessary outbound network polling. We applied a thorough hardening and debloating regimen that reclaimed between 1.5 GB and 2.5 GB of RAM while ensuring that Hyper-V, WSL 2, OpenSSH, and Windows Defender remained intact. | Category | Component / Process | Action Taken | Why It Was Disabled / Removed | Reclaimed Impact | |---|---|---|---|---| | Cloud Storage | Microsoft OneDrive OneDrive.exe | Uninstalled via OneDriveSetup.exe /uninstall ; GPO DisableFileSyncNGSC=1 | Vigil stores data in PostgreSQL, Redis, and ext4 VHDX. OneDrive causes unwanted file locks. | ~90 MB RAM; eliminated background sync tasks. | | News & MSN | Windows Widgets Widgets.exe , WidgetService.exe | Process terminated; AppX Client.WebExperience uninstalled; GPO AllowNewsAndInterests=0 | Delivers consumer news feeds and ad tiles. Zero utility on a SOC server. | ~100 MB RAM; stopped continuous MSN HTTP polling. | | News & MSN | Bing News, Weather, Search | Uninstalled provisioned AppX packages | Standalone consumer UWP applications. | Frees disk space; stops background push listeners. | | Lockscreen | Windows Spotlight ContentDeliveryManager | GPOs: DisableWindowsSpotlightFeatures=1 , DisableWindowsConsumerFeatures=1 | Periodically downloads rotating wallpapers, lockscreen ads, and tips from Bing CDNs. | Halts periodic CDN image downloads and disk writes. | | Gaming | Xbox Gaming Subsystem | Removed 5 AppX packages XboxGamingOverlay , TCUI , etc. ; GPO AllowGameDVR=0 | Social gaming overlays, party chat, and screen recording hooks. | Frees disk space and unregisters kernel display hooks. | | Consumer Apps | Solitaire, Clipchamp, Teams, Outlook | Removed AppX packages across all users | Pre-installed consumer apps card games, video editors, consumer chat . | Completely clears non-enterprise bloatware. | | Edge Engine | Edge Startup Boost & WebView Persistence | Policies: StartupBoostEnabled=0 , BackgroundModeEnabled=0 , WebWidgetAllowed=0 | Pre-warms Edge and WebView2 processes in RAM for faster consumer launching. | Reclaims ~500 MB RAM immediately. | | Telemetry | Diagnostic Tracking DiagTrack , dmwappushservice | Services stopped and set to Disabled ; Policy AllowTelemetry=0 | Continuously uploads diagnostic logs, crash reports, and telemetry to Microsoft. | Reduces background CPU, disk logging, and network telemetry. | | Search & AI | Bing Start Search & Windows Copilot | Policies: DisableWebSearch=1 , TurnOffWindowsCopilot=1 | Sends local Start menu searches over the internet to Bing; injects Copilot panels. | Prevents outbound search tracking and browser webviews. | Preserved Core Capabilities Throughout this optimization, critical infrastructure components were preserved without modification: - Hyper-V & Virtual Machine Platform : Active for WSL 2 virtualization. - Windows Subsystem for Linux WSL 2 : Running Ubuntu 22.04 LTS and native Docker. - OpenSSH Server sshd : Continuously active for headless terminal administration. - Windows Defender Antivirus & Firewall : Active with targeted exclusions for the WSL VHDX. - Windows Terminal & PowerShell : Available for system administration. The Automated Optimization Script WARNING: Review and understand before use. Always make backups prior to modifying your system and use at your own risk The entire debloating procedure was codified into an idempotent PowerShell script: Run from an elevated Administrator PowerShell prompt Write-Host "=== Hardening Windows 11 Host for Vigil SOC ===" -ForegroundColor Cyan 1. Uninstall & Disable OneDrive Stop-Process -Name "OneDrive" -Force -ErrorAction SilentlyContinue $od = "$env:SystemRoot\System32\OneDriveSetup.exe" if -not Test-Path $od { $od = "$env:SystemRoot\SysWOW64\OneDriveSetup.exe" } if Test-Path $od { Start-Process $od -ArgumentList "/uninstall" -Wait } $odKey = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\OneDrive" if -not Test-Path $odKey { New-Item -Path $odKey -Force | Out-Null } Set-ItemProperty -Path $odKey -Name "DisableFileSyncNGSC" -Value 1 -Type DWord Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "OneDrive" -ErrorAction SilentlyContinue 2. Disable Widgets & News Stop-Process -Name "Widgets", "WidgetService" -Force -ErrorAction SilentlyContinue $dshKey = "HKLM:\SOFTWARE\Policies\Microsoft\Dsh" if -not Test-Path $dshKey { New-Item -Path $dshKey -Force | Out-Null } Set-ItemProperty -Path $dshKey -Name "AllowNewsAndInterests" -Value 0 -Type DWord Get-AppxPackage -AllUsers WebExperience | Remove-AppxPackage -AllUsers -ErrorAction SilentlyContinue 3. Disable Windows Spotlight & Consumer Features $cloudKey = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\CloudContent" if -not Test-Path $cloudKey { New-Item -Path $cloudKey -Force | Out-Null } Set-ItemProperty -Path $cloudKey -Name "DisableWindowsSpotlightFeatures" -Value 1 -Type DWord Set-ItemProperty -Path $cloudKey -Name "DisableWindowsConsumerFeatures" -Value 1 -Type DWord 4. Remove Consumer Bloatware, Solitaire, and Xbox $bloatApps = @ "Microsoft.BingNews", "Microsoft.BingWeather", "Microsoft.BingSearch", "Microsoft.MicrosoftSolitaireCollection", "Clipchamp.Clipchamp", "Microsoft.GamingApp", "Microsoft.XboxGamingOverlay", "Microsoft.XboxIdentityProvider", "Microsoft.XboxSpeechToTextOverlay", "Microsoft.Xbox.TCUI", "Microsoft.XboxGameCallableUI", "Microsoft.YourPhone", "MSTeams", "Microsoft.OutlookForWindows", "Microsoft.GetHelp", "Microsoft.WindowsFeedbackHub", "Microsoft.WindowsCamera", "Microsoft.WindowsSoundRecorder", "Microsoft.ZuneMusic" foreach $app in $bloatApps { Get-AppxPackage -AllUsers -Name $app -ErrorAction SilentlyContinue | Remove-AppxPackage -AllUsers -ErrorAction SilentlyContinue Get-AppxProvisionedPackage -Online | Where-Object DisplayName -eq $app | Remove-AppxProvisionedPackage -Online -ErrorAction SilentlyContinue } $gKey = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\GameDVR" if -not Test-Path $gKey { New-Item -Path $gKey -Force | Out-Null } Set-ItemProperty -Path $gKey -Name "AllowGameDVR" -Value 0 -Type DWord 5. Disable Edge Startup Boost & Background Persistence ~500 MB RAM saved Stop-Process -Name "msedge", "msedgewebview2" -Force -ErrorAction SilentlyContinue $eKey = "HKLM:\SOFTWARE\Policies\Microsoft\Edge" if -not Test-Path $eKey { New-Item -Path $eKey -Force | Out-Null } Set-ItemProperty -Path $eKey -Name "StartupBoostEnabled" -Value 0 -Type DWord Set-ItemProperty -Path $eKey -Name "BackgroundModeEnabled" -Value 0 -Type DWord 6. Disable Telemetry, Bing Web Search, and Copilot Stop-Service -Name "DiagTrack" -Force -ErrorAction SilentlyContinue Set-Service -Name "DiagTrack" -StartupType Disabled Stop-Service -Name "dmwappushservice" -Force -ErrorAction SilentlyContinue Set-Service -Name "dmwappushservice" -StartupType Disabled $dcKey = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" if -not Test-Path $dcKey { New-Item -Path $dcKey -Force | Out-Null } Set-ItemProperty -Path $dcKey -Name "AllowTelemetry" -Value 0 -Type DWord $sKey = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Windows Search" if -not Test-Path $sKey { New-Item -Path $sKey -Force | Out-Null } Set-ItemProperty -Path $sKey -Name "DisableWebSearch" -Value 1 -Type DWord Set-ItemProperty -Path $sKey -Name "ConnectedSearchUseWeb" -Value 0 -Type DWord $cpKey = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsCopilot" if -not Test-Path $cpKey { New-Item -Path $cpKey -Force | Out-Null } Set-ItemProperty -Path $cpKey -Name "TurnOffWindowsCopilot" -Value 1 -Type DWord Write-Host "=== Hardening Complete. ~2GB RAM Reclaimed. ===" -ForegroundColor Green 7. Operational Verification Following these adjustments, the complete VigilSOC stack was verified running in production on the Windows 11 host: - Reverse Proxy : curl -k -I https://<host-ip / returns HTTP/1.1 200 OK Server: nginx , with HTTP-to-HTTPS redirection operational. - Core Microservices : Native Docker Engine hosts deeptempo-postgres , deeptempo-redis , and deeptempo-bifrost , all healthy and bound strictly to 127.0.0.1 . - Backend API : Serving http://localhost:6987/api/health with status healthy . - SOC Daemons : Background daemon, LLM worker, and agent runtimes running uninterrupted in systemd’s persistent slice. - Model Discovery : Multiple local models hermes3:8b , qwen2.5:7b recognized and assignable to individual SOC agents. - Web Console : Fully interactive over HTTPS with live WebSocket investigation streaming. Deploying VigilSOC on Windows 11 does not have to be a fragile hack. By running native Docker inside WSL 2, terminating TLS with native Windows Nginx, isolating internal microservices to localhost, and stripping away unnecessary consumer OS overhead, Windows 11 can run VigilSOC reliably. While there is no intended support path for Windows consumer or server installations in an official capacity the platform can still be used to learn when other device types are unavailable. Questions or deploying Vigil in your environment? Drop into our community channels on the Vigil community page https://vigilsoc.org/community/ or explore the repository on GitHub https://github.com/Vigil-SOC/vigil .