{"slug": "deploying-vigilsoc-on-windows-11-architecture-pitfalls-and-hardening", "title": "Deploying VigilSOC on Windows 11: Architecture, Pitfalls, and Hardening", "summary": "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.", "body_md": "**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.**\n\nVigilSOC 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.\n\nTaking 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.\n\nWe 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.\n\n## 1. Virtualization & Subsystem Architecture\n\nDeploying 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.\n\n```\n+--------------------------------------------------------------------------+\n| Physical Hypervisor (Proxmox VE / KVM)                                    |\n| Virtual CPU: \"host\" (exposes VT-x / AMD-V flags)                         |\n+--------------------------------------------------------------------------+\n                                     |\n                                     v\n+--------------------------------------------------------------------------+\n| Windows 11 Guest VM                                                      |\n| - Hyper-V & VirtualMachinePlatform Enabled                               |\n| - Native Nginx (C:\\nginx) -> Binds 0.0.0.0:80 / 0.0.0.0:443              |\n| - OpenSSH Server (sshd) for Headless Remote Management                  |\n| - Stripped Consumer Services (~2.5 GB RAM Reclaimed)                    |\n+--------------------------------------------------------------------------+\n                                     | (Localhost Forwarding)\n                                     v\n+--------------------------------------------------------------------------+\n| WSL 2 Subsystem (Ubuntu 22.04 LTS / Jammy)                               |\n| - Native Linux Docker Engine (docker.io, docker-compose-v2)              |\n| - systemd=true (/etc/wsl.conf)                                           |\n| - Systemd Unit: /etc/systemd/system/vigil.service                        |\n|                                                                          |\n| Containers & Daemons (Bound strictly to 127.0.0.1):                      |\n| - Frontend Web Console (Vite):         127.0.0.1:6988                    |\n| - Backend API (Uvicorn / FastAPI):     127.0.0.1:6987                    |\n| - Bifrost LLM Gateway:                 127.0.0.1:8080                    |\n| - PostgreSQL:                          127.0.0.1:5432                    |\n| - Redis:                               127.0.0.1:6379                    |\n| - SOC Daemon & Agent Layer:            services/daemon, worker, agent    |\n+--------------------------------------------------------------------------+\n```\n\n### Enabling Nested Virtualization\n\nIf 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:\n\n```\nWSL2 is unable to start since virtualization is not enabled on this machine.\nPlease ensure the \"Virtual Machine Platform\" optional component is enabled...\nError code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED\n```\n\nIn PowerShell, `(Get-CimInstance Win32_Processor).VirtualizationFirmwareEnabled` will report `False`.\n\nTo fix this:\n\n1. 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.\n2. Inside Windows, enable the Hyper-V hypervisor stack and WSL components via elevated PowerShell:\n    \n\n```\nEnable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -All -NoRestart\nEnable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart\nEnable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -All -NoRestart\nbcdedit /set hypervisorlaunchtype auto\n```\n\n3. Reboot the host and confirm `VirtualizationFirmwareEnabled` returns`True` .\n\n### Provisioning the WSL 2 Subsystem\n\nRather than relying on store-based interactive distribution installers that require a desktop user session, import the official Ubuntu 22.04 LTS (Jammy) rootfs directly:\n\n```\ncurl.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\nNew-Item -ItemType Directory -Path 'C:\\WSL\\Ubuntu' -Force\nwsl.exe --import Ubuntu 'C:\\WSL\\Ubuntu' 'C:\\Ubuntu\\ubuntu-jammy.tar.gz' --version 2\n```\n\nConfigure `/etc/wsl.conf` to enable systemd init support:\n\n```\n[boot]\nsystemd=true\n```\n\n## 2. Docker Architecture: Headless Daemon vs. Docker Desktop\n\nOne of the most consequential decisions when running Vigil on Windows is how to host Docker.\n\n### The Pitfall of Docker Desktop\n\nDocker 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).\n\nIf you manage your server headlessly over OpenSSH (`sshd`) or via automated CI/CD tooling (Session 0):\n\n- `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.\n- Closing a desktop session or managing the VM remotely leaves the Docker daemon stopped.\n\n### The Solution: Native Linux Docker Inside WSL 2\n\nBy enabling `systemd` inside WSL 2, we bypass Docker Desktop entirely and run native Linux Docker Engine directly within the Ubuntu distribution:\n\n```\nsudo apt-get update\nsudo apt-get install -y docker.io docker-compose-v2\nsudo systemctl enable --now docker\n```\n\nNative `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.\n\n## 3. Filesystem Performance & Security Exclusions\n\n### Avoid the Cross-Filesystem DrvFs Trap\n\nA 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/`.\n\nCross-filesystem translation via DrvFs introduces severe performance bottlenecks:\n\n- File metadata and permission mappings (`chmod` , POSIX ownership) are simulated.\n- Linux `inotify` kernel events do not reliably propagate across the Windows NTFS boundary, breaking frontend hot reloads and log file watchers.\n- Docker bind mounts into `/mnt/c` suffer 5x to 10x I/O latency.\n\n**Always clone and execute Vigil directly inside the native Linux ext4 filesystem** (e.g., `/root/vigil` or `/home/analyst/vigil`).\n\n### Taming Windows Defender I/O Saturation\n\nDuring 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`).\n\nConfigure exclusions for your WSL virtual disk path and project directories:\n\n```\nAdd-MpPreference -ExclusionPath 'C:\\WSL\\Ubuntu'\nAdd-MpPreference -ExclusionPath 'C:\\Ubuntu'\n```\n\n## 4. Key Engineering Fixes from the Windows Trenches\n\nDeploying 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:\n\n### 1. Clock Steps & Premature Healthcheck Timeouts\n\nDuring 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.\n\nIn `scripts/lib.sh`, startup healthchecks tracked elapsed time using bash’s `$SECONDS` variable:\n\n```\n# Vulnerable to wall-clock steps:\nstart=$SECONDS\nwhile [ $((SECONDS - start)) -lt \"$timeout\" ]; do ... done\n```\n\nBecause `$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.\n\n**The Fix:** Transition all healthcheck loops to monotonic iteration counters (`elapsed=0; sleep 1; elapsed=$((elapsed + 1))`), ensuring immunity to NTP jumps.\n\n### 2. Headless SSH Process Teardown & WSL Session Cgroups\n\nWhen 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.\n\nIn 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.\n\n**The Fix:**\n\n1. Enable systemd lingering for the user:\n    \n\n```\nloginctl enable-linger root\n```\n\n and set `KillUserProcesses=no` in`/etc/systemd/logind.conf` .\n2. Ensure all background spawns decouple stdin and disown processes:\n    \n\n```\nnohup \"$VENV_UVICORN\" ... </dev/null > logs/backend.log 2>&1 &\ndisown \"$!\"\n```\n\n3. Wrap the stack in a dedicated systemd service (`/etc/systemd/system/vigil.service` ):\n\n```\n[Unit]\nDescription=Vigil SOC Daemon Stack\nAfter=network.target docker.service\nRequires=docker.service\n\n[Service]\nType=oneshot\nUser=root\nWorkingDirectory=/root/vigil\nEnvironment=\"HOME=/root\"\nEnvironment=\"PATH=/usr/local/bin:/usr/bin:/bin\"\nExecStart=/root/vigil/start.sh -d\nExecStop=/root/vigil/shutdown_all.sh\nRemainAfterExit=yes\nTimeoutStartSec=360\n\n[Install]\nWantedBy=multi-user.target\n```\n\n Enabling this unit ( `systemctl enable --now vigil` ) moves the entire stack into systemd’s persistent`system.slice` , surviving SSH logouts and reboots.\n\n### 3. CRLF Line Endings in Agent Skills\n\nIf 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`).\n\nIn `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:\n\n```\nYAMLParseError: Unexpected scalar at node end at line 4, column 43: vigil-origin: \"epic #882 slice 2, #1077\" ^\n```\n\nBecause `loadSkills()` reads all skills alphabetically upon initialization, the very first skill (`attack-mapping/SKILL.md`) aborted all agent turns.\n\n**The Fix:**\n\n1. Update `parseSkill()` and`parsePlugin()` in`services/agent/plugins/registry.ts` to explicitly normalize`text.replace(/\\r\\n/g, \"\\n\")` prior to regex matching.\n2. Enforce `git config core.autocrlf false` and strip carriage returns across the codebase:\n\n```\nfind 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$//' {} +\n```\n\n### 4. Dynamic Model Discovery for External Ollama Instances\n\nWhen 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`).\n\n`_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.\n\n## 5. Network Architecture: Secure Reverse Proxy with Windows Nginx\n\nA cornerstone of our production deployment is network isolation.\n\n### Why Vigil Containers Bind Strictly to Localhost\n\nIn `.env`, we configure:\n\n```\nBIND_HOST=\"127.0.0.1\"\n```\n\nAll Vigil backend services and Docker containers bind exclusively to `127.0.0.1`:\n\n- **Vigil Web Console (Vite):**`127.0.0.1:6988`\n- **Backend API (Uvicorn):**`127.0.0.1:6987`\n- **Bifrost AI Gateway:**`127.0.0.1:8080`\n- **PostgreSQL Database:**`127.0.0.1:5432`\n- **Redis Cache:**`127.0.0.1:6379`\n\nNone 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.\n\n### Native Windows Nginx vs. WSL Mirrored Networking\n\nTo securely expose the web console to analysts over TLS, we evaluated two architectures:\n\n1. *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.\n2. *Native Windows Nginx (`C:\\nginx`)* : Running Nginx directly on the Windows 11 host.\n\nNative Windows Nginx proved overwhelmingly superior:\n\n- It binds directly to `0.0.0.0:80` and`0.0.0.0:443` across Windows network adapters.\n- **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.\n- TLS certificates and HTTPS termination are handled cleanly on the Windows host using standard Nginx syntax.\n\n### Nginx Configuration (`C:\\nginx\\conf\\nginx.conf`)\n\n```\nworker_processes 2;\n\nevents {\n    worker_connections 1024;\n}\n\nhttp {\n    include       mime.types;\n    default_type  application/octet-stream;\n    sendfile        on;\n    keepalive_timeout 65;\n\n    # Redirect all HTTP traffic to HTTPS\n    server {\n        listen       80;\n        server_name  _;\n        return 301 https://$host$request_uri;\n    }\n\n    # Terminate TLS and proxy to localhost Vite / Vigil console\n    server {\n        listen       443 ssl;\n        server_name  _;\n\n        ssl_certificate      C:/nginx/ssl/vigil.crt;\n        ssl_certificate_key  C:/nginx/ssl/vigil.key;\n\n        ssl_protocols TLSv1.2 TLSv1.3;\n        ssl_ciphers HIGH:!aNULL:!MD5;\n        ssl_prefer_server_ciphers on;\n\n        location / {\n            proxy_pass http://127.0.0.1:6988;\n            proxy_http_version 1.1;\n\n            # WebSocket support for live case updates and agent streaming\n            proxy_set_header Upgrade $http_upgrade;\n            proxy_set_header Connection \"upgrade\";\n\n            proxy_set_header Host $host;\n            proxy_set_header X-Real-IP $remote_addr;\n            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n            proxy_set_header X-Forwarded-Proto https;\n\n            # Extended timeouts for long-running LLM investigation turns\n            proxy_read_timeout 300s;\n            proxy_send_timeout 300s;\n        }\n    }\n}\n```\n\nOnly TCP ports 80 and 443 are allowed through the Windows Firewall:\n\n```\nNew-NetFirewallRule -DisplayName \"Vigil HTTPS (443)\" -Direction Inbound -LocalPort 443 -Protocol TCP -Action Allow\nNew-NetFirewallRule -DisplayName \"Vigil HTTP (80)\" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow\n```\n\nThe Nginx process is registered as an automatic Windows Scheduled Task under `NT AUTHORITY\\SYSTEM` with `PT0S` (infinite) execution limits, guaranteeing continuous uptime across reboots.\n\n## 6. Transforming Windows 11 into a Hardened SOC Appliance\n\nOut 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.\n\nOn a dedicated server hosting an AI security platform, these components represent unacceptable resource contention, CPU wakeups, disk I/O, and unnecessary outbound network polling.\n\nWe 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.\n\n| Category | Component / Process | Action Taken | Why It Was Disabled / Removed | Reclaimed Impact | \n|---|---|---|---|---|\n| **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. | \n| **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. | \n| **News & MSN** | **Bing News, Weather, Search** | Uninstalled provisioned AppX packages | Standalone consumer UWP applications. | Frees disk space; stops background push listeners. | \n| **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. | \n| **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. | \n| **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. | \n| **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. | \n| **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. | \n| **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. | \n\n### Preserved Core Capabilities\n\nThroughout this optimization, critical infrastructure components were preserved without modification:\n\n- **Hyper-V & Virtual Machine Platform** : Active for WSL 2 virtualization.\n- **Windows Subsystem for Linux (WSL 2)** : Running Ubuntu 22.04 LTS and native Docker.\n- **OpenSSH Server (`sshd`)** : Continuously active for headless terminal administration.\n- **Windows Defender Antivirus & Firewall** : Active with targeted exclusions for the WSL VHDX.\n- **Windows Terminal & PowerShell** : Available for system administration.\n\n### The Automated Optimization Script\n\nWARNING: Review and understand before use. Always make backups prior to modifying your system and use at your own risk!!!\n\nThe entire debloating procedure was codified into an idempotent PowerShell script:\n\n```\n# Run from an elevated Administrator PowerShell prompt\nWrite-Host \"=== Hardening Windows 11 Host for Vigil SOC ===\" -ForegroundColor Cyan\n\n# 1. Uninstall & Disable OneDrive\nStop-Process -Name \"OneDrive\" -Force -ErrorAction SilentlyContinue\n$od = \"$env:SystemRoot\\System32\\OneDriveSetup.exe\"\nif (-not (Test-Path $od)) { $od = \"$env:SystemRoot\\SysWOW64\\OneDriveSetup.exe\" }\nif (Test-Path $od) { Start-Process $od -ArgumentList \"/uninstall\" -Wait }\n$odKey = \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows\\OneDrive\"\nif (-not (Test-Path $odKey)) { New-Item -Path $odKey -Force | Out-Null }\nSet-ItemProperty -Path $odKey -Name \"DisableFileSyncNGSC\" -Value 1 -Type DWord\nRemove-ItemProperty -Path \"HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\" -Name \"OneDrive\" -ErrorAction SilentlyContinue\n\n# 2. Disable Widgets & News\nStop-Process -Name \"Widgets\", \"WidgetService\" -Force -ErrorAction SilentlyContinue\n$dshKey = \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Dsh\"\nif (-not (Test-Path $dshKey)) { New-Item -Path $dshKey -Force | Out-Null }\nSet-ItemProperty -Path $dshKey -Name \"AllowNewsAndInterests\" -Value 0 -Type DWord\nGet-AppxPackage -AllUsers *WebExperience* | Remove-AppxPackage -AllUsers -ErrorAction SilentlyContinue\n\n# 3. Disable Windows Spotlight & Consumer Features\n$cloudKey = \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows\\CloudContent\"\nif (-not (Test-Path $cloudKey)) { New-Item -Path $cloudKey -Force | Out-Null }\nSet-ItemProperty -Path $cloudKey -Name \"DisableWindowsSpotlightFeatures\" -Value 1 -Type DWord\nSet-ItemProperty -Path $cloudKey -Name \"DisableWindowsConsumerFeatures\" -Value 1 -Type DWord\n\n# 4. Remove Consumer Bloatware, Solitaire, and Xbox\n$bloatApps = @(\n    \"Microsoft.BingNews\", \"Microsoft.BingWeather\", \"Microsoft.BingSearch\",\n    \"Microsoft.MicrosoftSolitaireCollection\", \"Clipchamp.Clipchamp\",\n    \"Microsoft.GamingApp\", \"Microsoft.XboxGamingOverlay\", \"Microsoft.XboxIdentityProvider\",\n    \"Microsoft.XboxSpeechToTextOverlay\", \"Microsoft.Xbox.TCUI\", \"Microsoft.XboxGameCallableUI\",\n    \"Microsoft.YourPhone\", \"MSTeams\", \"Microsoft.OutlookForWindows\",\n    \"Microsoft.GetHelp\", \"Microsoft.WindowsFeedbackHub\", \"Microsoft.WindowsCamera\",\n    \"Microsoft.WindowsSoundRecorder\", \"Microsoft.ZuneMusic\"\n)\nforeach ($app in $bloatApps) {\n    Get-AppxPackage -AllUsers -Name $app -ErrorAction SilentlyContinue | Remove-AppxPackage -AllUsers -ErrorAction SilentlyContinue\n    Get-AppxProvisionedPackage -Online | Where-Object DisplayName -eq $app | Remove-AppxProvisionedPackage -Online -ErrorAction SilentlyContinue\n}\n$gKey = \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows\\GameDVR\"\nif (-not (Test-Path $gKey)) { New-Item -Path $gKey -Force | Out-Null }\nSet-ItemProperty -Path $gKey -Name \"AllowGameDVR\" -Value 0 -Type DWord\n\n# 5. Disable Edge Startup Boost & Background Persistence (~500 MB RAM saved)\nStop-Process -Name \"msedge\", \"msedgewebview2\" -Force -ErrorAction SilentlyContinue\n$eKey = \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Edge\"\nif (-not (Test-Path $eKey)) { New-Item -Path $eKey -Force | Out-Null }\nSet-ItemProperty -Path $eKey -Name \"StartupBoostEnabled\" -Value 0 -Type DWord\nSet-ItemProperty -Path $eKey -Name \"BackgroundModeEnabled\" -Value 0 -Type DWord\n\n# 6. Disable Telemetry, Bing Web Search, and Copilot\nStop-Service -Name \"DiagTrack\" -Force -ErrorAction SilentlyContinue\nSet-Service -Name \"DiagTrack\" -StartupType Disabled\nStop-Service -Name \"dmwappushservice\" -Force -ErrorAction SilentlyContinue\nSet-Service -Name \"dmwappushservice\" -StartupType Disabled\n\n$dcKey = \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows\\DataCollection\"\nif (-not (Test-Path $dcKey)) { New-Item -Path $dcKey -Force | Out-Null }\nSet-ItemProperty -Path $dcKey -Name \"AllowTelemetry\" -Value 0 -Type DWord\n\n$sKey = \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows\\Windows Search\"\nif (-not (Test-Path $sKey)) { New-Item -Path $sKey -Force | Out-Null }\nSet-ItemProperty -Path $sKey -Name \"DisableWebSearch\" -Value 1 -Type DWord\nSet-ItemProperty -Path $sKey -Name \"ConnectedSearchUseWeb\" -Value 0 -Type DWord\n\n$cpKey = \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsCopilot\"\nif (-not (Test-Path $cpKey)) { New-Item -Path $cpKey -Force | Out-Null }\nSet-ItemProperty -Path $cpKey -Name \"TurnOffWindowsCopilot\" -Value 1 -Type DWord\n\nWrite-Host \"=== Hardening Complete. ~2GB RAM Reclaimed. ===\" -ForegroundColor Green\n```\n\n## 7. Operational Verification\n\nFollowing these adjustments, the complete VigilSOC stack was verified running in production on the Windows 11 host:\n\n- **Reverse Proxy** :`curl -k -I https://<host-ip>/` returns`HTTP/1.1 200 OK` (Server:`nginx` ), with HTTP-to-HTTPS redirection operational.\n- **Core Microservices** : Native Docker Engine hosts`deeptempo-postgres` ,`deeptempo-redis` , and`deeptempo-bifrost` , all healthy and bound strictly to`127.0.0.1` .\n- **Backend API** : Serving`http://localhost:6987/api/health` with status`healthy` .\n- **SOC Daemons** : Background daemon, LLM worker, and agent runtimes running uninterrupted in systemd’s persistent slice.\n- **Model Discovery** : Multiple local models (`hermes3:8b` ,`qwen2.5:7b` ) recognized and assignable to individual SOC agents.\n- **Web Console** : Fully interactive over HTTPS with live WebSocket investigation streaming.\n\nDeploying 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.\n\n*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).*", "url": "https://wpnews.pro/news/deploying-vigilsoc-on-windows-11-architecture-pitfalls-and-hardening", "canonical_source": "https://vigilsoc.org/blog/2026/11/13/vigil-on-win64/", "published_at": "2026-11-13 00:00:00+00:00", "updated_at": "2026-11-13 21:20:56.512390+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-tools"], "entities": ["VigilSOC", "Windows 11", "WSL 2", "Ubuntu 22.04 LTS", "Proxmox VE", "QEMU/KVM", "Bifrost", "Nginx"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/deploying-vigilsoc-on-windows-11-architecture-pitfalls-and-hardening", "markdown": "https://wpnews.pro/news/deploying-vigilsoc-on-windows-11-architecture-pitfalls-and-hardening.md", "text": "https://wpnews.pro/news/deploying-vigilsoc-on-windows-11-architecture-pitfalls-and-hardening.txt", "jsonld": "https://wpnews.pro/news/deploying-vigilsoc-on-windows-11-architecture-pitfalls-and-hardening.jsonld"}}