Hypervisor panel -> VirtConsole: rebrand + v3.2.0, still from $2/node/mo

Some of you know our panel as Hypervisor - the KVM/Proxmox control panel a few LET providers run their fleets on. We renamed it. Hypervisor is now VirtConsole, and 3.2.0 is the first release carrying the new name.

Why? Honestly: we picked the most generic word in virtualization and paid for it daily. You can't Google the product, reviews of us return VMware docs, and in our own manual "the hypervisor" could mean the product or the KVM host it manages. Full reasoning: https://virtconsole.com/blog/rebranding-to-virtconsole

What does NOT change (before anyone asks):

  • Your license, pricing and terms - untouched
  • Running installs keep working; updates via the same in-panel updater
  • hypervisor.io endpoints keep answering through the whole transition
  • Same team, same codebase, same roadmap

What's new in 3.2.0 besides the name:

  • Windows SPLA licensing - enter your keys once, Windows guests activate on deploy, keys never reach the guest or the customer
  • Managed SSL - account-level certs, SNI multi-cert on managed LBs, Let's Encrypt issue/renew + expiry alerts
  • Built-in support desk - SLA tracking, scanned attachments, optional AI triage
  • Import Doctor - pull VMs in from other platforms (Windows included); driver/boot issues detected and repaired offline so they boot first try
  • System DNS - host public zones, with delegation checks that tell you exactly what's misconfigured
  • One installer for Debian 11/12/13, Ubuntu 22.04/24.04/26.04, RHEL-family 9/10

Fresh install (as root - no sudo needed, minimal Debian friendly):

curl -fsSL https://packages.virtconsole.com/master/install.sh | bash

Existing installs move to the new layout with one command per node (hypervisor nodes first, then panel) - VMs, data, license and pricing preserved:

curl -fsSL https://packages.virtconsole.com/virtconsole-migrate.sh | DEPLOY_RELEASE=1 bash

Full feature set on every plan, from $2/hypervisor/month, free trial: https://virtconsole.com

Happy to answer anything here - stack questions, migration from Virtualizor/SolusVM/Proxmox, feature requests.

Comments

  • imokimok OG Not Administrator

    -1 for mentioning the OGF

  • -1 for including Debian 11 that has reached EOL

    We accept Karma donations for the last flan. 🍮 affbrr

  • Does it use AI now?

  • ReadyDedisReadyDedis ProviderOG
    edited September 16

    We just shipped VirtConsole 3.2.2 (plus a small 3.2.2.1 patch, more on that at the end). For anyone who has not seen it before: VirtConsole is a self-hosted control panel for KVM hosting. One master, any number of nodes, customer panel, admin panel, REST API, hourly billing or WHMCS/Blesta/HostBill/Paymenter, VPCs, load balancers, Kubernetes, managed databases, S3. This release adds a new compute type next to all of that.

    MicroVMs (Firecracker)

    Your customers can now run Firecracker microVMs that boot in seconds and bill per second of vCPU and RAM plus disk per hour. It is one resource with three parts:

    • Images. Build from a Dockerfile on top of a platform base image, import any container image from a registry, or point at a git repo. Base images are published and signed by us and synced into your install automatically: Debian 13, Ubuntu 24.04, Ubuntu 26.04, AlmaLinux 10, Rocky Linux 10, Amazon Linux 2023. Custom images inherit the base's SSH daemon and agents, so a FROM debian:13-slim Dockerfile still gives you a box you can SSH into.
    • MicroVMs. Public IP, VPC address or both, exactly like a KVM instance. VPC-only microVMs leave through the VPC NAT gateway and the same security groups apply. SSH keys from the account are injected before first boot. Optional lifetime cap (pause or kill on timeout), idle pause, pause/resume with memory kept, HTTPS ingress on a wildcard domain or a custom domain with certificates handled for you, web shell, streaming logs, live metrics.
    • Connectors. Install the GitHub App or register a GitLab runner token and every CI job gets a fresh microVM on the plan you pick, torn down when the job ends.

    E2B-compatible API

    The sandbox API speaks the same wire protocol as E2B, so existing E2B code runs against your panel with two environment variables (E2B_API_KEY, E2B_API_URL=https:///api/e2b). The API keys page ships quick starts for Python, JavaScript, the CLI, cURL, Anthropic and OpenAI. If you have been getting asked for "sandboxes for AI agents", this is a way to sell them from hardware you already own.

    For the admin side

    Enable it per location (hypervisor group), flip the MicroVM engine on a node's card, and a Readiness page tells you what is still missing before customers can use it. Plans carry vCPU, memory, disk and the three prices; plan groups map plans to locations. Admin pages list every customer microVM with the node's live view.

    Also in 3.2.2

    • Provider-managed backups: a group-level default backup policy every new instance inherits, per-node throttling, and a "rebuild from backups" action for a dead node.
    • location_id in the customer API, OpenTofu provider (v0.4.0) and MCP server; hypervisor_group_id still works as an alias.
    • ConfigServer Firewall coexistence on KVM nodes: the agent detects CSF and stops fighting it for the INPUT chain.
    • Redesigned MicroVM detail pages and a pile of node-operations docs.

    Links

  • @ascicode said:
    Does it use AI now?

    Only if you want it to?

Sign In or Register to comment.