Windows servers
Alpacon supports Windows servers through the Alpamon agent. Terminal access (Websh), file transfer (WebFTP), system information, system control, and metrics all work; some Unix-specific features do not. This page covers what’s specific to Windows; the step-by-step procedures live in the linked guides.
Supported versions and architecture
| Supported | |
|---|---|
| Windows Server | 2019, 2022, 2025 |
| Windows client | Windows 10 (1803 or later), Windows 11 |
| Architecture | amd64 (x64) only |
The support baseline is Windows Server 2019+ and Windows 10 1803+. Websh (the browser terminal) additionally needs ConPTY, the Windows pseudoconsole available only on Server 2019+ and Windows 10 1809+—so on Windows 10 1803–1808, everything works except Websh. Windows Server 2016 and older are not supported: the installer relies on the built-in tar.exe and modern PowerShell features that aren’t present there. There is no ARM64 build for Windows.
Installation
Install from an elevated PowerShell (cmd.exe is not supported). The workspace-generated command, install.ps1, manual .zip, and Ansible paths are all in the installation guide.
What works on Windows
| Feature | Windows |
|---|---|
| Terminal sessions (Websh) | ✅ |
Command execution (exec, shell) | ✅ (PowerShell) |
| File transfer (WebFTP) | ✅ |
| System information (users, groups, inventory) | ✅ |
| System control (restart, reboot, shutdown) | ✅ |
| Real-time metrics | ✅ |
| Agent self-upgrade | ✅ |
| User and group management | ❌ |
Permission changes (chmod / chown) | ❌ |
| Firewall management | ❌ |
| Port forwarding (tunnel) | ❌ |
| Code editor | ❌ |
| ARM64 builds | ❌ |
Permissions and identity on Windows
This is the most important difference from Linux and macOS.
On Windows, the agent runs every command as SYSTEM (LocalSystem), regardless of which account you select when connecting. The account shown in a session is an audit label, not a privilege boundary—running whoami in Websh returns nt authority\system.
Because there is no per-user boundary on the server, access is controlled by Alpacon rather than by Windows file permissions:
- Websh and command execution run as SYSTEM.
- WebFTP runs as SYSTEM and can read and write any path the agent can reach, including system directories such as
C:\Windows\System32. There is no home-directory confinement.
The real boundary is your Alpacon roles and permissions and the list of users allowed to connect. Grant Websh and WebFTP access deliberately, and use roles to limit who can reach sensitive servers and paths.
Who can connect
Alpacon does not create Windows accounts on demand. To connect with a system account, that account must already exist on the server—create the Windows account first, and it becomes selectable when connecting.
Upgrades
Like Linux and macOS, the Windows agent self-updates. Trigger it with the console Upgrade command (alpacon agent upgrade) or run alpamon upgrade on the server; the agent downloads the latest release, verifies the checksum, and restarts itself. If the self-update path is blocked, re-run the installer with the latest release—see upgrading the agent.
Removal and recovery
Remove the agent with alpamon unregister, or recover a stuck host with alpamon register --force. Run these on the server (RDP or serial console), not over Websh, on alpamon v2.3.0 or later. Full steps: uninstallation and re-registration and recovery.
Troubleshooting
- SmartScreen: the binary is unsigned; if you downloaded the archive manually, run
Unblock-Filebefore registering. - No automatic log rotation:
%ProgramData%\alpamon\log\alpamon.loggrows unbounded—rotate it with a scheduled task. - Service won’t start (including StartPending) and other agent issues: see Agent issues → Windows.
Operations reference
For deeper operational detail—service recovery behavior, PowerShell and TLS requirements, and the full install matrix—see the Alpamon Windows runbook: alpamon/docs/windows.md.