▤01 / DEFINITIONSLOCALLY VALIDATED
Definitions and inspection
Strict YAML, deterministic hashes and SQLite storage. Inspect saved definitions and explicitly refresh remote VM power state without confusing it with guest readiness.
Your homelab.
From anywhere.
Your Proxmox homelab, from desktop or mobile.
Define a Linux environment once. Recreate it when needed.
THE IDEA / DEFINITION ≠ INSTANCE
Define once.
Recreate anytime.
The environment outlives the VM: delete an instance, keep its definition, recreate it when you need it again.
- Self-hosted first.
- Your own Proxmox VE host or cluster, and no mandatory vendor cloud or account service. Proxmox is the first provider, behind an adapter — not the domain model.
- Reproducible, not magic.
- Inputs, image and template versions, provisioning steps and limitations are explicit. Definitions are validated strictly and never executed implicitly.
- Secure by default.
- Least-privilege Proxmox credentials, verified TLS and SSH host keys, and no Proxmox admin API exposed. Clients connect over your LAN or VPN.
WHAT RUNS TODAY
Implemented paths,
visible limits.
Local native and generated-provider evidence, kept separate from real homelab acceptance.
◇02 / PROVISIONINGGENERATED-PROVIDER TESTS
Create and recreate
Confirmed clone, resources, Cloud-Init, readiness and retained-definition recreation pass API/worker and native integration checks. Actual Proxmox template and guest acceptance remain open.
▥03 / SSHNATIVE INTEGRATION
Interactive SSH
Explicit host-key trust, encrypted application identity and an interactive terminal. Linux terminal checks pass against an owned SSH peer; optional Linux Secret Service unlock-secret controls now pass the complete WebView/IPC/vault/shell flow against a private test keyring.
⏻04 / LIFECYCLENATIVE INTEGRATION
Control and recovery
Remote start/shutdown, snapshot creation/restore and deletion have generated-provider integration evidence. Durable operation history survives restart without replaying uncertain mutations.
▣05 / DECLARED STEPSNATIVE INTEGRATION
Packages and final snapshot
Explicit package and final-snapshot review now passes joined Linux native creation/recreation checks, including lost-reply recovery. Safe failure messages and explicit recorded stage views pass native integration; actual guest installation remains unverified.
⇄06 / DELIVERYTEST ARTIFACTS
Linux server and Android
Linux server archives and signed ARM64/x86_64 Android debug APKs are buildable. Current APK execution, real deployment and full platform acceptance remain open; this is not a release candidate.
THE MVP / AS THE ROADMAP STATES IT
From a definition
to a running VM.
The main workflows have native/generated-provider evidence. Completing this journey on an approved real guest and the current Android artifact remains the acceptance target.
The MVP outcome from VMAnyware.md; current implementation and validation boundaries are tracked in STATE.md.
A DEFINITION
An environment
is a file.
Versioned YAML, validated strictly by the control plane, stored independently of any VM.
● ● ●
examples/kernel-lab.yamlLINUXapiVersion: vmanyware.dev/v1
kind: Environment
metadata:
name: kernel-lab
description: Linux development environment
spec:
image: debian-13
resources:
cpu: 4
memoryMiB: 8192
diskGiB: 40
provisioning:
cloudInit: true
sshAuthorizedKeys:
- ssh-ed25519 AAAAC3Nz… vmanyware-example
packages:
- build-essential
- git
lifecycle:
snapshotAfterProvisioning: falseA Linux development environment: image, resources, cloud-init, packages and lifecycle.
From the repository’s examples/ and README; the public demonstration key is shortened here.
STATUS / IN DEVELOPMENT
Implemented,
still being validated.
What has been verified, what is pending, and what isn’t built — kept apart.
API, worker and native paths.
Owned generated-provider checks cover creation/recreation, lifecycle, snapshots, deletion and restart recovery. Linux native SSH uses a generated local peer; these checks do not establish real guest behavior.
The home Proxmox journey.
Actual template/resources, Cloud-Init, package installation, SSH and snapshot guest-state restoration still need an available, explicitly approved disposable Proxmox target.
Platform acceptance and key storage.
Recorded stage views now pass Linux native checks, including the extracted server archive. Refreshed Android APKs have packaging evidence; exact APK execution, normal desktop vault setup, Android Keystore and other OS credential stores, iOS/Windows parity and production deployment/release acceptance remain open.
Concrete infrastructure targets.
Real VM, production or credential changes require approval of their concrete target and operation. Default checks use owned local fixtures without Proxmox credentials.
IN PRACTICE / THE EVIDENCE
A problem.
What changed.
Choose a target to read what happened: the problem, the finding and the result. Each story names its evidence and the scope of its validation.
A lost reply must not become a second VM action.
- Problem
- When a start request loses its reply, the client cannot safely assume failure and submit a fresh operation.
- Finding
- The lifecycle walkthrough exercised persisted request identity, lost replies and explicit resume. Native Linux validation connected the real Tauri UI and production commands to Axum and a generated HTTPS provider fixture.
- Result
- The documented validation checked start and graceful shutdown through the native stack. Retained operation identity makes an uncertain result reviewable and resumable.
OPEN SOURCE / IN DEVELOPMENT
Try the local demo
without Proxmox.
Run the API and the native window side by side, then check the local service.
RUN LOCALLY · FROM THE REPOSITORY ROOT
make doctor make install-client make server # in one terminal make dev # in another, then click "Check local service"