Vyomi v2.0.1

Zero-config first launch. v2.0.0 shipped HTTPS via mkcert + Caddy at https://vyomi.local:9443, but a fresh laptop hit three Chrome gotchas in sequence: (1) Secure DNS bypassing /etc/hosts for .local TLDs, (2) HSTS cache locking failed early attempts into HTTPS-only, (3) HTTPS-First Mode auto-upgrading http:// requests. Users were dropped into chrome://net-internals/#hsts to debug. v2.0.1 sidesteps all three by pivoting the canonical URL to https://localhost:9443/ — a hostname Chrome universally trusts. mkcert already covered localhost in its SAN list, so the green padlock works without any browser config changes.

Added

• socat localhost bridge — vyomi up now forwards 127.0.0.1:9000 → VM_IP:9000 and 127.0.0.1:9443 → VM_IP:9443 via two host-side socat processes (PIDs tracked at ~/.vyomi/run/socat-*.pid). Bridge is loopback-only (bind=127.0.0.1) — not reachable from outside the laptop. Idempotent — old PIDs killed before respawn. vyomi down/stop/kill tear it down cleanly.
• Auto browser open — after the health check passes, the launcher opens the working URL in the default browser (open on macOS, xdg-open on Linux, Start-Process on Windows). Honors VYOMI_NO_OPEN=1 for CI / headless / scripted environments.
• Loud mkcert failure surface — if the user dismisses the sudo prompt for mkcert -install, the launcher now prints a clearly-visible yellow ⚠ warning with the exact remediation command (brew install mkcert && vyomi restart). Old behaviour was a silent verbose-mode-only log line that users missed.

Changed

• Default appliance URL → https://localhost:9443/ (was https://vyomi.local:9443/). Banner probe ladder tries localhost:9443 (TLS) → vyomi.local:9443 (TLS) → localhost:9000 (HTTP) → vyomi.local:9000 (HTTP) → IP, and picks the first reachable one as primary. The other reachable URLs are advertised as fallbacks. Existing v2.0.0 URLs continue to work — this is purely a default-routing change.
• mkcert SAN order — the leaf cert is now generated with localhost 127.0.0.1 vyomi.local (was vyomi.local localhost 127.0.0.1). The cert covers the exact same names — just primary subject swapped to match the new default URL. Existing certs from v2.0.0 stay valid (all SANs preserved). Force regeneration with VYOMI_REISSUE_TLS=1 vyomi up.
• Brew formula adds depends_on "socat" and depends_on "mkcert" — both are required for the green-padlock-by-default UX. Pre-fetching them at brew install vyomi time means the first vyomi up has one fewer interactive prompt. Reinstall to pick up: brew reinstall vyomi.

Notes for users on v2.0.0

• After brew reinstall vyomi, run vyomi restart once. The new launcher will start the socat bridge against your existing VM and your browser will land on https://localhost:9443/.
• The vyomi.local and 192.168.x.x URLs from v2.0.0 still work — they're now listed as fallbacks rather than primary.
• If your Chrome had cached HSTS / HTTPS-First Mode for vyomi.local, the localhost pivot makes that irrelevant. You don't need to clear anything.
• Windows: the localhost bridge is not yet wired (no socat in standard tools). Windows users continue to hit vyomi.local:9443 directly. netsh interface portproxy-based bridge is a v2.1.0 follow-up.

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-2.0.1-1.noarch.rpm
• cloud-learn-2.0.1.tar.gz
• cloud-learn_2.0.1_all.deb

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

Vyomi v2.0.0

The vyomi-branded release. 13-phase rebrand campaign: CLI binary, brew formula, Docker Hub namespace, GitHub org, license (MIT → BSL 1.1), HTTP headers, env vars, Python modules, filesystem paths, Docker volumes, Multipass VM name, and HTTPS by default. Every layer ships with runtime back-compat so v1.x upgrades are transparent. See docs/MIGRATION-v2.md for the upgrade guide.

Changed — BREAKING

