Microsoft Announces 'Hyperlight Wasm': Speedy VM-Based Security at Scale with a WebAssembly Runtime

Cloud providers like the security of running things in virtual machines "at scale" — even though VMs "are not known for having fast cold starts or a small footprint..." noted Microsoft's Open Source blog last November. So Microsoft's Azure Core Upstream team built an open source Rust library called Hyperlight "to execute functions as fast as possible while isolating those functions within a VM."

But that was just the beginning... Then, we showed how to run Rust functions really, really fast, followed by using C to [securely] run Javascript. In February 2025, the Cloud Native Computing Foundation (CNCF) voted to onboard Hyperlight into their Sandbox program [for early-stage projects].

[This week] we're announcing the release of Hyperlight Wasm: a Hyperlight virtual machine "micro-guest" that can run wasm component workloads written in many programming languages...

Traditional virtual machines do a lot of work to be able to run programs. Not only do they have to load an entire operating system, they also boot up the virtual devices that the operating system depends on. Hyperlight is fast because it doesn't do that work; all it exposes to its VM guests is a linear slice of memory and a CPU. No virtual devices. No operating system. But this speed comes at the cost of compatibility. Chances are that your current production application expects a Linux operating system running on the x86-64 architecture (hardware), not a bare linear slice of memory...

[B]uilding Hyperlight with a WebAssembly runtime — wasmtime — enables any programming language to execute in a protected Hyperlight micro-VM without any prior knowledge of Hyperlight at all. As far as program authors are concerned, they're just compiling for the wasm32-wasip2 target... Executing workloads in the Hyperlight Wasm guest isn't just possible for compiled languages like C, Go, and Rust, but also for interpreted languages like Python, JavaScript, and C#. The trick here, much like with containers, is to also include a language runtime as part of the image... Programming languages, runtimes, application platforms, and cloud providers are all starting to offer rich experiences for WebAssembly out of the box. If we do things right, you will never need to think about whether your application is running inside of a Hyperlight Micro-VM in Azure. You may never know your workload is executing in a Hyperlight Micro VM. And that's a good thing.
While a traditional virtual-device-based VM takes about 125 milliseconds to load, "When the Hyperlight VMM creates a new VM, all it needs do to is create a new slice of memory and load the VM guest, which in turn loads the wasm workload. This takes about 1-2 milliseconds today, and work is happening to bring that number to be less than 1 millisecond in the future."

And there's also double security due to Wasmtime's software-defined runtime sandbox within Hyperlight's larger VM...

I heard you liked sandboxes?

