Netlify's engineers, who now run Edge Functions on Unikraft, wrote it better than we ever have: "V8 isolates, no matter their name, do not provide this level of isolation."
Here is what they built on our platform instead. Every function gets a service ID that is a hash of its spec plus the site info. Different code or different env vars never share a microVM, so a compromised deploy can't poison other customers or the compute layer underneath.
The numbers behind that: a hypervisor is ~200 to 250k lines of code you have to trust. A V8 isolate is ~47M. Containers don't contain. Isolates don't isolate. Hardware does.
🔗 Full story: netlify.com/blog/edge-func…
Here is what they built on our platform instead. Every function gets a service ID that is a hash of its spec plus the site info. Different code or different env vars never share a microVM, so a compromised deploy can't poison other customers or the compute layer underneath.
The numbers behind that: a hypervisor is ~200 to 250k lines of code you have to trust. A V8 isolate is ~47M. Containers don't contain. Isolates don't isolate. Hardware does.
🔗 Full story: netlify.com/blog/edge-func…
1
2
7
334
Netlify now runs Edge Functions on Unikraft. They moved from V8 isolates to microVMs on our platform and published the numbers. Median warm invocation went from 25 to 40ms down to **~5 to 6ms**. p99 is 47.4% faster. Log delivery is 5x faster. Availability sits at 99.998%. All of illion Edge Functions a day**.
To boot, all of this with (1) the same pricing (2) no migration for their customers and (3) now running on strongly-isolated microVMs, not isolates.
All numbers are Netlify's own, from their engineering writeup.
🔗 Full story: netlify.com/blog/edge-func…
To boot, all of this with (1) the same pricing (2) no migration for their customers and (3) now running on strongly-isolated microVMs, not isolates.
All numbers are Netlify's own, from their engineering writeup.
🔗 Full story: netlify.com/blog/edge-func…
1
0
21
741
felipehuici retweeted
Introducing Expand Fetch, a new way to scrape and crawl the web.
Your agent has never seen the web. No wonder it gets basic questions wrong.
Traditional Markdown APIs lose critical details. So we trained two System one models to change that:
Iris, a vision model that sees erving tables, icons, and layouts.
X-Ray, a JSON model that uncovers the hidden data behind every page.
Every fetch also comes with a Wayback Machine. Every line links back to its source, so you can verify exactly what your agent saw.
Three products. One API.
On our benchmark of 1,094 questions across 326 challenging web pages, agents using Expand got 74% right. The next best API got 55%.
Available today at $1 per 1,000 fetches.
Try it at expand.ai
Your agent has never seen the web. No wonder it gets basic questions wrong.
Traditional Markdown APIs lose critical details. So we trained two System one models to change that:
Iris, a vision model that sees erving tables, icons, and layouts.
X-Ray, a JSON model that uncovers the hidden data behind every page.
Every fetch also comes with a Wayback Machine. Every line links back to its source, so you can verify exactly what your agent saw.
Three products. One API.
On our benchmark of 1,094 questions across 326 challenging web pages, agents using Expand got 74% right. The next best API got 55%.
Available today at $1 per 1,000 fetches.
Try it at expand.ai
166
161
1,182
423,232
Now for something new: just-in-time, millisecond remote desktop functionality 🔥
In this short video:
1. We start a normal microVM with no such functionality
2. We click on the "Desktop" tab and we get a warning that this is a plain microVM and so it cannot show a desktop (sad, est inserting a Desktop (VNC) plugin into the LIVE microVM
4. Clicking on the button does so, in milliseconds, and the display appears 🥳
5. The platform can remove the plugin if not needed, also dynamically
Dynamic, scale to zero millisecond remote desktop envs are now here! 🚀
Coming soon to a Unikraft dashboard near you!
In this short video:
1. We start a normal microVM with no such functionality
2. We click on the "Desktop" tab and we get a warning that this is a plain microVM and so it cannot show a desktop (sad, est inserting a Desktop (VNC) plugin into the LIVE microVM
4. Clicking on the button does so, in milliseconds, and the display appears 🥳
5. The platform can remove the plugin if not needed, also dynamically
Dynamic, scale to zero millisecond remote desktop envs are now here! 🚀
Coming soon to a Unikraft dashboard near you!
1
2
20
915
To dashboard or to CLI? That is the question! 🤔
The answer: both! 🚀
We have now integrated our CLI directly into the dashboard, so you can now get the best from both worlds: whatever's easier by clicking you can click to do, whatever's best for typing or scripting you can do l react accordingly.
Thanks to Cezar Crăciunoiu Jesús Enrique Cartas Rascón and the rest of the team for putting this togeher! 🔥
The answer: both! 🚀
We have now integrated our CLI directly into the dashboard, so you can now get the best from both worlds: whatever's easier by clicking you can click to do, whatever's best for typing or scripting you can do l react accordingly.
Thanks to Cezar Crăciunoiu Jesús Enrique Cartas Rascón and the rest of the team for putting this togeher! 🔥
1
1
7
355
felipehuici retweeted
Felipe Huici, CEO and Co-Founder at Unikraft, on the Linux kernel failures that only surface when you scale to 10,000 VMs:
1
1
1
242
Release 14 of our platform, Harpalyke (another Jupiter moon, of course), is now out.
First, a feature we’re very excited about: GPU timesharing, by which I mean the ability for multiple VMs to share a single GPU (or GPU slice) transparently. Essentially, we now support the same scale to zero and snapshotting dynamics that you’d expect from our platform when using CPUs, but applied to GPUs. You can now oversubscribe GPUs, and whenever one goes idle, very quickly (eg, 1-2 seconds) suspend and then resume another workload or VM. And this of course then lays the groundwork for GPU workload migration, coming up soon.
Second, we’ve added support for dynamic vertical memory and vCPU scaling. Up to now, sizing a VM has always meant guessing its peak consumption at start time. Worse, if you size for the peak, you pay for memory that sits idle most of the time. If, instead, you size for the average, the VM struggles when traffic arrives and there may be an OOM error in its near future. With this release you no longer have to guess right: give a VM a range, and it grows and shrinks its memory and vCPUs while it runs: memory is added when the guest needs it and handed back when it does not, and the guest takes extra vCPUs when work is queuing up and releases them when no longer needed.
Finally, we’ve done several major improvements to the dashboard. One that I find particularly cool is the ability to, at a click of a button, be dropped into an interactive shell for any microVM that you’re running. What’s really cool about it is that when you click that button, a plugin is dynamically added to the microVM, extending the microVM’s endpoints and functionality to allow for the shell to work – all of that in milliseconds, as with everything in our platform.
More on each of these over the next few days!
Release 14 is rolling out now. Enterprise features ship with the Harpalyke platform packages, while the CLI, dashboard and SDK updates are live for everyone. Full write up link at unikraft.com/blog/harpalyke…
First, a feature we’re very excited about: GPU timesharing, by which I mean the ability for multiple VMs to share a single GPU (or GPU slice) transparently. Essentially, we now support the same scale to zero and snapshotting dynamics that you’d expect from our platform when using CPUs, but applied to GPUs. You can now oversubscribe GPUs, and whenever one goes idle, very quickly (eg, 1-2 seconds) suspend and then resume another workload or VM. And this of course then lays the groundwork for GPU workload migration, coming up soon.
Second, we’ve added support for dynamic vertical memory and vCPU scaling. Up to now, sizing a VM has always meant guessing its peak consumption at start time. Worse, if you size for the peak, you pay for memory that sits idle most of the time. If, instead, you size for the average, the VM struggles when traffic arrives and there may be an OOM error in its near future. With this release you no longer have to guess right: give a VM a range, and it grows and shrinks its memory and vCPUs while it runs: memory is added when the guest needs it and handed back when it does not, and the guest takes extra vCPUs when work is queuing up and releases them when no longer needed.
Finally, we’ve done several major improvements to the dashboard. One that I find particularly cool is the ability to, at a click of a button, be dropped into an interactive shell for any microVM that you’re running. What’s really cool about it is that when you click that button, a plugin is dynamically added to the microVM, extending the microVM’s endpoints and functionality to allow for the shell to work – all of that in milliseconds, as with everything in our platform.
More on each of these over the next few days!
Release 14 is rolling out now. Enterprise features ship with the Harpalyke platform packages, while the CLI, dashboard and SDK updates are live for everyone. Full write up link at unikraft.com/blog/harpalyke…
0
0
2
220
2ms. That's P99 cold-start time for a microVM running live Netlify Edge Functions traffic, in production, not a benchmark.
Here's the whole path, in four hops:
1. Request lands at the nearest edge node.
2. Rendezvous hashing picks the compute node, deterministic, so the same the same node and its cache stays warm.
3. 98.8% of the time, the image's already there. Boot the microVM in <1ms (2ms at P99) and run.
4. The other 1.2%? Pull from origin (~9ms), cache it, never pull it again.
(Stickiness breaks on purpose under a traffic spike, load spreads across nodes instead of melting one.)
Netlify owns the routing, the hashing, the node fleet. We own what happens next: a hardware-isolated VM, booted and running in single-digit milliseconds, at their scale.
Here's the whole path, in four hops:
1. Request lands at the nearest edge node.
2. Rendezvous hashing picks the compute node, deterministic, so the same the same node and its cache stays warm.
3. 98.8% of the time, the image's already there. Boot the microVM in <1ms (2ms at P99) and run.
4. The other 1.2%? Pull from origin (~9ms), cache it, never pull it again.
(Stickiness breaks on purpose under a traffic spike, load spreads across nodes instead of melting one.)
Netlify owns the routing, the hashing, the node fleet. We own what happens next: a hardware-isolated VM, booted and running in single-digit milliseconds, at their scale.
8
1
33
2,600
OpenAI Codex is the latest, not the first. Pillar Security found sandbox escapes across Cursor, Codex, Gemini CLI and Antigravity in July 2026, and Accomplish AI's Oren Yomtov found two more Codex-specific bugs in August, reported August 12 and disclosed September 20.
This isn't tern across the whole category. Every major coding agent shipped in the last year has had to patch its way out of a sandbox escape, and the fixes keep landing about a week after disclosure instead of never needing to happen.
If you're running agents that execute arbitrary code, critical or multi-tenant, on a container or a process boundary, you're playing with fire. The fix shouldn’t be faster patch cadence, that’s treating the symptom; curing the disease should be about not sharing the enforcement boundary with the code you don't trust in the first place.
Every agent session on our platform is its own hardware-isolated VM with its own kernel. A bug in the sandbox logic there doesn't hand an attacker the host, because there's no shared kernel or shared process to escape into.
🔗 Full story here: bleepingcomputer.com/news/security/…
This isn't tern across the whole category. Every major coding agent shipped in the last year has had to patch its way out of a sandbox escape, and the fixes keep landing about a week after disclosure instead of never needing to happen.
If you're running agents that execute arbitrary code, critical or multi-tenant, on a container or a process boundary, you're playing with fire. The fix shouldn’t be faster patch cadence, that’s treating the symptom; curing the disease should be about not sharing the enforcement boundary with the code you don't trust in the first place.
Every agent session on our platform is its own hardware-isolated VM with its own kernel. A bug in the sandbox logic there doesn't hand an attacker the host, because there's no shared kernel or shared process to escape into.
🔗 Full story here: bleepingcomputer.com/news/security/…
1
0
0
247
With the 90-minute Lambda timeout AWS announced September 9, AWS is telling developers to handle their own retries, keep credentials valid for the full run, and make writes idempotent so a duplicate execution doesn't double-charge a customer or write the same row twice.
That's ng-running serverless function. Once it runs long enough, you're back to solving the same problems you'd solve running your own long-lived server, just without the tooling built for one.
We think the better fix is not making functions run longer, it's making them not need to. *Scale-to-Zero* on our platform resumes a VM from its exact memory state in under 10ms, so a workload can suspend and pick back up mid-task instead of staying alive and awake for 90 minutes straight just to avoid paying a cold start twice.
Say hello to state you can suspend and resume for free, and goodbye to babysitting a function for an hour and a half so it doesn't double-charge someone.
🔗 Full story here: infoq.com/news/2026/09/l…
That's ng-running serverless function. Once it runs long enough, you're back to solving the same problems you'd solve running your own long-lived server, just without the tooling built for one.
We think the better fix is not making functions run longer, it's making them not need to. *Scale-to-Zero* on our platform resumes a VM from its exact memory state in under 10ms, so a workload can suspend and pick back up mid-task instead of staying alive and awake for 90 minutes straight just to avoid paying a cold start twice.
Say hello to state you can suspend and resume for free, and goodbye to babysitting a function for an hour and a half so it doesn't double-charge someone.
🔗 Full story here: infoq.com/news/2026/09/l…
0
0
1
264
felipehuici retweeted
The Firecracker MicroVMs behind Netlify Edge Functions start in about 2ms at p99. Once a function's JavaScript server starts listening, we snapshot the VM. Idle functions scale to zero, and the next invocation restores from that memory-mapped snapshot, so the VM starts executing before the whole snapshot is back in memory.
@UnikraftCloud built that lifecycle, and we worked closely with their team through the migration.
netlify.com/blog/edge-func…
@UnikraftCloud built that lifecycle, and we worked closely with their team through the migration.
netlify.com/blog/edge-func…
1
5
10
2,817
Alex just posted a full walkthrough of going from a fresh signup to a running app on our platform, and the first few minutes are the part worth sending to anyone still deciding whether to try it.
No credit card required for the free tier. Install our CLI with a one line 's `brew` on macOS or a `.deb`/`.rpm` on Linux, then log in and you're looking at the dashboard.
From there our docs have dozens of guides across languages and frameworks, and our GitHub examples repository has pre-built applications if you'd rather start from working code than a blank folder.
Full video at youtube.com/watch?v=0KNUIJ…
No credit card required for the free tier. Install our CLI with a one line 's `brew` on macOS or a `.deb`/`.rpm` on Linux, then log in and you're looking at the dashboard.
From there our docs have dozens of guides across languages and frameworks, and our GitHub examples repository has pre-built applications if you'd rather start from working code than a blank folder.
Full video at youtube.com/watch?v=0KNUIJ…
1
1
8
502
The proof is in the instance list, not a slide.
Once Alex's app is deployed, `unikraft instance ls -w` shows it sitting in `standby`, scaled to zero, with a boot time of 6.89 milliseconds.
Hit the URL and it serves the request immediately. Stop sending traffic and it scales ldown window, ready to boot again in single digit milliseconds the next time someone shows up.
Full video at youtube.com/watch?v=0KNUIJ…
Once Alex's app is deployed, `unikraft instance ls -w` shows it sitting in `standby`, scaled to zero, with a boot time of 6.89 milliseconds.
Hit the URL and it serves the request immediately. Stop sending traffic and it scales ldown window, ready to boot again in single digit milliseconds the next time someone shows up.
Full video at youtube.com/watch?v=0KNUIJ…
0
0
2
341
Time sharing a GPU across many VMs, with scale to zero dynamics?? 🤔
We're used to time sharing a CPU, but GPUs are different beasts -- until now 🚀 ! We now support the ability to quickly snapshot and scale to zero VMs that use a @nvidia GPU (or GPU slice), which means that ime share a single GPU so idle GPUs need no longer apply!
This short video shows this in action, hope you like it 🙂
We're used to time sharing a CPU, but GPUs are different beasts -- until now 🚀 ! We now support the ability to quickly snapshot and scale to zero VMs that use a @nvidia GPU (or GPU slice), which means that ime share a single GPU so idle GPUs need no longer apply!
This short video shows this in action, hope you like it 🙂
2
1
13
614
Netlify now runs every tier of Edge Functions as microVMs on our platform!
That product handles more than 20 billion requests a month, for customers from startups up to Figma and Riot Games.
The number we're proudest of: median per-request overhead dropped from about 50ms to e Netlify moved from software isolates to hardware-isolated VMs. Usually you trade isolation for speed. Here they got both.
VM startup on Netlify's fleet now runs at 2ms P99: selecting a machine, allocating and booting the VM, and getting the customer's code on disk. The deployment holds 99.998% measured availability, including through traffic spikes of 200x a customer's normal volume.
More this week: the case study behind the migration, and the engineering story our team wrote about building it.
Link to the full story: unikraft.link/netlify-x
That product handles more than 20 billion requests a month, for customers from startups up to Figma and Riot Games.
The number we're proudest of: median per-request overhead dropped from about 50ms to e Netlify moved from software isolates to hardware-isolated VMs. Usually you trade isolation for speed. Here they got both.
VM startup on Netlify's fleet now runs at 2ms P99: selecting a machine, allocating and booting the VM, and getting the customer's code on disk. The deployment holds 99.998% measured availability, including through traffic spikes of 200x a customer's normal volume.
More this week: the case study behind the migration, and the engineering story our team wrote about building it.
Link to the full story: unikraft.link/netlify-x
5
10
55
2,914
Oren Yomtov of Accomplish AI found two separate ways out of OpenAI Codex's sandbox this year, disclosed September 20. One read an auth token straight out of a shared V8 heap to impersonate a trusted process. The other abused a patch tool to write outside its own directory and ell config file.
Different bugs, same root cause: the thing enforcing the sandbox was running inside the sandbox it was supposed to contain.
Containers don't contain, and isolates don't isolate. This is the same failure mode wearing different clothes, whether it's a process boundary, a V8 isolate, or a container runtime.
Every session on our platform gets its own microVM with hardware-level isolation and its own kernel, not a shared one. When a workload needs to execute commands or touch the filesystem, that goes through our *Plugin API* over an authenticated endpoint, not as code the workload can reach into directly.
🔗 Full story here: bleepingcomputer.com/news/security/…
Different bugs, same root cause: the thing enforcing the sandbox was running inside the sandbox it was supposed to contain.
Containers don't contain, and isolates don't isolate. This is the same failure mode wearing different clothes, whether it's a process boundary, a V8 isolate, or a container runtime.
Every session on our platform gets its own microVM with hardware-level isolation and its own kernel, not a shared one. When a workload needs to execute commands or touch the filesystem, that goes through our *Plugin API* over an authenticated endpoint, not as code the workload can reach into directly.
🔗 Full story here: bleepingcomputer.com/news/security/…
0
1
3
335
We're hiring a GTM Engineer at Unikraft. Python/TypeScript, REST APIs, real AI/agent experience. Automate lead enrichment, campaign pipelines, outbound workflows with the founding GTM team. Founder-led, remote (CET +-2hrs).
careers.unikraft.com/jobs/8352919-g…
careers.unikraft.com/jobs/8352919-g…
17
6
53
4,088
An engineer on SpaceX AI's Grok team ships around 2,000 pull requests a month through an agent workflow called pstack. That's roughly 100 PRs a day (September 2026).
Do the math on human review: one person looking at every one of those gets five minutes per PR, for the whole gets done.
Verification, not the model, is the actual ceiling on how fast agents can ship. An agent that can check its own work keeps going. An agent that can't turns every human reviewer into the bottleneck.
The part that's easy to miss: verification at that volume is also an infrastructure problem. Each attempt needs its own environment, running against real dependencies, ready in seconds, not minutes.
That's what *On-Demand Templates* and *Instance Forking* give you on our platform: boot once, absorb the heavy init, then stamp out a warmed VM in around 10ms, or transparently fork a running VM so a new attempt gets its own isolated copy instantly.
🔗 Full story here: thenewstack.io/agentic-verifi…
Do the math on human review: one person looking at every one of those gets five minutes per PR, for the whole gets done.
Verification, not the model, is the actual ceiling on how fast agents can ship. An agent that can check its own work keeps going. An agent that can't turns every human reviewer into the bottleneck.
The part that's easy to miss: verification at that volume is also an infrastructure problem. Each attempt needs its own environment, running against real dependencies, ready in seconds, not minutes.
That's what *On-Demand Templates* and *Instance Forking* give you on our platform: boot once, absorb the heavy init, then stamp out a warmed VM in around 10ms, or transparently fork a running VM so a new attempt gets its own isolated copy instantly.
🔗 Full story here: thenewstack.io/agentic-verifi…
4
0
9
646