• HTTPS via mkcert + Caddy — the simulator is now reachable at https://vyomi.local:9443 with a green padlock (no 'Not Secure' browser warning). On first vyomi up (or install.sh curl-bash run), the launcher detects missing mkcert, offers to install it (brew/apt/dnf/winget), runs mkcert -install once to add a local CA to the system trust store (one sudo/UAC prompt accepted forever), then generates a cert+key for vyomi.local + localhost + 127.0.0.1 at ~/.vyomi/tls/. The cert is bind-mounted into a Caddy sidecar container (added to both docker-compose.yml and docker-compose.appliance.yml) that terminates TLS and reverse-proxies to the simulator on port 9000. HTTP on :9000 remains reachable as a fallback for scripts that don't validate certs. Set VYOMI_NO_TLS=1 to skip the whole flow. VYOMI_REISSUE_TLS=1 to force regenerate. VYOMI_TLS_DIR to override the cert location. Caddyfile lives at packaging/caddy/Caddyfile — swappable to nginx/Traefik later without touching server.py.
• Docker volumes renamed cloudlearn-* → vyomi-* in both docker-compose.yml (compose path) and docker-compose.appliance.yml (Multipass appliance path). 9 volumes: vyomi-data, vyomi-sql-pg, vyomi-sql-mysql, vyomi-gcs, vyomi-nats, vyomi-minio, vyomi-dynamodb, vyomi-portal-keys, vyomi-portal-data (cloudsim-data already neutral, untouched). Fresh installs use the new names. Existing users upgrading from v1.x must run bash scripts/migrate-volumes-vyomi.sh ONCE between docker compose down and docker compose up -d — copies all data from cloudlearn-* volumes into the new vyomi-* equivalents. The legacy volumes are left in place after migration for safe rollback; delete them with docker volume rm cloudlearn-* once satisfied.
• Multipass VM name defaults to vyomi-appliance for fresh installs. Existing installs with a cloudlearn-appliance VM (created pre-v2.0.0) keep using the old name — the launcher auto-detects via multipass info and avoids destroying state. The VM name surfaces only in multipass info <name>; users hit the simulator at vyomi.local:9000 regardless (mDNS publishing handles the brand-facing hostname). Env override VYOMI_APPLIANCE_NAME added (mirrors CLOUD_LEARN_APPLIANCE_NAME via Phase 8 env aliases).
• Filesystem paths renamed ~/.cloud-learn/ (launcher state) and ~/.cloudlearn/ (compose install) → ~/.vyomi/ with one-time migration. On first v2.0.0 boot: if either old path exists and ~/.vyomi/ doesn't, the launcher atomically renames it + creates a back-compat symlink at the old path. Both cloud-learn up and the install.sh curl-bash flow run the migration independently. End users with existing state (logs at ~/.cloud-learn/logs/, appliance bootstrap files at ~/.cloud-learn/appliance/<vm>/, compose state at ~/.cloudlearn/{compose,data,deployments}/) experience zero data loss. Idempotent — does nothing once ~/.vyomi/ is the canonical dir. The two old launcher/compose path namespaces were inconsistent (hyphen vs no-hyphen); this rename unifies them under ~/.vyomi/. Symlink retired in v3.0. NOT touched in this phase: /etc/cloudlearn/ (deb/rpm system config), /var/lib/cloudlearn/ (inside-VM state) — those are higher-risk and deferred to a focused later release.
• Python modules renamed core.cloudlearn_* → core.vyomi_* with full back-compat re-export shims at the old paths. Affected: core.cloudlearn_platform → core.vyomi_platform (with internal class CloudLearnPlatform → VyomiPlatform and back-compat alias inside the module), and 14 packs.azure.cloudlearn_azure_* → packs.azure.vyomi_azure_* modules. Old import paths (from core.cloudlearn_platform import CloudLearnPlatform) keep working — the shim re-exports the canonical names. Pack identifier strings (e.g. cloudlearn.azure.vm.basic) are unchanged for now (catalog-internal, not user-visible). Removal slated for v3.0.
• Environment variables renamed CLOUDLEARN_* → VYOMI_* with full back-compat. A new runtime mirror (core/env_aliases.mirror_env) populates both spellings in os.environ at server startup — existing deployments, .env files, Dockerfiles, and CI configs keep working unchanged. .env.example now uses VYOMI_* as the documented canonical name. docker-compose.yml interpolations use a dual fallback ${VYOMI_X:-${CLOUDLEARN_X:-default}} so users overriding via either name win. The bash launcher (scripts/cloud-learn) does the same mirror at shell level so docker compose and multipass exec subshells see both spellings. Conflict-safe: if both names are set with different values, neither is overwritten and a one-line stderr warning is emitted at startup. Removal slated for v3.0.
• HTTP headers renamed X-CloudLearn-* → X-Vyomi-* with full back-compat. A new ASGI middleware (core/header_aliases.HeaderAliasMiddleware) transparently bridges both names on every request and response: clients can send either spelling, the server reflects both back on responses. SPA + portal-shipped SDKs now send X-Vyomi-* exclusively; legacy X-CloudLearn-* consumers (older SPA cached in browsers, third-party scripts) keep working. Affected headers: Tenant, Tier, Tier-Denied, Principal, Acting-As-Tenant, XTRBAC-Denied, Cedar-Denied, SSO-Denied, Admin-Key, Bridge-Token, CI-Secret, Notif-Secret, Sink-Secret, Host-OS. Removal slated for v3.0.
• CLI binary renamed cloud-learn → vyomi with a cloud-learn deprecation shim. The shim prints a one-line yellow warning to stderr on every interactive invocation (suppressible via VYOMI_NO_DEPRECATION_WARN=1) and then execs vyomi with the same args. End users on every install path see the binary rename simultaneously:
  • Brew: bin/vyomi (primary) and bin/cloud-learn (shim) both shipped with the formula
  • DEB/RPM: /usr/bin/vyomi (primary) and /usr/bin/cloud-learn (shim) installed by the package
  • Scoop: scoop install vyomi is the new canonical; scoop install cloud-learn keeps working via a separate deprecation manifest that prints the rename notice on install
  • Docker Compose: unaffected — the container runs python server.py directly
