- Something elided here is that nested virtualization on regular EC2 instances has only been possible since February this year[1] - before this, you had to use a metal EC2 instance to run Firecracker VMs.
1. https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
- Hi, Alex from Unikraft here. One clarification: Browser-Use didn't move away from Unikraft because of any limitation around browser startup times, snapshotting, scale-to-zero, or browser-level autoscaling. Those capabilities worked well and were a key reason they adopted the platform in the first place.
The challenge they encountered was at a different layer: horizontally scaling the underlying EC2 infrastructure. At the time, native EC2 fleet autoscaling wasn't yet supported by the platform, so they chose to take ownership of that part of the stack and build directly on Firecracker.
It's also worth noting that Unikraft is actively working on transparent infrastructure autoscaling (with live migration), so the gap they encountered is being addressed. The article's title may give the impression that unikernels were the bottleneck (they weren’t, and our platform transparently support Linux VMs as well), when in reality the decision was driven by infrastructure orchestration requirements rather than browser runtime capabilities.
As an aside, we love Browser-Use <3 and we still work together closely!
- > cloud browsers. We need to create them constantly, sometimes thousands at a time, and throw them away as soon as sessions end.
Oh that's why the captcha is unpassable for regular people now.
It's just yesterday with another evolution of captcha on lenovo.com I was not able to finish my purchase. Thank you very much, seriously.
- I'm a bit surprised that with all this, they still stuck with Chromium.
We have a much less sophisticated setup in our web-access MCP server[0] where browser instances are spawned as subprocesses and the biggest win in stability, CPU and memory usage we had was in switching from Chrome to Lightpanda[1].
Fitting to the statement at the end of the article, the faster browser to boot might be one that allocates less memory in general.
[0]: https://github.com/EratoLab/web-access-mcp
[1]: https://lightpanda.io
- > Next: skip Chromium startup
> This is complex, as a running browser has open devices, timers, graphics state, network state, and fingerprint state.
Hmm, can't you just keep a set of browsers already running, like a warm pool, ready to assign to an incoming request? The latency would be close to zero for the user. You'd need some prediction logic to expand / contract the warm pool based on traffic patterns, but that seems like the easiest solution to me.
- Very cool to see more use of userfaultfd, really powerful API because you can fully control how and from where memory is loaded during a pagefault.
by timojeajea
3 subcomments
- We run a screenshot API (ApiFlash) with Chromium packaged in an AWS Lambda container image instead of Firecracker on EC2. AWS Lambda gives you the isolation and autoscaling for free which is ideal for spiky stateless work like screenshots. I believe we get mostly the same benefits compared to browser-use solution but with a much much simpler architecture. The tradeoff is the AWS lambda cold starts, but in practice sequential AWS Lambda invocations actually reuse a hot function. As a result, with a large enough volume, spikes are smoothed and cold starts are not that frequent.
by losteric
23 subcomments
- > Plain headless Chromium is easy to detect by websites with anti-bot measures. Plain headless Chromium avoided getting blocked by websites only 2% of the time, according to our stealth benchmark.
> Our browsers avoid blocks 81% of the time on our stealth benchmark, and 84.8% on Halluminate BrowserBench, the highest of any provider.
Seems very unethical, no? Who uses service providers like this? The whole point of anti-bot measures is to get rid of bots - you are not wanted there.
These kinds of services inevitably make the web more human-hostile and expensive. Websites will continue pushing back on automated usage, meaning more hurdles to access content.
No doubt part of why we see this push for verified ID on the web - not just age gating and "protect the children", but also protect sites from bots, and protect ad revenue (not a statement of support; just seems like an obvious higher order effect)
- Firecracker is fantastic technology. I'm using it for my interviewing startup to run isolated runtimes for coding interviews (and personal workspaces), and it's been rock solid and incredibly lightweight. Interfacing with it through the Go SDK has been a piece of cake, too.
by rbbydotdev
2 subcomments
- > The catch is that regular EC2 is already a VM. AWS runs our host inside its own isolation layer, and then we run browser VMs inside that host. In other words, every browser is a VM inside a VM.
yes but i think there is specifically some ec2s which give you hypervisor access and thereby firecracker too - someone correct me if im wrong?
- > Unikraft needed an engineer to add capacity by hand
This seems a little unfair - the _architecture_, as designed, required the human in the loop. The tool doesn’t require it.
by SomaticPirate
3 subcomments
- What is firecracker needed? Couldn’t this just run in a container directly? I understand some of the isolation concerns but a browser and container breakout is a billion dollar CVE, no?
by sandGorgon
3 subcomments
- have you tried running android browsers ? we run RL workloads using android browsers. We are having to maintain a fork of https://github.com/budtmo/docker-android/ and android chrome on top. We would rather use browser-use if it had that support.
P.S. we do maintain our fork of a browser for rubric computation...but that is not relevant for this. The infrastructure is what we are looking for.
- Pretty light on details, heavy on fluff. 9.8s to 3.1s was userfaultd + hugepages, 500ms was PS/2 mouse and… where is the rest of the time to get to 400ms?
- Running in firecracker is fine but if you want density you can run them in containers.
https://hub.docker.com/r/kasmweb/chrome
- Just use something like https://shellbox.dev instead of FireCracker inside ec2. Much simpler, boxes are up in a couple of seconds, and it is way cheaper.
- No mention of the tools/methods used to do the profiling, I think that would be the most interesting part.
Also a bit surprising that a checkpoint with the browser running wouldn't just work. Is this some quirk of firecracker?
- > During a burst in traffic, the system, instead of reacting on its own, required humans to adjust it.
Isn't this solvable with autoscaling? how is this not an issue with Firecracker as well?
by johnsmith1840
1 subcomments
- Saving state before launch of the browser for quick startup is interesting but how do you configure it? I suppose you don't? Or post configure?
- The article doesn't mention docker at all. I don't understand why containers are not viable solution for headless browsers.
by wewewedxfgdf
2 subcomments
- But Firecracker is not compatible with GPU for Chrome, is that right?
That means Chrome is slow - quite the tradeoff.
by anonymous344
0 subcomment
- can i use these from python script without any ai?
i need a small data retriever that wont get blocked, so no same ip every time
by rbbydotdev
3 subcomments
- crazy that the maker of chrome(google) and also the owner of a massive amount of cloud services has not made a cloud product identical to this yet
- to do this on non `.metal` instances, you would need to patch kernel right? PVM patch requried?
by GrinningFool
1 subcomments
- The Internet is drowning in bots, everyone who hosts a site or service is paying the price. At least we have companies like this to make the problem worse.
by aussieguy1234
0 subcomment
- >Unikraft does not have good built-in autoscaling, so an engineer had to change a variable, manually adding more instances.
>During a burst in traffic, the system, instead of reacting on its own, required humans to adjust it. This caused problems: one load test brought down production for 45 minutes. So we rebuilt our setup on Firecracker.
It shouldn't need to have autoscaling built in. If the variable is adjustable, why couldn't monitoring happen that sets off a process to adjust the variable when traffic spikes?
- Kubernetes + Kata would have helped with scaling here, I think.
by andrewstuart
1 subcomments
- How many tabs do you use per server?
- Just hot stage a bunch of VMs and then there is no startup time. Every time someone finishes, just start another one and leave it running waiting for the next customer.
by jauntywundrkind
1 subcomments
- I love that they start no no core pinning, then switch-over to having cores pinned.
This could be a bit of a tricky one, but I'd expect Checkpoint Restore In Userspace eventually tackles a lot of this. An image of a running Chromium process on a tmpfs (in-memory filesystem) that can just be launched endlessly tackles the memory slowdown problem, eliminates conventional startup costs. This feels like an ideal CRIU use case.
I imagine there's a lot of things Chrome needs to run though, bits of state to save/restore.
- How do you handle browser sessions?
by iririririr
1 subcomments
- > Plain headless Chromium is easy to detect by websites with anti-bot measures.
what a disgusting business model. they are central to the main bot problem of our time. any one with morals would expect those systems to respect robots.txt and announce themselves via user agent strings.
disgusting and i hope they crash and burn. i will actively spend time today looking for open source projects detecting their browsers and start contributing.
- [flagged]
- [flagged]
- [flagged]
by codelong888
0 subcomment
- [flagged]
- [dead]
by huflungdung
0 subcomment
- [dead]
- [flagged]
- [flagged]
- fancy terms aside... they likely just run alpine linux.
- “ click this button, type this text, read this page, take this screenshot.”
You left in the Ai’s instructions. lol
Interesting read though, thanks
Hacker News