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. Older versions such as Windows Server 2016 are not officially supported, though the console-generated install command still runs there and non-interactive features (WebFTP, command execution, metrics, system info) work; only Websh is unavailable. 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 | ❌ (re-run the installer to update) |
| 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
Unlike Linux and macOS, the Windows agent does not self-update, and command-based upgrade (console Upgrade / alpacon agent upgrade) does not apply to Windows. Update by re-running 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.