• Bash completion now registers against both vyomi and cloud-learn so tab-complete works on legacy invocations.
• Brew formula renamed cloud-learn.rb → vyomi.rb. New canonical install: brew install vyomi-cloud/tap/vyomi. Back-compat: Aliases/cloud-learn → Formula/vyomi.rb symlink in the tap, so brew install cloud-learn continues to work indefinitely (both resolve to the same package). Formula class renamed CloudLearn → Vyomi, license metadata MIT → :cannot_represent (BSL 1.1 isn't in SPDX simple form), homepage now https://vyomi.cloud.
• License: MIT → Business Source License 1.1 with a Vyomi-specific Additional Use Grant. Source-available, not open-source-OSI. Change Date 4 years from release, Change License Apache 2.0. The Additional Use Grant blocks (a) hosting Vyomi as a third-party commercial multi-cloud simulator service, (b) modifying/bypassing tier-enforcement code, (c) rebranding for commercial redistribution. Non-commercial use and internal evaluation remain unrestricted. See LICENSE for full text. Existing forks pre-v2.0.0 retain MIT under the historical commit terms.
• Shim removal slated for v3.0 — users have at least one major version cycle to migrate.

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-2.0.0-1.noarch.rpm
• cloud-learn-2.0.0.tar.gz
• cloud-learn_2.0.0_all.deb

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

Vyomi v1.2.6-rc4

See CHANGELOG.md

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-1.2.6-rc4-1.noarch.rpm
• cloud-learn-1.2.6-rc4.tar.gz
• cloud-learn_1.2.6-rc4_all.deb

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

Vyomi v1.2.6-rc3

See CHANGELOG.md

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-1.2.6-rc3-1.noarch.rpm
• cloud-learn-1.2.6-rc3.tar.gz
• cloud-learn_1.2.6-rc3_all.deb

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

Vyomi v1.2.6-rc2

See CHANGELOG.md

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-1.2.6-rc2-1.noarch.rpm
• cloud-learn-1.2.6-rc2.tar.gz
• cloud-learn_1.2.6-rc2_all.deb

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

CloudLearn v1.2.6-rc1

See CHANGELOG.md

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-1.2.6-rc1-1.noarch.rpm
• cloud-learn-1.2.6-rc1.tar.gz
• cloud-learn_1.2.6-rc1_all.deb

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

CloudLearn v1.2.5

Default-space naming convention. The three out-of-the-box spaces are now aws-default, gcp-default, and azure-default — matching how every other identifier in the appliance and SDK examples talks about per-provider defaults. Previous names (Legacy Workspace, GCP Project, Azure Subscription) were inconsistent and looked like manually-created spaces rather than defaults.

Changed

• Fresh installs now seed three spaces named aws-default, gcp-default, azure-default (was: Legacy Workspace, GCP Project, Azure Subscription). Space IDs are unchanged (space-legacy, space-gcp-default, space-azure-default) so cloudsim_runtime_id / lxd_project_name references in persisted state stay valid.
• Existing installs get a one-shot migration on first v1.2.5 boot (migrate_default_space_names() in core/app_context.py) — renames spaces only when the current name still matches the legacy default. Any space the user renamed themselves is untouched.

Why

The pricing/upgrade flow, the per-cloud console gates, and the docs all reference aws-default etc. as the canonical names. Having the UI show a different label was a needless source of "wait, which space am I in?" confusion for new users.

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-1.2.5-1.noarch.rpm
• cloud-learn-1.2.5.tar.gz
• cloud-learn_1.2.5_all.deb

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

CloudLearn v1.2.4

URL parity: every install path now lands on http://vyomi.local:9000. v1.2.3 made the Multipass-based paths (Brew/.deb/.rpm/Scoop) reachable via mDNS at vyomi.local. This release extends the same hostname to the Docker Compose path so users never have to remember a different URL based on which install method they picked.

Added

• install.sh now adds 127.0.0.1 vyomi.local to /etc/hosts at the end of the one-liner install — idempotent (only inserts if the line is absent), interactive sudo prompt, best-effort DNS-cache flush (macOS dscacheutil, Linux systemd-resolve). Falls back to http://localhost:9000 cleanly if the user declines sudo or /etc/hosts isn't writable.
• INSTALL.md documents the one-time hosts entry as step 5 of the quick-install flow with a "Why vyomi.local?" explainer.
• Portal /install page Docker Compose entry now has a "Step 3: One-time hosts entry so http://vyomi.local:9000 works" with copy-pasteable macOS / Linux / Windows-PowerShell commands. Step 4/5 commands updated to use the new URL.

Fixed

• .env.example image pin bumped to gansudkum/cloud-learn:1.2.4 (was 1.2.2).
• install.sh day-2 hint had the same pull && up -d typo as INSTALL.md before v1.2.2 — fixed to docker compose pull && docker compose up -d.

Why this matters

Before v1.2.3, every install path landed on a different URL (an IP for the appliance, localhost for Compose). v1.2.3 unified the Multipass paths on vyomi.local. v1.2.4 finishes the job — one URL across all 5 install methods on every supported OS.

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-1.2.4-1.noarch.rpm
• cloud-learn-1.2.4.tar.gz
• cloud-learn_1.2.4_all.deb

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

CloudLearn v1.2.3

The appliance is now reachable at http://vyomi.local:9000/ — no more pasting bridged Multipass IPs into a browser. Hostname resolution uses standard mDNS (Bonjour on macOS, avahi on Linux, native mDNS on Windows 10 1809+) so it works on any local network that doesn't actively block multicast, with zero /etc/hosts modification.

Added

• cloud-init.yaml now installs avahi-daemon + libnss-mdns, sets the VM hostname to vyomi, patches /etc/nsswitch.conf to query mDNS, and enables the avahi service. A fresh cloud-learn up makes vyomi.local resolvable from the host within seconds of boot.
• ensure_vyomi_mdns_active() runs on every cloud-learn up and idempotently brings legacy VMs (launched before v1.2.3) up to the same state. Fast no-op (~50 ms) when avahi is already publishing; ~30s one-time fix-up otherwise. Bounded by a 60s wall-clock cap so it can never hang the launcher.
• print_url_banner() probes vyomi.local:9000/healthz and prefers the hostname URL when reachable. The bridged IP is always shown as a fallback so users on multicast-blocked networks (corporate, some VPNs) still have a copy-pasteable URL.
• Phase 8 status output now shows both URLs as soon as the VM IP is known, so the user can open either in a browser while the health check is still polling.

Fixed

• The portal /install page's hero subtitle previously claimed all paths land on http://localhost:9000 — accurate only for Docker Compose. Now the copy distinguishes the Multipass-based paths (Brew/.deb/.rpm/Scoop → http://vyomi.local:9000) from Compose (still http://localhost:9000). The "After install" block has the same fix.
• Per-method comment examples in install_catalog.py swapped http://192.168.x.x:9000 for http://vyomi.local:9000, matching what the launcher actually prints.

Operational notes

• Networks that block multicast (corporate switches with IGMP snooping misconfigured, some hotel WiFi, certain VPN clients) will fail mDNS resolution. The launcher's URL banner shows the IP fallback for exactly this case.
• Linux server installs without libnss-mdns on the HOST won't resolve vyomi.local from that host either — apt install libnss-mdns once on the host and it works. Default on Ubuntu desktop, Fedora, Debian with the standard meta-packages.
• Windows users on Windows 10 builds older than 1809 (October 2018 Update) need Apple Bonjour Print Services installed, or they should use the IP fallback.

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-1.2.3-1.noarch.rpm
• cloud-learn-1.2.3.tar.gz
• cloud-learn_1.2.3_all.deb

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

CloudLearn v1.2.2

Distribution-parity release: every package-manager install path that ships cloud-learn now gets the same first-launch experience — cloud-learn up detects missing Multipass and installs it via the platform-native package manager. Closes the Windows (Scoop) and Linux-without-snapd gaps that v1.2.1 left open. Also fixes a docker-compose .env.example bug that made the Compose install path 404 on docker compose pull.

Added

• maybe_install_multipass() now covers Windows. When PARENT_OS=windows (Scoop install path), the launcher detects winget on PATH, shows the same yellow notice box used on macOS/Linux, and runs winget install --id Canonical.Multipass --accept-package-agreements --accept-source-agreements. Honors -y / CLOUD_LEARN_YES=1 and gracefully degrades if winget isn't on PATH (e.g. Windows Server without App Installer).
• Snapd-bootstrap guidance on Linux. When snap itself isn't on PATH (common on RHEL/Fedora/SUSE minimal images), the launcher detects which distro package manager is available (apt-get / dnf / zypper) and prints the exact 2-3 commands to install snapd + enable its socket + install Multipass. No more silent fall-through to "multipass is not installed" with no recovery path.

Fixed

• .env.example image pin was broken. Was CLOUDLEARN_SIMULATOR_IMAGE=cloudlearn/simulator:1.0.0 — wrong namespace (cloudlearn/simulator does not exist on Docker Hub) AND stale version (months behind). Any user running cp .env.example .env && docker compose pull got pull access denied. Now pins to gansudkum/cloud-learn:1.2.2 (the real, current image). Comment explains how to opt into rolling :latest updates.
• INSTALL.md docker-compose upgrade step clarified. docker compose up does NOT auto-pull on existing images — added an explicit docker compose pull && docker compose up -d recipe with a note about --pull always semantics. The previous one-liner docker compose pull && up -d was a typo (missing the second docker compose).

Coverage matrix after this release

Install path	OS	Auto-install command
Brew	macOS	brew install --cask multipass
DEB / RPM	Linux + snapd	sudo snap install multipass
DEB / RPM	Linux no-snapd	Step-by-step instructions for apt-get / dnf / zypper
Scoop	Windows	winget install Canonical.Multipass
Docker Compose	any	N/A — appliance runs inside Docker, no host Multipass needed

Why this matters

v1.2.1 closed the macOS-via-brew gap. v1.2.2 closes the same gap on every OTHER package-manager install path users actually use. A first-time Windows user who runs scoop install cloud-learn followed by cloud-learn up now gets the same one-prompt-and-go experience their macOS counterpart does.

---

Artifacts

• SHA256SUMS
• cloud-learn-0.1.0.tar.gz
• cloud-learn-1.2.2-1.noarch.rpm
• cloud-learn-1.2.2.tar.gz
• cloud-learn_1.2.2_all.deb

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