VMAnyware — Votre homelab. De partout.

L’IDÉE / DÉFINITION ≠ INSTANCE

Décrire une fois.
Recréer à volonté.

L’environnement survit à la machine virtuelle : supprimez une instance, gardez sa définition, recréez-la quand vous en avez de nouveau besoin.

Hébergé chez vous d’abord.: Votre propre serveur ou cluster Proxmox VE, sans cloud ni compte obligatoire chez un fournisseur. Proxmox est le premier fournisseur, derrière un adaptateur — pas le cœur du modèle.
Reproductible, pas magique.: Les entrées, les versions d’images et de modèles, les étapes de création et les limites sont explicites. Les définitions sont validées strictement et jamais exécutées implicitement.
Sûr par défaut.: Des identifiants Proxmox aux droits minimaux, des certificats TLS et des clés d’hôte SSH vérifiés, et aucune API d’administration Proxmox exposée. Les applications se connectent par votre réseau local ou votre VPN.

CE QUI FONCTIONNE AUJOURD’HUI

Parcours implémentés,
limites visibles.

Les preuves natives et simulées restent distinctes de la validation d’un vrai homelab.

▤01 / DÉFINITIONSVALIDÉ EN LOCAL

Définitions et inspection

YAML strict, empreintes déterministes et SQLite. Inspection des définitions et lecture explicite de l’état distant, distincte de la disponibilité SSH.

◇02 / CRÉATIONFOURNISSEUR SIMULÉ

Créer et recréer

Clone, ressources, Cloud-Init, disponibilité et recréation passent les tests API/worker et natifs. Vrais templates et guests Proxmox restent à valider.

▥03 / SSHINTÉGRATION NATIVE

Terminal interactif

Empreinte confirmée, identité chiffrée et terminal. Les tests Linux passent contre un serveur SSH local dédié ; l’option Secret Service Linux passe le parcours complet WebView/IPC/coffre/terminal avec un trousseau privé de test.

⏻04 / CYCLE DE VIEINTÉGRATION NATIVE

Contrôle et reprise

Démarrage/arrêt distant, snapshots/restauration, suppression et reprise après redémarrage passent les tests avec fournisseur simulé, sans rejouer les mutations incertaines.

▣05 / ÉTAPES DÉCLARÉESINTÉGRATION NATIVE

Paquets et snapshot final

Revue explicite des paquets et du snapshot final validée sur les parcours Linux natifs de création/recréation, y compris la reprise après réponse perdue. Messages d’erreur et lecture explicite des étapes validés en intégration native ; installation dans un vrai guest non validée.

⇄06 / LIVRAISONARTEFACTS DE TEST

Serveur Linux et Android

Archives serveur Linux et APK Android debug signés ARM64/x86_64 sont compilables. APK actuel, déploiement réel et plateformes restent à valider ; ce n’est pas une release candidate.

LA PREMIÈRE VERSION / TELLE QUE LA FEUILLE DE ROUTE LA DÉCRIT

D’une définition
à une machine qui tourne.

Les parcours natifs et simulés ont leurs preuves. Le guest réel approuvé et l’APK Android actuel restent à valider.

Le résultat visé par la première version, d’après VMAnyware.md ; l’état actuel de la réalisation et de la validation est suivi dans STATE.md.

UNE DÉFINITION

Un environnement
est un fichier.

Du YAML versionné, validé strictement par le serveur de contrôle, rangé indépendamment de toute machine virtuelle.

● ● ●examples/kernel-lab.yamlLINUX

apiVersion: 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: false

Un environnement de développement Linux : image, ressources, cloud-init, paquets et cycle de vie.

Tiré des exemples (examples/) et du README du dépôt ; la clé publique de démonstration est raccourcie ici.

ÉTAT / EN DÉVELOPPEMENT

Implémenté,
encore en validation.

Ce qui a été vérifié, ce qui reste à faire, et ce qui n’est pas construit — chacun à sa place.

01 / VÉRIFIÉ

API, worker et parcours natifs.

Les tests dédiés couvrent création/recréation, cycle de vie, snapshots, suppression et reprise. Le SSH Linux natif utilise un serveur local généré ; cela ne prouve pas le comportement d’un vrai guest.

02 / EN ATTENTE

Le parcours Proxmox à la maison.

Template réel, ressources, Cloud-Init, paquets, SSH et restauration de l’état du guest nécessitent une cible Proxmox jetable disponible et explicitement approuvée.

03 / ENSUITE

Plateformes et stockage des clés.

La lecture des étapes passe les tests natifs Linux, y compris avec le serveur extrait de son archive. Les APK actualisés passent les contrôles de paquet ; exécution Android, coffre du bureau installé, Android Keystore, coffres des autres OS, iOS/Windows, déploiement et release restent à valider.

04 / SUR APPROBATION

Des cibles concrètes.

Les changements de VM réelle, de production ou d’identifiants demandent l’approbation de la cible et de l’opération. Les tests par défaut utilisent des fixtures locales sans identifiants Proxmox.

EN PRATIQUE / LES PREUVES

Un problème.
Ce qui a changé.

Choisissez une cible pour lire ce qui s’est passé : le problème, la découverte et le résultat. Chaque histoire cite ses preuves et l’étendue de sa validation.

Validation d’intégration isolée

Une réponse perdue ne doit pas devenir une seconde action sur la machine.

Problème: Quand une demande de démarrage perd sa réponse, l’application ne peut pas supposer un échec et relancer une nouvelle opération sans risque.
Découverte: Le parcours du cycle de vie a mis à l’épreuve l’identité des demandes enregistrée, les réponses perdues et la reprise explicite. La validation native sous Linux a relié la vraie interface Tauri et les commandes de production à Axum et à un faux fournisseur HTTPS généré.
Résultat: La validation documentée a vérifié le démarrage et l’arrêt propre à travers toute la pile native. Garder l’identité de l’opération permet de revoir et de reprendre un résultat incertain.

OPEN SOURCE / EN DÉVELOPPEMENT

Essayez la démo locale
sans Proxmox.

Lancez l’API et la fenêtre native côte à côte, puis vérifiez le service local.

EN LOCAL · DEPUIS LA RACINE DU DÉPÔT

make doctor
make install-client
make server      # in one terminal
make dev         # in another, then click "Check local service"

Ouvrir le dépôt Tous les outils devutils

Node.js 22.12+, Rust 1.99.1 et les prérequis de Tauri · iOS demande Xcode, Android son SDK/NDK

Votre homelab.De partout.

Décrire une fois.Recréer à volonté.

Parcours implémentés,limites visibles.