WRM PRO

Web Remote Manager PRO (WRM)

A remote server manager that runs in any web browser, with an AI assistant and guided setup for AI agents. Add your own AI provider or a local model: WRM offers model suggestions, an Ollama setup wizard and connection presets for MCP agents to help you start practical work on your servers quickly.

Optional automatic Ollama installation: from WRM, an administrator can install the Ollama server on the WRM host, start it as a background service and download the chosen model. Enable ai_ollama_manage in Admin → AI, then confirm each action in the provider wizard. Choose the suggested local model or another supported model; installation and setup actions are recorded and audited. Connect Codex CLI, Claude Code, Gemini CLI, OpenCode, Cursor / VS Code, Claude or ChatGPT through the MCP wizard, which supplies the connection commands or configuration and lets you choose the servers and permissions.

Manage SSH terminals, SFTP / FTP / FTPS files and RDP / VNC desktops, Git service comparison and deployment, jump hosts, proxies, tunnels, BMC and serial consoles, keys and credentials, inventory imports, server-to-server transfers, notifications and collaboration with voice. AI tools can inspect logs and services, diagnose problems, run permitted commands and propose file changes with read-only, approval or limited automatic modes. WRM also provides sharing roles, 2FA, audit logs and session recordings. Run WRM as one self-hosted binary, a Docker container or a Linux AppImage.

Current version: v14.5.0 · Download · Release notes · Changelog · Security · Architecture

What's new in v14.5.0

Chains recognise your servers. The builder lists servers by folder with search and adds several at once, without quick connections and without adding a server twice. Right after adding them, WRM looks at the servers read-only and turns their services, containers, named ports (PostgreSQL (5432), HTTPS (443) …) and network mounts into one-click check suggestions. Mounts between servers suggest the links. A URL, host:port or host name becomes an outside endpoint with the fitting checks, and Test now tries one check without saving. See Chains.

No more freezing while an AI works through MCP. The MCP live view used one connection per session, and over plain HTTP a browser has only six per server for all its tabs, so WRM stopped responding once an AI app had opened six sessions. All AI and MCP views of a tab now share one stream.

What's new in v14.4.0

See every S3 request, and what it costs. The storage window has a live 📡 S3 activity panel beside the file browser, shown by default and hidden with one button. It lists every request WRM sends to the bucket as it happens (operation, key, answer, time, and whether you, the background check, a chain or an AI connection caused it) and counts each operation for today and in total. The storage form has a Provider picker (Hetzner, DigitalOcean Spaces, Amazon S3, Backblaze B2, Cloudflare R2, MinIO, other). It says whether that provider bills the requests WRM uses, and how much, quoting the provider's price page. The activity panel prices the counted requests the same way.

The AI works inside the Chains builder. The 🤖 AI button on a chain or draft takes one instruction ("add a TLS check for example.com", "why is the backup path red?"). The AI reads the chain and its last results and writes a draft. A draft that changes an existing chain says so, and the chain changes only when you press Apply changes; it keeps its id and history. Test once runs a draft's checks a single time and shows the results on the diagram, without saving anything. WRM's AI panel gets chain_get and chain_test, and chain_draft can now change a chain. The same four tools are available to MCP clients (Claude Desktop, Claude Code and others) behind the new opt-in `chains` scope.

What's new in v14.3.2

A storage can be edited and removed again. Each storage in the list has a ✎ (edit) and a 🗑 (remove) button, and the open storage has *Edit* in the toolbar; the form also has *Remove storage*. Renaming or changing permissions no longer contacts the bucket, so it also works while the endpoint is down. The background bucket check runs every 15 minutes instead of 5 (storage_check_minutes, 0 turns it off), a chain's storage check asks the bucket at most every 5 minutes instead of on every 30-second poll (chain_storage_check_s), and docs/STORAGES.md lists every S3 request WRM sends.

What's new in v14.3.1

Log reads and WRM responsiveness with Claude/MCP. A log glob such as follower.log* is no longer mistaken for a PuTTY private key; explicit .ppk files are still refused. The database pool now has headroom for parallel MCP calls and several browser tabs, and connection/folder lists load their labels in one query instead of one per row, so WRM no longer becomes unreachable until a restart.

What's new in v14.3.0

Storage folders are shown completely. The browser follows every S3 continuation token instead of stopping at the first page: it reports the running count while loading, then the total object and folder count and size with a clear "all objects in this folder are shown" line (and *Load more* above a 100-page safety limit). Search filters the whole folder, sort goes by name/size/date, and select-all, bulk delete and copy-path are available. Test connection now checks the values in the add form before saving.

The S3 share links are gone for security. The Share button, its API and the public /s3/ page were removed; links created by an older version stop working, and storage access always needs a signed-in account with the storage's permissions.