[Pinky's Brain]

This seems an okay way to mitigate the never ending stream of low level sidechannel attacks. Obscure sidechannels with webassembly translation, protect the webassembly runtime attack surface with a microvm while at it since it's nearly free any way.

React

[phantomfive]

I like React because it allows encapsulation of components, largely separable into libraries.

But it can be so slow sometimes. The browser has to compile and run through a lot of lines of code just to get it started.

This will allow you to write in any language, without that overhead.

Re: React

[josiahbryan]

I think you might be confused, this has nothing to do with React, does it? In other words, these run times and micro VMS have nothing to do with the front end. Necessarily, they don't change how you write code for the front end, unless you're talking about dynamic compiling stuff and streaming server side rendering, is that what you're talking about?

Re:

[phantomfive]

It lets you write code for the browser in any language. So we won't be limited to Javascript anymore.

Malware creators can't wait

[devslash0]

What are the chances that web malware is going to be hinding from detection inside those VMs, too, eh?

Yet another empty promise

[gweihir]

At least the security claims will be. One more in a long string of empty promises. The only thing that will help is better application code.

Re:

[phantomfive]

If you let Javascript run on your browser, then it's not more safe than WebAssembly.

Re:Yet another empty promise

[rocket rancher]

At least the security claims will be. One more in a long string of empty promises. The only thing that will help is better application code.

As a former sysadmin who spent decades riding herd on heterogeneous dev environments for a very large American defense contractor, I can say this is anything but an empty promise. Hyperlight solves real, compliance-choked legacy cruft we used to keep alive with scripts, coffee, and despair—and then had to explain to DoD auditors who couldn’t tell a syscall from a CPU register.

Back then, we had to lock down workloads per team, per contract—each with different languages, runtimes, and risk profiles. Our only real option was to spin up hardened VMs, one per workload, tuned to STIGs [cyber.mil] and stuffed with custom images. Half the time they sat idle, chewing up resources just to meet audit requirements.

Hyperlight flips that model. You get per-function hardware isolation with a micro-VM that spins up in under 2 milliseconds—fast enough to go from zero to secure execution on demand. There’s no kernel boot, no virtual devices, no OS bloat. Just a lean slice of memory, a vCPU, and a Wasm runtime like Wasmtime embedded inside. That’s not marketing; that’s architecture.

The Wasm integration means devs can write in Rust, Python, even JavaScript—and you can still wrap their code in a hardware-enforced box. If someone breaks out of Wasm (which is already hard), they still hit the hypervisor wall. That double-layer containment is exactly what we were begging for when sandbox escapes became a weekly headline.

This isn’t a theoretical whitepaper, either. Microsoft demoed Hyperlight live at KubeCon, handling 1,000 warm-start VM calls at 0.0009s latency. It’s already in the CNCF Sandbox, and Microsoft is already building Azure’s edge services on top of it. You can clone the repo today and watch it work.

No, it won’t fix lousy code. But it will prevent bad code from compromising everything else. For folks under budget and compliance pressure—especially in sensitive environments where security isn’t just a good idea, it’s mandated by the contract—that’s not just helpful. That’s a damn relief.

Re:

[Pinky's Brain]

As long as it's not some monstrosity cobbled together with shell script. How often do those old systems fit neatly in a faas/microservice model?

Re:

[phantomfive]

That double-layer containment is exactly what we were begging for when sandbox escapes became a weekly headline.

Double-layer containment isn't a solution for anything. https://www.youtube.com/watch?... [youtube.com]

If both layers are insecure, then the whole thing is insecure. Don't pretend.

If you like that...

[Gravis Zero]

You're going to love the speed of virtual virtual Linux applications! Not only do they run at 100% of native CPU execution speed but a compiler can ensure that your code will be able to utilize the full range of instructions that your processor supports! Just tack on zero additional lines of code and forget being slowed down like those other virtual machines That's because our virtual machine is entirely virtual as there is nothing between your program and the native OS environment!

Virtual virtual Linux can be yours for the low low price of "just fucking compile your code"!

Interactions?

[algaeman]

Don't most applications interact with something outside their little slice of memory? A disk, a network, a piece of hardware... Does hyperlight provide some abstraction of those?

Re:

[larkost]

A lot of what I write only gets in commands through HTTP, and all the resources it works with are through S3 or database connections. In some cases they use local disks, but only as a cache to deal with files that are larger than memory (less common for me right now).

So as long as network connections are possible, most of my work would be better done in systems like this.

AWS firecracker?

[simlox]

There is a lot of similarity it seems. MS made Azure Functions to have similar functionality as AWS lambda, but it is a lot slower and is biassed towards .NET: No matter what other language is used a .NET instance was still used to connect to the rest of Azure. This new thing might be an attempt to actually compete on technically, not only a check mark in a feature compatibility list.

Web technology to the rescue!

[Waccoon]

Next you'll be telling me that the web browser is the operating system of the future. Oh, wait... we don't need an OS, do we?

Sounds like a disease from Star Trek

[Drishmung]

"He picked up Hyperlight Wasm from an infected tribble! He's dead Jim".

So "secure" C wrapped in a sandbox

[rapjr]

so programmers do not have to write secure C for their apps. This was one of the premises of Java. Seems mainly designed to lock development to Microsoft products.