How we run Firecracker VMs inside EC2 and start browsers in less than 1s

browser-use.com

189 points by gregpr07 a day ago


losteric - 6 hours ago

> 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)

sudb - 4 hours ago

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...

mamine - 10 minutes ago

https://youtube.com/shorts/D8FQkof7mNY?feature=share

hobofan - 4 hours ago

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

cgijoe - 3 hours ago

> 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.

timojeajea - 4 hours ago

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.

johnsmith1840 - an hour ago

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?

smnscu - 2 hours ago

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.

SomaticPirate - 3 hours ago

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?

CompuIves - 6 hours ago

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.

rbbydotdev - 6 hours ago

> 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?

amarshall - 2 hours ago

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?

GrinningFool - 5 hours ago

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.

Dibby053 - 4 hours ago

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?

messh - 4 hours ago

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.

sandGorgon - 5 hours ago

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.

swazzy - 5 hours ago

> 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?

aussieguy1234 - an hour ago

>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?

gozzoo - 6 hours ago

The article doesn't mention docker at all. I don't understand why containers are not viable solution for headless browsers.

wewewedxfgdf - 5 hours ago

But Firecracker is not compatible with GPU for Chrome, is that right?

That means Chrome is slow - quite the tradeoff.

rbbydotdev - 6 hours ago

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

andrewstuart - 4 hours ago

How many tabs do you use per server?

latchkey - 4 hours ago

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.

jauntywundrkind - 5 hours ago

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.

stogot - 6 hours ago

How do you handle browser sessions?

zane_shu - 3 hours ago

[flagged]

huflungdung - 3 hours ago

[dead]

eptcyka - 7 hours ago

[flagged]

Rasbora - 4 hours ago

[flagged]

nisten - 6 hours ago

fancy terms aside... they likely just run alpine linux.

fsuts - a day ago

“ click this button, type this text, read this page, take this screenshot.”

You left in the Ai’s instructions. lol

Interesting read though, thanks