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: v13.14.1 · Download · Release notes · Changelog · Security · Architecture
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 narrow to a folder on the servers (a tree with counts, like the log viewer's folder filter), and the connection-folder filter includes subfolders. Right-click a folder to sort its subfolders A–Z or keep them sorted (#134). Admin → File edits keeps every file edit with its diff, from the editor and from the AI, filterable by user, server, session and AI (#129). SSH keys can log in with an OpenSSH user certificate, also the short-lived ones from opkssh (#119). See Connections & folders, SSH user certificates and opkssh, File edit history and Git workspace: every file and partial checks.
What's new in v13.13.1
Adding the WRM PRO marketplace in the Claude app. Enter the repository in lowercase, vedranius/web-browser-rdm-public: the Claude app names the marketplace after the repository, and GitHub accepts the name in any case. If the app still says only Failed to add marketplace, Troubleshooting says what to check and where its log keeps the reason; Upload plugin with claude-plugin-wrm-pro.zip from the release installs the same plugin.
What's new in v13.13.0
The WRM PRO plugin installs from the Claude app with one pick, and one script connects every AI app. The plugin needs no settings any more: it carries the WRM bridge, and the first /wrm-pro:wrm asks for the WRM address and opens WRM in the browser, where you sign in and approve; the token goes straight to your computer, never into the chat. /wrm-pro:wrm then lists your servers and everything WRM can do. Before, the plugin depended on settings the Claude app cannot ask for, and its HTTP connector would have connected from the cloud, which cannot reach a WRM on your own network. Settings → AI connections → 🧰 All AI apps at once downloads one script (Windows or Linux/macOS) that signs in once and adds WRM to Claude Code, the Claude app, Codex, Gemini CLI, VS Code, Cursor, Windsurf and OpenCode. Releases carry claude-plugin-wrm-pro.zip for Customize → Plugins → Upload plugin. See AI desktop apps (MCP).
What's new in v13.12.0
Tools for writing addons, also with an AI. wrm -addon-lint ./my-addon checks an addon before you install it: the manifest against its schema, every file, and the code for what the sandbox would refuse (remote scripts, inline handlers, eval, fetch, localStorage, tokens in the ZIP, sites missing from http.origins, a panel that never says ready). Every finding has a code, the file, the line and a hint, so an AI can fix its own addon; -addon-lint-json gives the same as JSON, and a failed install in Settings → Addons opens the report by itself. wrm -addon-new grafana-panel ./my-addon starts from one of four templates (blank, fetch-and-render, grafana-panel, wasm-hook) that come with wrm-bridge.js, a small helper for the bridge. wrm -addon-dev ./my-addon opens the panel on your computer with the real sandbox and CSP, a stand-in for WRM (settings, web requests, secrets from environment variables) and a reload whenever a file changes. WRM also serves the manifest schema and an llms.txt guide for AI assistants. See Addons and the addon developer guide.
What's new in v13.11.0
Addons can reach web sites, through WRM and only where an administrator said yes. An addon now lists the sites it needs in addon.json (for example https://grafana.example.com, with the methods and paths it uses). WRM makes the request on the panel's behalf, so the panel itself still has no network: anything not listed is refused, every name is resolved by WRM and private or local addresses are blocked unless the administrator ticked private network for that site, and redirects are checked again. API keys and passwords for those sites are secrets that you type into WRM (🔑 Secrets on the instance): per instance, with your own value in a shared instance if you need one. They are stored encrypted, added to the request by WRM and never shown to the panel. A personal addon's sites wait for an administrator's approval. Recent requests are listed in the window's diagnostics. See Addons and the addon developer guide.
What's new in v13.10.0
Saved logins on demand, hostname names and a calmer top bar. Edit connection has 👁 Show saved login: after you confirm with your WRM password (or your domain password), WRM shows what the connection logs in with. Right-click a connection for Copy username, Copy password (same confirmation) and Copy IP address. A new connection can take its name from the server's hostname. Tabs show just the connection's name, the version next to the logo stays visible, the user name no longer jumps every 5 seconds, and the Git workspace server filter has no blank entries any more. See Connections & folders.
What's new in v13.9.0
Addon platform v2: your own addons, several windows each, and settings that stay. Every user can now install personal addons that only they see (an administrator decides who may with addon_personal and can turn any of them off). An addon with a panel opens as instances, each with its own settings and window, for example two dashboards side by side; administrators can set up shared instances for everybody. Settings are kept on the WRM server with export and import, and windows come back where you left them after a reload or on another device. Addon themes appear in Settings → Appearance for whoever picks them. Before an addon is enabled WRM shows a permission sheet generated from addon.json; an update that asks for more waits for approval again. apiVersion 2 panels run without any network of their own, every file is pinned by SHA-256, and a watchdog offers Reload when a panel hangs. See Addons and the addon developer guide.
What's new in v13.8.0
AI sessions, your own AI settings and approvals that do what they say. The new 🧠 AI sessions panel lists every AI session you had, from the assistant, the log and file assistants, OpenCode agents and AI apps over MCP, with search (also in the conversation), filters, a transcript viewer, Continue (also an MCP session, whose steps become the earlier context), Save (kept beyond the transcript retention) and export to Markdown or JSON. Everybody sees only their own sessions. ⚙ My AI settings in the assistant keep your own default provider (your own key, e.g. your OpenAI or Anthropic account), model, mode, engine and whether you see the model's thinking. Over MCP an approval given in WRM after the AI app stopped waiting now runs the call at once (ai_mcp_later_approval), Deny in the AI app is final, an app's open question is closed when you decide in WRM, and deciding a request that is no longer waiting says who decided it and where. The work log keeps the whole thinking text instead of its last lines. See AI sessions and AI desktop apps (MCP).
What's new in v13.7.0
Themes, accessibility and a screen lock you can rely on. Settings → Appearance offers eleven themes (dark, OLED black, Fjord, Solar, Forest, Ember, light Daylight, Paper, Solar light and two high-contrast themes), follows the system's light/dark setting if you want, and lets you change every colour, the fonts, the interface size, corners and spacing, save your own themes, export and import them, and add your own CSS. Themes from addons are picked there per user instead of being forced on everyone. For colour vision deficiency (deuteranopia, protanopia, tritanopia, achromatopsia) WRM switches status colours, diffs and optionally the terminal palette to colours you can tell apart, can add ✓ ✕ ! signs and shapes so nothing relies on colour alone, and offers more contrast, a terminal minimum contrast, reduced motion and transparency and a strong focus outline. Settings → Security → Screen lock sets when WRM locks (inactivity with a warning, a hidden window, the computer locking or sleeping, on every start, a keyboard shortcut) and how the lock screen looks; Lock now locks at once while terminals, transfers, tunnels, AI and MCP keep running. The lock is now kept by the server: a reload or a new tab stays locked, directory (LDAP) accounts can unlock, and a personal PIN can unlock instead of the password. See Appearance, themes and accessibility and Screen lock.
What's new in v13.6.0
Log folders, a folder tree and smarter operators. Monitoring → Logs can show the logs as a folder tree under their main folders (/var/log, /home/scripts …) and has a Folder filter for one folder and everything below it; Log settings take your own main folders. Operators are recognised from words that repeat in folder and service names (nova, NOVA2, novatv → one operator group), and every log says whether it sits in a log folder or an app folder. A log folder and a script folder with the same name (different case) no longer hide each other's logs. See Logs: viewer, search and log settings.
What's new in v13.5.0
A professional log viewer, a smart editor and an AI that shows its work. Monitoring → Logs lists every log of a server in about a second (one read-only SSH command), sortable and filterable by operator and service, and never lists scripts such as .py. Logs open in tabs with level colours, smart highlighting, find, level filters and Follow; the Search tab greps all selected logs on the server for a From/To range in the EU date format and sorts the hits on a timeline. Log settings are now separate from Zabbix. The file manager's editor highlights syntax, finds and replaces, shows your changes before saving, warns when the file changed on the server and has an AI assistant that reviews and edits the open file with your approval. The log viewer has an AI log assistant (search_logs). The AI work log shows the assistant's thinking and each step, chats get a short title with date and time, and an ended chat can be continued. See Logs: viewer, search and log settings, Text editor and AI assistant.
v13.0.0 to v13.4.4 (log engine, addons, screen lock, OpenCode Go, Claude quick start, Claude Desktop and Claude Code setup) are described in the changelog.
What's new in v12.9.1
Medium runs without the original tool. The WRM engine is now the default for projects nobody chose an engine for, its card comes first on the Medium page, and the original deploy tool with its Docker runtime is folded away as optional. Upgraded installations that already use the original tool keep it as their default until an administrator switches Medium: default engine to native. The deploy-config editor can now pull the configuration from its Git repository, show your local changes and Commit and push them through the WRM Git source, after checking that the whole configuration loads. WRM-host builds can run as an unprivileged account (medium_build_user) with a clean environment.
What's new in v12.9.0
Medium shows what changes in each file and lets you edit deploy-config. In the WRM engine's plan, Details opens the server's version of a changed file against the branch, line by line. Files that differ only in CRLF/LF are marked line endings only and counted separately, as in the original tool. Edit deploy-config edits servers.yaml, environments.yaml and the project files in WRM: a file is saved only when the whole configuration still loads, and comments, layout and line endings stay as you wrote them.
What's new in v12.8.1
Security update without a database change. The build toolchain is now Go 1.27.3, which fixes GO-2026-6809 / CVE-2026-111943: crypto/x509 now rejects known compromised intermediate certificates that an older system trust store may still contain. The gosec G702 finding in the OpenCode Docker sandbox was reviewed and accepted as a false positive: the Docker path is operator-configured and the container name is generated by WRM, both passed as separate arguments without a shell. See the release notes for the provenance of both findings.
What's new in v12.8.0
Folders now behave like a proper remote manager. Deleting a folder removes its subfolders and every connection inside in one step, without moving anything to the root first. Folders and connections can be moved from the context menu or dragged, including several selected connections at once, and the new position is saved. Shared and collaboration trees keep their nested folder structure; connection names sort case-insensitively, while folders keep their manual order.
Every reported detail is covered. The Settings window opens at the size of the Admin window and wide tab rows have scroll arrows. Terminal windows have Edit and Tunnels buttons in the title bar. The file manager can change permissions (including recursively and with an optional sudo password), and the transfer destination can create a folder. Additional uploads can be queued while one is running. Tunnels can be filtered by port, description or host, with an active-only switch, and proxy settings are reachable from Tools and the Tunnels panel. Save buttons show progress and reject a second click, and + Connection on a folder is pre-filled with that folder and its defaults.
What's new in v12.7.4
RDP works on Windows without preparing guacd by hand. When guacd does not answer and its address is local (127.0.0.1:4822), WRM starts the official guacamole/guacd:1.5.5 container in Docker Desktop, publishes it on loopback only, and keeps it running with Docker (wrm-guacd, unless-stopped). The first RDP/VNC/Telnet connection can start it; later starts happen with WRM. Admin → Overview shows the state and has Start guacd, -setup-guacd does the same from the command line, and the desktop window explains when Docker Desktop is missing or stopped. A custom guacd on another machine is never touched. Linux keeps using its system guacd or the docker-compose.yml service.
Every text file previews with its formatting. Preview now detects text from the file content, so shell/Python scripts, XML/SMIL, JSON, YAML, configuration files and extensionless files open as text instead of being refused. A bundled offline PrismJS highlighter colors the formats it knows; binary files still get the clear answer to download them. The 256 KiB preview limit and escaped-text safety policy are unchanged.
What's new in v12.7.3
Medium builds where you choose. Projects with a build step can now deploy with the WRM native engine. For each project, choose where the build runs: on the WRM host, on a chosen Linux build server over SSH, or not at all. The plan shows the place and the build's platform and architecture before anything runs; a destination with a different platform or architecture is refused with the reason. A build server receives only the prepared source in a temporary directory (no Git metadata and no SSH keys), and the directory is removed afterwards.
Monitoring → Logs finds every service. Service logs are now discovered under /home/<operator>/<operator>/<service>/log and /logs, with the correct Service and Operator labels. Non-compressed service logs, including FTP .txt files, are listed; virtual environments, build/archive directories and old backups are skipped. Discovery and listing have larger time budgets, so large hosts no longer show incomplete results.
What's new in v12.7.2
The version is read from the code. The Git workspace no longer trusts VERSION.md to say what is deployed. It compares every tracked file on the server with the repository tree at the target and at the earlier tags: all files matching one version show that version, a consistent older version is named exactly from its commit tree, and a mix or a hand-edited file shows Mixed / modified with the per-file details. A new checkbox next to Check now (off by default) also checks VERSION.md and warns when it disagrees. See Git workspace: every file and partial checks.
What's new in v12.7.1
Medium: per-environment server lists. environments.yaml now accepts the original deploy tool's servers: [name, ...] key, so an environment can be limited to chosen servers. A project target in that environment cannot deploy to any other server; an unknown, duplicate or empty list is refused with the file and key named. Existing configs without the key keep every server. See Medium native engine.
What's new in v12.7.0
Medium deploys natively. Switch a Medium project to the WRM native engine and WRM deploys it itself, from your WRM Git source to every server of the environment through your saved WRM connections, without Docker and without the original tool. Each server gets a lock, a backup of everything that changes, a SHA-256 check of every uploaded file, post_deploy and a history entry, all in the original tool's format, so both engines can take turns on the same servers and roll back each other's deployments. A dry run compares again under the lock and changes nothing; changes can be left out of a deployment; History and rollback shows what runs where, rolls back the last deployment and releases a lock someone left behind. Projects with a build step gained native builds in v12.7.3. See Medium native engine.
What's new in v12.6.26
SIEM export, security alerts and lockdown. WRM sends every audit entry to your SIEM: syslog over TLS (RFC 5424), a JSON lines file, Splunk HEC, Elastic, Microsoft Sentinel or any HTTPS collector, with user, role, directory identity, source address and the audit hash chain, and catches up after an outage. The admin sees per destination whether it delivers and what is waiting. Security alerts tell administrators about repeated failed sign-ins, break-glass sign-ins, new administrators, revealed secrets, AI full-access approvals and the audit being turned off. Stop user ends everything an account has open in one click, and lockdown keeps everyone except break-glass administrators out, switches AI off and pauses shares, from the UI, wrm -lockdown or WRM_LOCKDOWN=1. See SIEM export, alerts and lockdown.
What's new in v12.6.25
Active Directory, LDAP and SCIM. People sign in with their Active Directory or LDAP name and password on the normal sign-in page; WRM checks the password with the directory over LDAPS or StartTLS and never stores it. Rules turn directory groups (nested AD groups included) into WRM roles and teams, and WRM checks every linked account regularly: someone deleted, disabled, locked or removed from the WRM groups loses access at once. SCIM 2.0 lets Microsoft Entra ID or Okta create, change and disable WRM accounts and groups immediately. Whichever way an account is stopped, WRM ends its sessions, terminals, tunnels, rooms, AI sessions and AI connections. See LDAP / Active Directory and SCIM.
What's new in v12.6.24
Sign in with your organisation's account. WRM now signs people in through Microsoft Entra ID, ADFS, Okta, Keycloak, Google Workspace or any OpenID Connect provider (authorization code with PKCE). In Admin panel → Directory sign-in you add the provider, test the connection step by step, and write rules: an Entra app role or a group ID gives a WRM role and teams. Accounts are created on the first sign-in only for people a rule matches; everyone else is refused with a message that says why. People are recognised by their immutable directory ID, never by their name, so a renamed or re-used name cannot take over an account. A provider can require MFA proven by the token. WRM checks regularly with the provider that each signed-in user may still sign in: someone disabled or removed from the WRM group loses their sessions and terminals. Password sign-in can be limited to the break-glass administrators (the Enterprise level requires it once a directory sign-in is on). Test sign-in shows what the provider sends and what WRM would do, without creating anything. See Directory sign-in (OIDC).
What's new in v12.6.23
Roles, teams and a second confirmation for risky actions. Every account now has a role: Administrator, Security auditor (reads the audit log, terminal sessions, recordings, file transfers and the security posture, and changes nothing), Operator or User. Administrators create teams in Admin panel → Teams; a share can include a whole team with one role, and policies that say who may use a feature accept operators and teams:<names> besides off / admins / all. With step-up on (required from the Business level), changing policies, roles, the security level, deleting or disabling users, resetting passwords or 2FA and revealing stored secrets ask for your password (and 2FA code) again. A break-glass administrator account must use 2FA, can be limited to chosen networks, and every sign-in is audited and sent to the other administrators. When you delete a user, their connections, folders, credentials, keys, shares and proxies can pass to their team lead or another account instead of being deleted. See Roles, teams, step-up and break-glass.
What's new in v12.6.22
Security levels: Home, Business, Enterprise. Pick how strict WRM is on the first-run screen, at install (-security-level, WRM_INITIAL_SECURITY_LEVEL, forced with WRM_SECURITY_LEVEL) or later in Admin panel → Security. A level sets minimums for HTTPS, two-factor authentication, passwords, sessions, registration, host keys, secret export, guest links, AI full access, audit and session recording. Before you switch, a preview shows every change, what blocks it and whom it affects; a setting you keep below the level is a deviation with a written reason, on record and audited. The security posture page grades the installation item by item with the exact fix, and exports a report for auditors (JSON or PDF). See Security levels and posture.
What's new in v12.6.21
Signed releases. Every release from now on carries an ed25519 signature of its SHA256SUMS.txt, a software bill of materials (CycloneDX) and GitHub build provenance. Once the project's public key is built in, the one-click update refuses a release whose signature is missing or wrong, so a changed file on the release page cannot be installed. wrm -release-verify SHA256SUMS.txt checks a download by hand. Every night, fuzz tests feed random input to the import parsers (mRemoteNG, SSH config, CSV/XLSX, PuTTY, WinSCP, configuration files, deploy-config YAML) and OWASP ZAP scans a running WRM, signed out and as an administrator. The fuzz tests already found and fixed a crash in the PuTTY import.
What's new in v12.6.20
Security checked on every change. WRM is now built with a supported Go release (1.27) and up-to-date libraries, and every push and pull request runs automatic security checks: known vulnerabilities in Go and the libraries WRM uses (govulncheck), GitHub CodeQL for the server and the web UI, gosec and staticcheck, secret scanning (gitleaks), checks of the build workflows themselves, a dependency review, a vulnerability scan of the Docker image and the OpenSSF Scorecard. Dependabot proposes library updates every week, and Claude can review pull requests for security problems. The Medium proxy uses Go's safer Rewrite hook. No change for users; see Continuous security checks and the security roadmap (signed releases, security levels for home, business and enterprise, roles and teams, sign-in with Microsoft Entra ID / AD, LDAP and SCIM, SIEM export).
What's new in v12.6.11
OpenCode inside WRM. Add the OpenCode Zen provider and use OpenCode's free models in the AI assistant without an account, or paste an OpenCode account's Zen key for all its models. A Go subscription has its own OpenCode Go provider, so a Go key is sent to Go's endpoints instead of Zen. Choose OpenCode agent as the assistant's engine (agents build and plan): WRM downloads OpenCode itself after one click by an administrator (sha512 checked) and runs it on the WRM host with its own shell, file and web tools switched off, so it works on your servers only through WRM and every command still waits for your approval. The assistant can also hand text jobs to helper models, picked automatically by the kind of job (free first), each labelled with how it treats your data; models that may train on prompts stay off until you switch them on. See OpenCode Zen, Go, agents and helper models.
What's new in v12.6.10
One canvas, arranged your way. The window area is one canvas: terminals, file managers, desktops, Workboard addons and panels share it. Addons are windows you move, resize, snap, pin or dock; panels can be placed anywhere on the canvas, not only at the edges. The ▤ Workboard menu adds addons and holds the canvas tools: grid, tile and cascade, lock, saved layouts (optionally with your terminals) and export / import. New addons: links, saved sessions and a timer. The top bar is tidier: Broadcast is in 🧰 Tools, Shares is an icon, and Settings · Panels · Workboard sit together. A closed terminal's banner has a ✕ Close window button. See Workboard: the shared canvas and addons.
What's new in v12.6.9
Workboard: what matters, at a glance. ▤ Workboard in the top bar opens a page of tiles you put together yourself from an addon catalog, so nothing appears until you add it: server status, CPU / RAM / disk bars of chosen servers (from Monitoring, or read over SSH), WRM's notifications inside WRM, clocks for your time zones, the last commits of a Git service, running tunnels, quick connect buttons and notes. Any tile can be pulled out into a panel and docked, stacked or floated like the other panels. See Workboard and addons.
What's new in v12.6.8
Your panels, where you want them. Connections, Sessions, Snippets, Clipboard and the AI live view are panels with a tab you can drag: onto another panel's tab bar to stack them as tabs, onto the top or bottom part of a panel to split the column, onto an edge strip to dock it left, right or under the windows, or anywhere else to let it float. Panels (▦) in the top bar shows and hides them, and Lock the layout keeps everything in place. The layout is stored for your account on the server, so it follows you to every browser. See Panel layout.
What's new in v12.6.7
A top bar that fits and an AI panel that docks. The top bar now fits at any width and browser zoom: labels go first, then less used buttons move into a ⋯ menu, so nothing overlaps. The AI live view (what an AI app runs on your servers, with approvals and output) no longer covers your windows: it is a 🤖 AI tab next to Sessions and Snippets, a dock under the windows, a floating window, or hidden, chosen with its title bar buttons or by dragging it to an edge, and remembered per user. Approval cards still always pop up. See AI desktop apps (MCP). Every text on the page can be selected and copied again, and Medium's Docker runtime trusts your computer's certificates, so it works behind proxies and antivirus that inspect HTTPS (see Docker for Medium).
What's new in v12.6.6
Docker everywhere, installed by WRM. The original deploy tool now runs in WRM's managed Docker runtime on Linux, macOS and Windows alike, and WRM installs Docker itself when it is missing: an administrator presses Install Docker in Medium step 2 once (accepting Docker Desktop's licence on Windows and macOS), and WRM installs Docker Engine from the Linux distribution's packages or Docker Desktop from docker.com (signature checked), starts it, waits for it and prepares the runtime, every step with its output in the activity log. Afterwards a tool ZIP import does all of it by itself. Where WRM has no administrator rights it shows the one command to run, sudo wrm -setup-docker. See Docker for Medium.
What's new in v12.6.5
Medium tells you what it is doing. The Medium view now has a numbered step-by-step guide for the original deploy tool (1 import the tool ZIP, 2 prepare its runtime, 3 your deploy-config, 4 your SSH profile, 5 start/stop), each with a light, what it waits for and what to do when it fails. While something runs you see what runs, who started it, since when and every step with its time, with the output of Docker, pip and the original tool (secrets redacted). A deploy-config ZIP is checked by WRM at once and kept for the next start while the runtime is still being prepared, so you no longer wait to upload it. A new activity log lists every Medium action with its result, duration, steps and output, and WRM's console logs each step. The read-only WRM preview is a separate, clearly labelled panel. See Medium step by step.
What's new in v12.6.4
Your blocked commands, your choice. With full access on, the administrator now decides whether their own list of blocked commands (ai_blocked_commands) asks for approval like everything else (default) or stays blocked even with full access (ai_full_access_blocked, Admin panel → AI connections). See AI desktop apps (MCP).
What's new in v12.6.3
Full access with one switch. The administrator now chooses how full access applies (ai_full_access_mode): by default the Full access for the AI switch alone opens it for every AI session; it can instead apply only to AI connections with the ⚠ Full access scope, or to users who turn it on for themselves in Settings → AI connections. Claude still asks before anything WRM would otherwise refuse. See AI desktop apps (MCP).
What's new in v12.6.2
Full access, but Claude still asks. When an administrator allows it (ai_full_access), an AI connection can get the ⚠ Full access scope. WRM then refuses nothing outright: destructive and blocked commands, deny lists, shutdown and secret files come to you as an approval marked FULL ACCESS, every time and never automatically. Read-only connections stay read-only. See AI desktop apps (MCP).
What's new in v12.6.1
"Allow everything" now means everything. In an AI connection's automatic mode, Allow everything fills in * for commands and /** for files, and No time or action limit keeps the connection automatic for as long as it is valid. Chains with &&, variables and redirections no longer stop at an approval when * is allowed; blocked commands, your deny lists and sensitive files still do. When WRM does ask and nobody answers in time (or the app declines the question), the request stays in WRM to approve later, and the AI repeats it once you have. Files that may hold secrets are read after your approval, with secrets redacted. See AI desktop apps (MCP).
What's new in v12.6.0
Medium's native engine, first step. The Medium view has a read-only Native engine panel: WRM reads your deploy-config as it is, matches its servers to your saved WRM connections, prepares the chosen branch or tag from your WRM Git source and shows what a deployment would change on each server, without Docker and without writing anything. Compare with the original tool runs the original comparison next to it and shows whether both give the same result. Deploying natively and rollback followed in v12.7.0. See Medium native engine.
What's new in v12.5.1
Claude Desktop and Claude Code in one step. Settings → AI connections → Claude Desktop now downloads a WRM PRO extension (wrm-pro.mcpb) with your WRM address and token already filled in: open it, press Install, done. It works with a WRM on your own network and over plain HTTP, because Claude Desktop talks to WRM from your computer (a claude.ai custom connector connects from Anthropic's cloud and needs a public HTTPS address). For Claude Code there is a WRM PRO plugin: claude plugin install wrm-pro --marketplace vedranius/web-browser-RDM-public --config wrm_url=… --config wrm_token=…. Token lifetimes are entered in hours or days and default to 7 days (at most 30), so you are not asked to approve again every day. While an AI app works on a server, a live panel in WRM shows each command, the approval buttons and the output; after a denial the AI asks you how to go on. See AI desktop apps (MCP).
What's new in v12.5.0
Stamp as it is: the Stamp dialog shows which files differ and why an installation cannot be stamped. Tick Also stamp installations that are not up to date to write VERSION.md with each file's actual version and a note that the installation is partial.
Back in dialogs: dialogs opened from another dialog (for example Details → Update → confirmation) have ← Back (Alt+←) and keep what you ticked or typed. A code review of the v12.4.x features fixed production confirmations, Medium start/stop/settings and imports, log search with non-UTF-8 bytes and special characters, and the client GitLab cache. The next versions run Medium without Docker on WRM's own engine (roadmap).
What's new in v12.4.5
Medium: select the trusted tool/config ZIPs and click Prepare and run. WRM retains the imports, starts Docker, prepares the original dependencies, validates config, synchronizes the private profile and opens the unchanged original tool. First Windows setup can invoke the signed official Docker installer; OS/vendor prompts and required restarts remain visible. Existing custom configuration Git settings are replaced by the explicitly uploaded local config ZIP.
Monitoring → Logs: discovery starts automatically and streams results by server. Service log folders and Supervisor paths supplement manual roots. Filter by server/operator/service and event time, then search a keyword across all matching files from their beginning. Results show file modification time, matching event range, highlighted excerpts and open/follow actions. Progress, permission errors and partial searches remain visible; continue a bounded scan when necessary. Host metrics, service checks and SSH logs have separate setup requirements.
Overview/Installations keep filters, check controls and actions together while scrolling. Environments adds combined search/service/environment/server filters.
Operation and limits · Validation.
What's new in v12.4.4
Monitoring with Zabbix metrics/history and service Functionality, multi-window logs, client GitLab token access with persistent snapshots, easier MCP setup and editable grants, structured configuration inventory, terminal selection-to-AI/Open terminal here, visual folder/connection labels, longer provider timeouts, sticky filters and replay/import fixes.
Operation and limits · Release validation · Original Medium tool parity. General configuration import now recognizes mRemoteNG XML and PuTTY registry files (#5).
📜 License: free for personal use and as a work tool in companies
WRM is source-available. You may use it under the PolyForm Noncommercial License 1.0.0 or the PolyForm Internal Use License 1.0.0, whichever fits.
Copyright © 2026 vedranius. Third-party libraries keep their own licenses.
☕ Support the project
WRM is built in my spare time. If it saves you time, you can buy me a coffee:
https://ko-fi.com/vedranius. Thank you! ❤️
Table of contents
- What WRM is
- Quick start
- Upgrading from v13.14.0 · from v13.13.1 · from v13.13.0 · from v13.12.0 · from v13.11.0 · from v13.10.0 · from v13.9.0 · from v13.8.0 · from v13.7.0 · from v13.6.0 · from v13.5.0 · from v13.4.4 · from v12.9.0 · from v12.8.1 · from v12.7.1 · from v12.7.0 · from v12.6.26 · from v12.6.25 · from v12.6.24 · from v12.6.23 · from v12.6.22 · from v12.6.21 · from v12.6.20 · from v12.6.19 · from v12.6.11 · from v12.6.10 · from v12.6.9 · from v12.6.8 · from v12.6.7 · from v12.6.6 · from v12.6.5 · from v12.6.4 · from v12.6.3 · from v12.6.2 · from v12.6.1 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
What WRM is
WRM is a single executable with a built-in web server and a built-in web app. You start it on any machine: your PC, a Raspberry Pi, a VPS or a company server. Then you open it in a browser and manage your remote servers from there:
- SSH terminals in the browser (xterm.js, 256 colors, full-screen apps like
nano,vim,htop,mc), with snippets (saved commands with variables, one click or Ctrl+Shift+Space), run on connect (sudo -i,cd /srv/app…) and broadcast input (type into many terminals at once, with a safety check for dangerous commands). - Live up/down status of every saved connection in the sidebar, with latency, server banner and a notification when a server goes down.
- Quick connect — type
[email protected]:22(orrdp://…,vnc://…) and connect without saving; notes & runbooks per connection (procedures, contacts, links); network tools — port check, ping, traceroute, DNS and HTTP/TLS check from the WRM server or from any of your servers ("can app-01 reach the database on 5432?"). - Out-of-band management — power on/off/restart, health and inventory through the server's BMC (iDRAC, iLO, XClarity, Supermicro, OpenBMC via Redfish, or IPMI), and its serial console (BMC SSH or IPMI Serial-over-LAN) in a terminal window; serial ports of the WRM machine for switch and router consoles.
- Remote desktops — RDP (Windows), VNC and Telnet in a browser window, also behind jump hosts, with clipboard, Ctrl+Alt+Del, recording and replay (through guacd, the Apache Guacamole proxy).
- File manager for SFTP (over SSH), FTP and FTPS: browse, upload, download, rename, delete, edit, search.
- SSH keys & credentials vault: generate SSH keys, put them on many servers at once (like
ssh-copy-id), see who has access to a server; one shared login such asroot@dc1for many connections, shared with colleagues without revealing it, with password rotation on all its servers. - Jump hosts (like
ssh -J): reach servers behind a bastion, also in chains — for terminals, files, transfers and tunnels. Proxies (SOCKS5/4, HTTP CONNECT) as a connection setting, like in PuTTY, also combined with jump hosts; folder defaults for the jump host and proxy of everything in a folder.
Everything is stored in one local SQLite file. There is no external database, no Docker requirement, no CDN and no cloud account: the binary also serves all scripts and fonts, so WRM works in closed networks.
Supported platforms (prebuilt binaries): Linux (x86-64, arm64, ARMv7/Raspberry Pi, ARMv6, 32-bit), Windows (x86-64, arm64), macOS (Intel, Apple Silicon, Universal), Android arm64 (Termux), FreeBSD (x86-64, arm64), OpenBSD (x86-64).
Quick start
-
Download the binary for your system from Releases and optionally verify it: put
SHA256SUMS.txtandSHA256SUMS.txt.signext to it and runwrm-pro-… -release-verify SHA256SUMS.txt(signature and SHA-256), or compare the SHA-256 yourself.gh attestation verify <file> --repo vedranius/web-browser-RDM-publicshows which workflow and commit built it. -
Run it:
Linux / macOS / FreeBSD / OpenBSD
chmod +x wrm-pro-v13.14.1-linux-amd64 ./wrm-pro-v13.14.1-linux-amd64On macOS, if Gatekeeper blocks the file:
xattr -d com.apple.quarantine wrm-pro-*-darwin-*.Windows (PowerShell), or just double-click the
.exe:.\wrm-pro-v13.14.1-windows-amd64.exeLinux AppImage (x86_64 / ARM64)
chmod +x wrm-pro-v13.14.1-linux-amd64.AppImage ./wrm-pro-v13.14.1-linux-amd64.AppImage # On ARM64 use wrm-pro-v13.14.1-linux-arm64.AppImage instead.Open http://localhost:8080. The AppImage runs in a terminal and binds to localhost by default; use
PORTorLISTEN_ADDRto change that. Stop it with Ctrl+C. If FUSE is unavailable, run with--appimage-extract-and-run.Data is stored in
${XDG_DATA_HOME:-$HOME/.local/share}/wrm-pro/, or at your explicitDB_PATH. Replace the AppImage to upgrade; the data and encryption key stay in place. For a boot service use the standalone Linux binary with-install-service.Android (Termux)
pkg install wget wget https://github.com/vedranius/web-browser-RDM-public/releases/download/v13.14.1/wrm-pro-v13.14.1-android-arm64 chmod +x wrm-pro-v13.14.1-android-arm64 && ./wrm-pro-v13.14.1-android-arm64Docker
git clone https://github.com/vedranius/web-browser-RDM-public.git && cd web-browser-RDM-public docker compose up -d # https://<host>:8080 (self-signed certificate)See Docker for details.
-
Open http://localhost:8080 (or ). For voice calls from other computers use HTTPS — the quickest way is (see ).
On the first start WRM creates, next to the database:
Locked out? ./wrm-pro-… -reset-password admin prints a new temporary password (add -reset-2fa to also turn off two-factor authentication).
Upgrading from v13.14.0
Replace the executable/AppImage/container and keep the database and encryption key. No new tables or columns. On the first start, when addon_instances is empty, WRM copies the rows of the newest non-empty addon_instances_old_<time> table (left there by the start-up bug of v13.9.0–v13.14.0) back with their ids and logs Addon instances: restored …; the old copies are kept and can be dropped by hand once the addons look right. WRM now creates the folder <DB_PATH>.diag/ (goroutine dumps, newest 20 kept) on every stop and restart.
Upgrading from v13.13.1
From v13.13.0, also read the next section. Replace the executable/AppImage/container and keep the database and encryption key. Additive migration: a new table file_edits (append-only like the audit log, kept for audit_retention_days) and new columns folders.auto_sort and ssh_keys.certificate; a previous version still starts on the database. New settings file_edit_history (1) and file_edit_max_kb (1024). New endpoints GET / POST /api/folders/sort and GET /api/admin/file-edits[/{id}]; PUT /api/keys/{id} also takes certificate. Git checks no longer compare files the catalog does not track: their state is outside the check instead of same / differs, and log files (*.log, *.log.*, files below a log or logs folder) are never compared nor deployed unless the catalog's include list names them. A key file on the WRM server with a <key>-cert.pub next to it now logs in with that certificate first.
Upgrading from v13.13.0
Replace the executable/AppImage/container and keep the database and encryption key. No database change; a previous version still starts on the database. The WRM PRO Claude plugin is now 1.2.1 (icon path only). If adding the marketplace failed in the Claude app, add it again with the lowercase repository name vedranius/web-browser-rdm-public.
Upgrading from v13.12.0
Replace the executable/AppImage/container and keep the database and encryption key. No database change; a previous version still starts on the database. New endpoint POST /api/mcp/setup-all (audited as mcp.setup_script). The WRM PRO Claude plugin 1.2.0 no longer has the settings wrm_url and wrm_token: after updating the plugin, run /wrm-pro:wrm (or /wrm-pro:connect) once and approve the sign-in in the browser; drop --config from scripts that install it. A Claude Desktop extension downloaded from this version keeps running when its token is refused and offers wrm_connect.
Upgrading from v13.11.0
Replace the executable/AppImage/container and keep the database and encryption key. No database change; a previous version still starts on the database. New command-line options -addon-lint, -addon-lint-json, -addon-new, -addon-id, -addon-dev, -addon-dev-port and -addon-dev-private, and new endpoints under /api/addons/dev/. The addon ids dev, install, drafts, community and users are now reserved; an installed addon with one of those ids keeps working but cannot be installed again under that id.
Upgrading from v13.10.0
Replace the executable/AppImage/container and keep the database and encryption key. Additive migration: new tables addon_http_grants, addon_secrets and addon_http_log; a previous version still starts on the database (it ignores them, and addons with an http block were not installable there). New policy addon_http (all): who may use addons that reach web sites (off, admins, all). Existing addons are unchanged; an addon gets network access only after an update that declares http and a new approval.
Upgrading from v13.9.0
Replace the executable/AppImage/container and keep the database and encryption key. No database change; a previous version still starts on the database. Git workspace installations whose connection was deleted are no longer listed, and deleting a connection now removes its installations. Show saved login and Copy password follow the existing Allow export of passwords & keys policy (allow_secret_export, on by default; administrators always can) and the step-up policy.
Upgrading from v13.8.0
Replace the executable/AppImage/container and keep the database and encryption key. Additive migration: new tables addons_personal, addon_instances, addon_store and addon_windows and new columns files, approved and pending in addons; a previous version still starts on the database (it ignores personal addons, instances and stored values). Installed addons keep working; their files are pinned by SHA-256 the next time they are installed. New policy addon_personal (all): set it to admins or off if users must not install their own addons.
Upgrading from v13.7.0
Replace the executable/AppImage/container and keep the database and encryption key. Additive migration: a new column saved in ai_sessions and an index; a previous version still starts on the database. New settings ai_mcp_later_approval (run: an approval given in WRM after the AI app stopped waiting runs the call at once; repeat keeps the earlier behaviour, where the AI must repeat the call) and ai_keep_saved_sessions (1). Deny in an AI app's approval question is now a final denial; closing the question without an answer still keeps the request in WRM. New endpoints: GET /api/ai/sessions?view=all, POST /api/ai/sessions/{id}/save, GET /api/ai/sessions/{id}/export, and the key ai of /api/me/ui/{key}. A decision on a request that is no longer waiting answers 409 with decided.
Upgrading from v13.6.0
Replace the executable/AppImage/container and keep the database and encryption key. Additive migration: new columns locked_at and lock_failures in auth_sessions and lock_pin_hash in users; a previous version still starts on the database. New settings screen_lock_mode (server), screen_lock_max_minutes (0), screen_lock_pin (1), screen_lock_max_failures (0), appearance_default_theme (graphite) and appearance_custom_css (1); the Business and Enterprise security levels require screen_lock_mode=server and an idle lock of at most 30 / 15 minutes, and Enterprise turns the PIN off. Two behaviour changes: a locked browser session can no longer reach the API until it is unlocked (set screen_lock_mode to remember or browser for the looser behaviour), and a colour theme from an addon is no longer applied to everyone: each user picks it in Settings → Appearance, or the administrator makes it the default (appearance_default_theme=addon:<addon>:theme). The accent colour chosen in Settings → General before v13.7 is carried over into the theme once.
Upgrading from v13.5.0
Replace the executable/AppImage/container and keep the database and encryption key. No migration: the log settings gain main_folders (empty) and guess_operators (on) inside the existing per-server JSON, and a previous version ignores them. Labels of logs under a configured main folder are taken from it before the default patterns.
Upgrading from v13.4.4
Replace the executable/AppImage/container and keep the database and encryption key. Additive migration: a new table log_settings (per connection, encrypted) and new columns title, purpose, resumed_from and file_path in ai_sessions; a previous version still starts on the database. Log folders and journal units configured in the Zabbix dialog are read into the new Log settings until you save them there. New settings ai_show_thinking and ai_auto_titles (both 1). Dates are shown in the EU format by default; pick another in Settings → Date and time format (per browser).
Upgrading from v12.9.0
Replace the executable/AppImage/container and keep the database and encryption key. No database change. New policies: medium_default_engine (native) and medium_build_user (empty). If the original deploy tool was already imported, WRM sets medium_default_engine=original once at the first start and logs it, so projects keep their engine; set it to native in Admin → Policies to deploy with WRM by default. A project with an engine chosen explicitly keeps it. Pulling deploy-config from Git needs DEPLOY_CONFIG_REPO in the Medium settings and a WRM Git source for that repository (with a write token for commit and push).
Upgrading from v12.8.1
Replace the executable/AppImage/container and keep the database and encryption key. No database change. Editing deploy-config in WRM uses the existing medium_native policy (default admins); users without it see the files read-only.
Upgrading from v12.7.1
Replace the executable/AppImage/container and keep the database and encryption key. No database change. The Git check reads the version from the code by default; VERSION.md is only compared when the new checkbox is on. Deployments and updates still write VERSION.md. The first check after the upgrade may need a target refresh to load the older version trees; until then the per-file history is used.
Upgrading from v12.7.0
Replace the executable/AppImage/container and keep the database and encryption key. No database change. Existing deploy-config files keep working; an environment may now add servers: [name, ...] to limit its projects to those servers. Importing a config ZIP still replaces the config directory and removes its Git history, so use Git for changes once the directory is a clone.
Upgrading from v12.6.26
Replace the executable/AppImage/container and keep the database and encryption key. The database gets the table medium_project_engine; a previous version still starts on it (projects switched to the native engine are then deployed by the original tool again, which reads the same server state). Every project stays on the Docker runtime until someone allowed by the new policy medium_native (default admins) switches it to WRM native. New settings medium_command_timeout (300) and medium_transfer_timeout (3600). With step-up on, native deployments, rollbacks and lock releases ask for a confirmation (medium.deploy, medium.rollback, medium.lock_release).
Upgrading from v12.6.25
Replace the executable/AppImage/container and keep the database and encryption key. The database gets the table siem_destinations; a previous version still starts on it (it does not enforce a lockdown, so end a lockdown before going back). Nothing is exported until an administrator adds a SIEM destination. New settings alert_failed_signins (10), alert_failed_signins_minutes (10), alert_break_glass, alert_new_admin, alert_secret_reveal, alert_ai_full_access and alert_audit_off (all on); new notification event security.alert; new command line flags -lockdown / -lockdown-reason and environment variable WRM_LOCKDOWN. Security events (security.*) are now recorded even with audit_enabled off.
Upgrading from v12.6.24
Replace the executable/AppImage/container and keep the database and encryption key. The database gets the tables ldap_directories, ldap_identities, scim_clients, scim_users, scim_groups and scim_group_members; a previous version still starts on it (accounts that sign in with a directory password then cannot sign in, since WRM keeps no password for them). Nothing changes until an administrator adds an LDAP directory or a SCIM client. New setting ldap_sync_minutes (15). Changing an OIDC provider's issuer now asks for its client secret again.
Upgrading from v12.6.23
Replace the executable/AppImage/container and keep the database and encryption key. The database gets the tables oidc_providers and user_identities and the columns users.sso_only, auth_sessions.identity_id and team_members.source; a previous version still starts on it (directory accounts then cannot sign in, since they have no password). Nothing changes until an administrator adds an identity provider. New settings local_login (all), oidc_revalidate_minutes (60) and oidc_unverified_hours (12). The Enterprise level now requires local_login = break_glass; it takes effect only while a directory sign-in is enabled, so nobody is locked out of an installation without one. Releases from this version on are signed and published automatically when a version is merged.
Upgrading from v12.6.22
Replace the executable/AppImage/container and keep the database and encryption key. The database gets the tables teams, team_members and share_teams and the columns users.role, users.break_glass and auth_sessions.step_up_at; a previous version still starts on it (it sees administrators as before, and auditors and operators as ordinary users). Existing accounts keep their rights: administrators stay administrators, everyone else is a User. New settings require_step_up (off; the Business and Enterprise levels require it, so an installation at one of those levels shows it in the security posture until it is turned on), step_up_minutes and break_glass_ips. Scripts that call PUT /api/admin/settings, change roles or delete users with step-up on get 403 {"step_up": true} unless the session confirmed with POST /api/auth/step-up (signing in counts as a confirmation for step_up_minutes). DELETE /api/admin/users/{id} still deletes everything the user owns unless ?transfer_to=<user id> is given.
Upgrading from v12.6.21
Replace the executable/AppImage/container and keep the database and encryption key. The database gets one new table, security_deviations; a previous version still starts on it. Existing installations stay at the Home level and no setting changes until an administrator picks another level in Admin panel → Security (or sets WRM_INITIAL_SECURITY_LEVEL / WRM_SECURITY_LEVEL). New settings security_level, require_https and link_share_max_days; new endpoints GET /api/admin/security and POST /api/admin/security/level. Loosening a policy below the chosen level now needs a reason (_deviation_notes in PUT /api/admin/settings); scripts that set settings at the Home level are not affected.
Upgrading from v12.6.20
Replace the executable/AppImage/container and keep the database and encryption key. No database change. New setting update_signing_keys (empty: only the built-in key). This version has no built-in release key yet, so its self-update still verifies the SHA-256 only and the update dialog says Signature: not checked; the version that adds the key turns the signature check on. New command-line options -release-keygen, -release-sign, -release-verify.
Upgrading from v12.6.19
Replace the executable/AppImage/container and keep the database and encryption key. No database or setting change. Building from source now needs Go 1.26 or newer (go.mod asks for the Go 1.27.2 toolchain, which go downloads by itself when GOTOOLCHAIN allows it).
Upgrading from v12.6.11
Replace the executable/AppImage/container and keep the database and encryption key. No database change. Nothing changes until an administrator sets ai_opencode_sandbox (admins or all) and presses Download and install again in Admin panel → AI assistant → OpenCode agents, which prepares the Docker sandbox. New settings ai_opencode_sandbox and ai_opencode_sandbox_image; POST /api/ai/sessions takes sandbox: true.
Upgrading from v12.6.10
Replace the executable/AppImage/container and keep the database and encryption key. The database gets one new column, users.ai_delegate_training (a user's own choice to allow helper models that may train on prompts); a previous version still starts on it. Nothing changes until an administrator adds an OpenCode Zen provider, turns on delegation (ai_delegate) or installs OpenCode in Admin panel → AI assistant → OpenCode agents. ai_provider_kinds now includes opencode; if you set it yourself, add opencode to allow the new provider. New settings ai_delegate* and ai_opencode*; new endpoints /api/ai/delegate and /api/admin/opencode. OpenCode itself is stored next to the database in <DB>.opencode/.
Upgrading from v12.6.9
Replace the executable/AppImage/container and keep the database and encryption key. No database change. The Workboard is now the canvas itself: your v12.6.9 tiles open as addon windows beside your terminals the first time (from the top right), and tiles you pulled out into panels stay where they are. Broadcast moved from the top bar into 🧰 Tools. /api/me/ui/{key} now accepts values up to 256 KiB.
Upgrading from v12.6.8
Replace the executable/AppImage/container and keep the database and encryption key. The database gets one new table, user_events (each user's in-app notifications, newest 200); a previous version still starts on it and ignores it. Nothing changes on the page until you open ▤ Workboard and add an addon. New policy workboard_ssh_metrics (on): turn it off if the Server load addon must not log in to servers over SSH; servers with Monitoring still show their values. New endpoints /api/me/events and /api/workboard/metrics.
Upgrading from v12.6.7
Replace the executable/AppImage/container and keep the database and encryption key. The database gets one new table, user_ui (your panel layout); a previous version still starts on it and ignores it. Nothing moves: your first layout is built from what the browser remembered in v12.6.7 (the right panel's tab and width, where the AI live view was docked, floating or hidden). New endpoint /api/me/ui/{key}.
Upgrading from v12.6.6
Replace the executable/AppImage/container and keep the database and encryption key. No database or API change. The AI live view now opens as a 🤖 AI tab in the right panel instead of a box at the bottom left; pick Floating in its title bar (or the 🤖 menu) for the old behaviour. Medium's Docker runtime now trusts the WRM host's root certificates (policy medium_host_ca, default on); if runtime preparation failed with certificate verify failed, press Prepare runtime again.
Upgrading from v12.6.5
Replace the executable/AppImage/container and keep the database and encryption key. No database change. Medium now uses the managed Docker runtime by default on Linux and macOS too. An installation whose host runtime (Python virtual environment) is already prepared keeps it; set WRM_MEDIUM_RUNTIME=docker to move it to Docker, or native to keep the host runtime for good. Nothing is installed until an administrator presses Install Docker in Medium step 2; the new policy medium_docker_install (default on) switches that button and the automatic installation off.
Upgrading from v12.6.4
Replace the executable/AppImage/container and keep the database and encryption key. One additive table (medium_activity); a previous binary still starts on the database. POST /api/git/medium/start now answers 202 and starts in the background (poll GET /api/git/medium), and a deploy-config or SSH ZIP uploaded while Medium is busy or not prepared yet is kept and applied at the next start (202, pending). Command output is shown in the Medium activity log to the user who ran it and, for the shared runtime, to every Medium user; set medium_log_output to admins or none to limit that.
Upgrading from v12.6.3
Replace the executable/AppImage/container and keep the database and encryption key. No database change. Blocked commands keep asking under full access until an administrator sets ai_full_access_blocked to deny (Admin panel → AI connections → Blocked commands with full access).
Upgrading from v12.6.2
Replace the executable/AppImage/container and keep the database and encryption key. One additive column (users.ai_full_access); a previous binary still starts on the database. If ai_full_access was already on, it now applies to every AI session (ai_full_access_mode = all, the default); set the mode to AI connections with the Full access scope (connection) in Admin panel → AI connections to keep the v12.6.2 behaviour, or to Users who turn it on themselves (user).
Upgrading from v12.6.1
Replace the executable/AppImage/container and keep the database and encryption key. No database change. Full access stays off until an administrator turns on ai_full_access (Admin panel → AI connections); then edit an AI connection and tick ⚠ Full access. Open sessions of that connection end and the app reopens them with the new rules.
Upgrading from v12.6.0
Replace the executable/AppImage/container and keep the database and encryption key. No database change. Existing AI connections keep their limits. To let an app work without limits, edit its AI connection in Settings → AI connections, press
