Roadmap

What we intend to build, in the order we consider sensible. We aim to ship the items under In progress and Planned by March 2027. An item moves up when customers need it and down when something more important comes along. As of September 2026. Send us your wishes and priorities via the contact page.

In progress

• MariaDB updates without manual steps — The configuration tool detects a new MariaDB series and fills in the program and data paths itself. Until then the handbook describes the procedure.
• App-V detail pages with every action — Publish, retract and delete exist in the lists today; they are coming to the detail pages of packages and connection groups too, with the same handling as MSIX.
• Policies: the computer has a say — The computer part of a policy set decides whether user parts apply on that device, following the loopback principle from Group Policy.
• Logs that look after themselves — Server and agent logs are truncated, compressed and monitored. Agent error messages name the cause and the next step in plain language.

Planned by March 2027

• Entra ID as an identity provider — Portal sign-in via OpenID Connect alongside Windows SSO, permissions from Entra groups. The design is ready.
• App Attach: local cache — The agent keeps CIM images locally so applications start quickly even when the share is slow. Watching the mount, including self-healing, already ships.
• Prestage — Packages and licences are staged machine-wide in advance, the user only registers them. For terminal servers and VDI with many logons.
• ZeroPortal launcher — A starter for App-V and MSIX applications with scripts before and after launch, distributed centrally like a policy.
• Usage reporting for MSIX and App Attach — Which applications run where and how often, as App-V reporting does today. The basis for retiring packages.
• Unify the App-V module — Retraction and cleanup by the same rules as MSIX, a general overhaul of the App-V part.
• MSIX tooling in the portal — Re-signing with the identity preserved, shared package containers, winget import inside the portal, differential download on updates.

Later

• Portal server on Linux and in a container — The server is built for it: no P/Invoke, no registry, no WMI. The remaining Windows calls, for services and the firewall, are listed and replaceable. The agent stays on Windows.
• Sites and zones — A central topology instead of per-node configuration, so agents find the nearest server and the nearest share.
• Self-service for users — A catalogue where users request approved applications themselves. The server interface exists, the client is under review.

What has already shipped is in the release notes.