MikroTik's Cloud Hosted Router is RouterOS packaged as a virtual machine image that runs on standard hypervisors. For ISPs, CHR opens up use cases that physical RouterOS hardware does not address well: a RADIUS fallback server co-located with the billing platform, a virtual CGNAT router scaled by VM CPU allocation rather than hardware purchase, a management plane router running on your existing server infrastructure, or a development and test environment that mirrors your production configuration without requiring dedicated hardware.

CHR Licensing

CHR uses a different licensing model from physical RouterOS. License tiers determine the maximum network interface throughput the CHR instance is permitted to pass:

Free tier is limited to 1 Mbps per interface, adequate for testing and development but not production service delivery. P1 allows 1 Gbps per interface. P10 allows 10 Gbps. P-Unlimited removes the throughput cap entirely.

Licensing is per CHR instance and is bound to the specific virtual machine rather than to physical hardware. If a CHR instance is moved to different hardware or cloned, the license transfers with the system ID, but cloned instances need separate licenses.

For ISP use cases: a CHR instance handling CGNAT at moderate scale (under 1 Gbps aggregate) runs on a P1 license. A CHR instance used purely for management routing or RADIUS testing runs adequately on a Free trial period or P1. Production core routing at multi-gigabit capacity requires P10 or P-Unlimited.

Hypervisor Compatibility

CHR is distributed as a disk image compatible with: VMware ESXi (OVA format), Hyper-V (VHD format), KVM/QEMU (QCOW2 or RAW format), VirtualBox, Proxmox (using the QCOW2 image), and major cloud providers including AWS, Azure, and GCP through their marketplace or custom image import mechanisms.

For on-premises ISP deployment, KVM on a Linux host or VMware ESXi are the most common platforms. KVM with virtio network drivers delivers the best network performance of the available options, and Proxmox VE (which uses KVM internally) is a practical management interface for ISPs running their own server infrastructure.

Performance Tuning for KVM/Proxmox

The most important performance configuration for a CHR running on KVM is the network driver. Use virtio network interfaces rather than emulated e1000 or RTL8139 interfaces: virtio reduces the CPU overhead of packet processing significantly and enables near-wire-speed throughput at the P-Unlimited tier on adequate hardware.

In Proxmox, create the CHR VM with virtio network interfaces:

# Proxmox network interface configuration for CHR
net0: virtio=<MAC>,bridge=vmbr0,queues=4

The queues=4 parameter enables multi-queue virtio, which distributes packet processing across multiple CPU cores and significantly improves throughput for high packet-rate workloads like CGNAT.

Allocate CPU cores based on the workload: a CHR handling connection tracking for CGNAT at 100,000 concurrent connections needs at least 2 dedicated CPU cores. A CHR used for management routing with low packet rates runs adequately on 1 core. Avoid overcommitting CPU resources shared with other VMs on the same host, particularly for latency-sensitive routing workloads.

ISP Use Cases for CHR

CGNAT offload is one of the most compelling CHR use cases: run connection tracking and NAT on a CHR instance with P1 or P10 licensing and scale by adding CPU rather than buying a new hardware router. CHR CGNAT at 500 Mbps aggregate is achievable on a 4-core VM on modern server hardware.

A development and staging environment for RouterOS configuration testing eliminates the risk of testing changes on production hardware. Configure a CHR instance with your production configuration structure, test changes there first, and deploy to physical hardware only after verification. This is particularly valuable for firewall filter changes, BGP configuration updates, and scripting development.

Management plane routing: for ISPs running out-of-band management networks, a CHR instance handling management routing is simpler to maintain than a dedicated physical router, and its availability is tied to the server's availability rather than requiring separate hardware management.

RADIUS server co-location: while FreeRADIUS is the primary authentication server for most ISPs, a CHR instance configured for RADIUS failback (accepting authentication if the FreeRADIUS server is unreachable) provides an additional layer of availability for authentication without requiring a second physical router.

For operators designing a virtual infrastructure strategy for ISP operations, ISP Consulting & Advisory covers the architecture decisions around physical versus virtual infrastructure. For automating CHR deployments and configuration management through scripting and API, Automation & Integrations covers the automation layer.