Vyomi v2.3.0

Added

• Free tier = Vyomi-Nano (in-browser), end to end. The Free tier is now the zero-install in-browser sim: the workspaces dashboard + all three provider consoles run in a dark theme; live per-cloud resource-utilization pies + per-service CPU/RAM tiles (census written by each console page, read by the SW); the Nano launch page gains the Activate appliance (real portal device-flow) + GitHub buttons; and Active spaces shows a Connect external apps card with the live relay endpoint URL + SDK/CLI/curl examples. Portal: Free tier links to /nano/, system-requirements/downloads/install views describe the browser tier (OS tabs offer the optional vyomi-tunnel local relay via npm/brew, required only for external WASM RDS), homepage screenshots refreshed to the dark UI, and the Nano bundle is served base-path-aware at /nano/ with Cache-Control: no-cache.
• Vyomi-Nano relay → Cloudflare (DEPLOYED & live at relay.vyomi.cloud). wasm/relay/worker.js (Cloudflare Worker + RelaySession Durable Object) lets an external SDK/CLI reach the in-browser sim: a Nano tab opens an outbound wss://relay.vyomi.cloud/register?session=<id> held by the DO, and https://relay.vyomi.cloud/<id>/<path> is relayed to the tab. Deployed to Cloudflare (SQLite-backed DO via new_sqlite_classes; bound as a Custom Domain relay.vyomi.cloud; ALLOWED_ORIGIN=https://vyomi.cloud). Validated end-to-end against the live edge: external client → deployed Worker DO → browser tab (Pyodide cores) → response across all 7 AWS services + the in-tab PGlite SQL bridge + RDS Data API (17 requests served); origin gate confirmed (foreign origin → 403). Redeploy: cd wasm/relay && npx wrangler deploy.
• Dual tunnel — local relay + cloud, with automatic detection & failover. Adds a brew install vyomi-cloud/tap/vyomi-tunnel local reverse-tunnel (wasm/relay/local-relay.mjs, packaged at packaging/tunnel/ + Homebrew formula packaging/brew/vyomi-tunnel.rb) as the fast/private/offline counterpart to the hosted Cloudflare relay. The local relay serves GET /health (CORS + Private-Network-Access headers) so an https:// Nano tab can probe loopback; the SharedWorker auto-detects it and prefers local, falling back to cloud — dynamically and both directions: install/start the tunnel mid-session → switch to local within ~15s; quit it → fall back to cloud within ~30s (two-miss debounce), with no reload. The footer shows the active tunnel + the endpoint apps point at (http://127.0.0.1:8090 local, https://relay.vyomi.cloud/<session> cloud). Config overridable via localStorage (nano_local_* / nano_cloud_*); local relay tunables via RELAY_PORT/RELAY_HOST. Headless-browser validated: cloud-select with no local → switch-to-local on install → fall-back-to-cloud on kill, all green. Guide: docs/guides/nano-tunnel.md.
• Frozen relay-tunnel footer on every Nano view, backed by a module SharedWorker (wasm/relay/relay-shared-worker.js) that hosts the endpoint (Pyodide + cores + relay WebSocket) so the tunnel control + status + mirrored logs follow the user across dashboard↔console navigation with no extra tab (auto-resume re-handshakes per same-tab nav; separate tabs stay continuously connected).
• GCP console resource CRUD in Nano. The in-browser service worker now routes /api/gcp/* catalog paths to the provider-agnostic in-browser ResourceStore, so creating resources in the GCP console works (was 501). Spaces are now created/persisted in-browser (IndexedDB) and appear in the dashboard grid.
• Azure console in Nano — native ARM control plane in WASM. The Azure console speaks real Azure Resource Manager (/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.X/{type}/{name}?api-version=), not the generic /api/{cloud}/{service} scheme, so it gets its own port: a substrate-free core/azure_arm_core.py (AzureArm) — a faithful WASM analogue of providers/azure_services.handle_arm, with the appliance's real RESOURCE_CATALOG dumped verbatim into core/azure_arm_data.py (13 services, 6 roles). It serves the full ARM surface — PUT/GET/DELETE/PATCH, collection list scoped by subscription+resource-group, provider-registration probes, resource-group list/item, POST action verbs (listKeys, VM start/powerOff metadata-only), and long-running-operation headers (Azure-AsyncOperation/Location → /api/azure/operations/{id} → Succeeded). The service worker now owns /subscriptions/* + /api/azure/operations/* (routed to ["azure","_arm",…] → registry._arm_dispatch → AzureArm, with the raw HTTP status/headers/body honoured verbatim) and serves /api/azure/catalog from a generated fixture. Same suite green on host CPython AND real Pyodide (tests/conformance/test_azure_arm_core.py, 34 checks); headless-browser validated 13/13 services round-trip create→get→list→delete over native ARM through the live SW. (Data-plane verbs the appliance backs with Azurite/Vault — Blob, Queues, Key Vault — are not yet in Nano; ARM control-plane only.)

Note

• The in-browser sim runtime is Pyodide, not WebVM/CheerpX (32-bit, no kernel, ~5–10× slower) — see docs/browser-lite/VYOMI-LITE-DESIGN.md.

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-2.3.0-1.noarch.rpm
• cloud-learn-2.3.0-x64.msi
• cloud-learn-2.3.0-x64.msi.sha256
• cloud-learn-2.3.0.tar.gz
• cloud-learn_2.3.0_all.deb
• vyomi-docker-2.3.0-1.noarch.rpm
• vyomi-docker_2.3.0_all.deb

Docker image: docker pull vyomi/appliance:2.3.0
Install: curl -fsSL https://raw.githubusercontent.com/vyomi-cloud/appliance/main/install.sh | bash
SHA256 checksums: see SHA256SUMS in attached artifacts.