Build, configure, diagnose, and eventually operate virtual machines through a secure, typed desktop experience built with Tauri, React, TypeScript, and Rust.
Documentation · Architecture · Roadmap · Contributing · Security · Issues
NexoraVM is an open-source Windows-first desktop application for managing virtual-machine definitions, local virtualization runtimes, and AI-assisted workflows from one focused workspace.
The project is intentionally being built in layers. The current foundation covers persistent VM configuration, runtime diagnostics, safe QEMU command construction, and controlled QEMU process management. Guest display, storage, networking, advanced lifecycle recovery, and the AI workspace are being developed as separate milestones rather than being coupled prematurely.
Project status: active early development. NexoraVM is not production-ready and should be treated as an experimental project while the runtime and guest-management layers mature.
| Area | Status | Current capability |
|---|---|---|
| Desktop shell | ✅ Implemented | Tauri v2 desktop shell, navigation, dashboard, settings, and VM workspace. |
| Persistent settings | ✅ Implemented | Typed settings persisted in the OS application-data directory. |
| VM definitions | ✅ Implemented | Persistent VM configuration with UUID-based identifiers and validation. |
| VM management | ✅ Implemented | Create, edit, delete, validation, status display, and runtime controls. |
| Runtime discovery | ✅ Implemented | Bounded QEMU discovery, executable validation, and fixed version probing. |
| QEMU command construction | ✅ Implemented | Deterministic typed command specifications with no shell execution. |
| QEMU process management | ✅ Implemented | Controlled validated process start/stop, monitoring, bounded output, and lifecycle state. |
| QEMU boot and disk lifecycle | ✅ Implemented | Install and normal boot modes, persistent disk creation, ISO/disk validation, duplicate-start rejection, and stop cleanup. |
| VM runtime integration | 🟡 Partial | Managed process lifecycle exists; complete guest/runtime synchronization is still being built. |
| WHPX execution | ⏳ Planned | Windows capability fields exist, but WHPX execution is not implemented. |
| Virtual storage | ⏳ Planned | Storage preferences exist; disk creation and management are not implemented. |
| Networking | ⏳ Planned | VM network modes are modeled; host networking is not configured. |
| Guest display / console | ⏳ Planned | Full display, input, and guest interaction layer is not implemented. |
| Snapshots | ⏳ Planned | Snapshot and restore workflows are not implemented. |
| AI workspace | ⏳ Planned | Product area is defined; model runtime and AI tools are not implemented. |
| AI model providers | ⏳ Planned | No local or cloud model provider runtime is integrated yet. |
| Release packaging | 🟡 Partial | Development builds work; a production-ready installer/release process is still being hardened. |
Screenshots will be added once a repeatable desktop capture workflow is established. Until then, the repository intentionally avoids broken or unverified image links.
flowchart TD
UI["React + TypeScript UI"] --> Bridge["Tauri Command Bridge"]
Bridge --> Core["Rust Application Core"]
Core --> Settings["Settings Persistence"]
Core --> VMDefs["VM Definition Store"]
Core --> Runtime["Runtime Adapter"]
Runtime --> Discovery["QEMU Discovery"]
Runtime --> Builder["Typed QEMU Command Builder"]
Runtime --> Process["Controlled Process Manager"]
Process --> QEMU["QEMU Process"]
Core -. future .-> WHPX["WHPX Backend"]
Core -. future .-> Storage["Storage Manager"]
Core -. future .-> Network["Network Manager"]
Core -. future .-> AI["AI Runtime"]
| Layer | Responsibility |
|---|---|
| React + TypeScript | Desktop UI, forms, dashboards, typed service calls, and user-visible runtime state. |
| Tauri | Desktop shell and narrow bridge between the frontend and trusted native operations. |
| Rust core | Persistence, validation, runtime discovery, command construction, process management, and structured errors. |
| Runtime adapter | Provider-neutral boundary for virtualization backends such as QEMU and future WHPX support. |
| QEMU layer | Discovery, typed command construction, and controlled process lifecycle. |
| Future AI runtime | Model providers, tool permissions, planning, and AI-assisted VM workflows. |
See Architecture for detailed data flow, boundaries, and design decisions.
|
Typed by design VM configuration, runtime capabilities, command specifications, and process states are represented as explicit models rather than loose strings. |
Security-conscious Native execution is deliberately constrained: no shell interpreters, no generic command runner, and no unnecessary administrator privileges. |
Built in layers Configuration, runtime, storage, networking, and AI are kept behind explicit boundaries so the system can grow without turning the UI into a monolith. |
| Technology | Purpose |
|---|---|
| Tauri v2 | Windows desktop shell and native command bridge. |
| React | Component-based desktop UI. |
| TypeScript | Frontend types, service contracts, and domain models. |
| Vite | Frontend development and production bundling. |
| Rust | Native application core, persistence, validation, diagnostics, and process management. |
| QEMU | Planned/current virtualization runtime used through validated process specifications. |
| WHPX | Planned Windows acceleration backend. |
- Windows 11 recommended.
- Node.js and npm.
- Rust stable with the Windows MSVC toolchain.
- Visual Studio or Visual Studio Build Tools with the Desktop development with C++ workload.
- Tauri v2 Windows prerequisites.
- WebView2 Runtime, normally available on modern Windows installations.
On Windows, Visual Studio Developer PowerShell may be required for the Rust MSVC linker.
npm cinpm run tauri devnpm run buildnpm run tauri buildA successful development/package build does not yet imply a production-ready installer or release workflow.
cargo fmt --manifest-path .\src-tauri\Cargo.toml -- --check
cargo check --manifest-path .\src-tauri\Cargo.toml
cargo test --manifest-path .\src-tauri\Cargo.toml
git diff --checkSee Development Guide for the complete contributor workflow and troubleshooting notes.
NexoraVM/
├── .github/ GitHub Actions, Dependabot, templates
├── docs/ Technical documentation and roadmap
├── public/ Static frontend assets
├── src/ React + TypeScript application
│ ├── components/ Reusable UI components
│ ├── hooks/ React hooks
│ ├── layouts/ Desktop shell layout
│ ├── lib/ Frontend services and shared utilities
│ ├── pages/ Dashboard, Settings, VM management, placeholders
│ └── types/ Frontend domain models
├── src-tauri/ Rust/Tauri application core
│ ├── src/ Commands, models, persistence, runtime code
│ ├── capabilities/ Tauri capability configuration
│ ├── Cargo.toml Rust package/dependencies
│ └── tauri.conf.json Tauri application configuration
├── CONTRIBUTING.md Contribution guidelines
├── SECURITY.md Security policy and threat model
├── SUPPORT.md Support and troubleshooting guidance
├── CHANGELOG.md Project change history
└── README.md Project entry point
NexoraVM keeps application settings and VM definitions separate from live runtime state.
Application settings are stored as settings.json in the OS application-data directory. VM definitions are stored separately as vm-definitions.json. Live QEMU process handles and runtime state remain managed in memory and are not persisted as if they were durable VM configuration.
See Configuration and Runtime for details.
Virtualization and native process execution are security-sensitive parts of the system. NexoraVM therefore uses explicit typed boundaries between UI input, VM configuration, command construction, and process execution.
The current design intentionally avoids:
- Shell interpreters such as
cmd.exe, PowerShell, orsh -cfor QEMU execution. - Arbitrary executable paths or arbitrary raw QEMU argument arrays from the frontend.
- Unrestricted generic process-execution commands.
- Unnecessary administrator privileges.
- Automatic host networking or firewall changes.
- Broad process scanning or adoption of unrelated QEMU processes.
See SECURITY.md for the current security model and known deferred work.
NexoraVM is being developed in explicit milestones so each boundary can be tested before the next layer depends on it.
- ✅ Desktop application foundation
- ✅ Persistent configuration foundation
- ✅ VM definition management
- ✅ Runtime discovery and diagnostics
- ✅ Safe QEMU command construction
- ✅ Controlled QEMU process management
- ✅ VM runtime-state synchronization
- ✅ Persistent disk and normal boot flow
- ✅ Persistent boot validation and lifecycle hardening
- ⏳ Guest display and console integration
- ⏳ Storage and networking
- ⏳ AI workspace and model providers
- ⏳ AI-assisted VM workflows
- ⏳ Release hardening
The detailed and canonical roadmap is docs/roadmap.md.
NexoraVM is an active open-source development project. Contributions should be focused, typed, tested, documented, and security-conscious.
Start with:
For troubleshooting and issue-reporting guidance, see SUPPORT.md. Before opening an issue, check the relevant documentation and existing issues where practical.
Licensing is not yet specified. A license should be added before broad distribution or accepting contributions under public reuse terms.
NexoraVM is under active development and is not production-ready. APIs, persistence formats, runtime behavior, and security boundaries may change before a supported release.
| Document | Purpose |
|---|---|
| Documentation Index | Entry point for project documentation. |
| Overview | Project goals, scope, and current maturity. |
| Architecture | System architecture, data flow, and boundaries. |
| Current Status | What is implemented today and what remains. |
| Roadmap | Canonical phased development plan. |
| Development | Local setup, checks, tests, and contributor workflow. |
| Configuration | Settings and VM-definition persistence. |
| Runtime | Runtime discovery, QEMU, and process-management behavior. |
| Decisions | Architectural decisions and rationale. |
| Contributing | Contribution and pull-request guidance. |
| Security | Security model and reporting guidance. |
| Support | Troubleshooting and issue-reporting guidance. |