The Chains wizard works with four or more servers. Check ids are kept inside the 40-character limit and a large "all checks OK" state is nested instead of exceeding the rule limit.

What's new in v14.2.0

Chains are now built, not typed. A new guided builder picks servers from your saved connections, adds checks with a form, connects nodes (or drag from a node's connector dot, like a workflow canvas) and edits states (scenarios) without JSON. Templates and the advanced JSON editor are still there, but nothing has to start as JSON.

The AI wizard looks at the servers first. Pick servers, optionally describe the system, and WRM reads the OS, running services, Docker containers, listening ports and network/object-storage mounts (rclone, s3fs, NFS, CIFS, SSHFS) with fixed read-only checks; the assistant then drafts a chain from real service names and ports instead of invented ones. Without an AI provider the same facts build a deterministic starter.

No storage required. A chain of servers is complete on its own; discovered mounts become mount checks and, when the source names a host, an outside endpoint with a DNS check. WRM never attaches to a discovered storage, never asks for its credentials and never creates a storage entry for it.

What's new in v14.1.0

Chains: a whole system watched as one. WRM now links the servers, storages and outside endpoints that form one working system (for example ingest → transcoding → content → CDN with a primary and a backup path), checks them in the background with read-only checks over the SSH connections it already has, and shows the chain as a live diagram whose links animate with traffic and turn red when something fails. Scenarios decide the active path (primary, backup, degraded), and every change is kept in a timeline and notified. Describe the system to WRM's AI assistant: chain_status and chain_draft let it write a draft with catalog checks only; you review that draft on the same diagram and approve it before any monitoring starts. Nothing is installed on a server, and a chain can never run a command. See Chains.

What's new in v14.0.0

One combined release: Storages, its release review, and the security work of v13.14.11. Everything below arrives together when you upgrade from v13.14.10 or older; from v13.14.11 the new part is Storages. Next on the roadmap is Chains, live monitoring of a whole service chain.

Storages: S3-compatible object storage as a section of its own. Add a Hetzner, DigitalOcean Spaces, Amazon S3, MinIO or Backblaze B2 bucket (confined to a prefix), browse it, preview images, play video with a sibling subtitle track, download, and edit small text objects (JSON, configuration, subtitles) with BOM/CRLF kept and a conflict check. Uploads, writes and deletes are allowed per storage; a delete needs an explicit confirmation. A background check notifies storage.down / storage.up, and AI connections get storage_list/read/write/delete behind the opt-in scopes storage_read, storage_write and storage_delete (changes only in the automatic mode). See Storages (S3) and docs/STORAGES.md.

What's new in v13.14.11

AI connections survive WRM restarts. Claude's bridge recovers its in-memory MCP session with the saved grant, and the server list stays selected. Grant creation and OAuth consent also have Select all controls.

Share links and security checks are stronger. New share links keep bearer tokens out of request URLs; saved credentials stay bound to their connection destination; AI approvals are rechecked before execution; outbound requests and addon messages are constrained.

Pending AI approvals are harder to miss. WRM can show desktop notifications that focus the related approval.

What's new in v13.14.10

Self-update works on Windows when an antivirus scanner holds the new file. WRM waits for the lock for about 15 seconds and copies the file into place if it stays locked, instead of stopping with *being used by another process*.

What's new in v13.14.9

The original deploy tool's Git section is explained, and locks name the right computer. The original tool shows its *Git* section (pull, commit and push of deploy-config) only when deploy-config is a Git clone; a deploy-config imported as a ZIP has no Git history. Medium step 3 now says so and points to DEPLOY_CONFIG_REPO in *Original runtime settings*, whose fields show in grey what an empty field means. In the managed Docker runtime DEPLOY_HOSTNAME now defaults to the WRM computer's name instead of the container ID, so locks and deploy history name a real computer.

What's new in v13.14.1

Addon settings survive restarts, and a frozen WRM leaves a record. Since v13.9.0 every start of WRM set the addon instances aside (for example a Grafana panel's configurations), so addons came back empty after a restart or an update; v13.14.1 keeps them and restores the most recent ones with their settings and window positions. WRM also writes what it was doing to remote_manager.db.diag/ next to the database whenever it is stopped or restarted and when its own watchdog sees that it no longer answers (see Troubleshooting).

What's new in v13.14.0

The Git workspace checks only what Git tracks, folders sort themselves, and every file edit is on record. The Git overview names servers by their hostname or connection name instead of an IP. A check compares only the files the catalog tracks: logs and other files outside the check are listed as *outside the check* and never compared, and the .gitignore helper has a Logs group. Every Git filter can na