Live data from Hacker News

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

browser-use.com

81–90 of 251 posts

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

#81

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.

Browsers can't be reused between customers. They contain sensitive and private data. Everything needs to be isolated and ephemeral.

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

#82
post #62

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.

It's not cheaper, slower startup, we lose full control and the environment is not optimized to run Chromium, so we also lose performance

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

#83
post #68

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 mem…

We decided to maintain Chromium as engine for stealth purposes.

Browsers like LightPanda lack stealth at all, they are trivial to detect. There are ways to make Chromium more performant, by removing everything that you don't need.

We believe that Chromium can reach that performance without starting an entire engine from scratch, and without losing stealth, a top priority for us.

The language is not the problem, C++ is as performant as Zig, but Chromium bloat is huge, agree on that.

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

#84

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?

Checkpoint with Chromium running is possible and will be our next step.

Main blockers right now is fingerprint injection and profile injection, solved already.

It's always a balance of engineering effort & gains. Post-Chromium snapshot let's us save 200ms, which is not that important for 99% of use-cases, but that will come soon since it brings some other benefits (like CPU footprint)

Profiling and tools used are already included with Chromium, they provide nice debugging tools

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

#85

Earlier quoted context omitted.

> 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. Unethical just because it does something someone else doesn't want? I guess it depends on why and what the intention is. I don't have time to sit 24/7 in front of a computer to get a ticket to some events, does that mean it's unethical for me to use my own bot so I c…

Its unethical because you're intentionally bypassing restrictions. Just because others do it doesn't mean its okay. If you saw a sign in a store that said "1 per person" or "for registered guests only", would you ignore it?

There are many ethical reasons to bypass restrictions. Colloquially, we just call them exceptions.

There are many valid ethical exceptions for evading anti-bot detections. For example: you are a white hat actor scraping a black hat site. There are hundreds of other plausible examples.

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

#86

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 se…

Not all use cases require all the features that we built

Few issues we had with lambas: - Limited running time (15 min), we support up to 4 hours (we can run longer if needed) - Price - Lack of snapshotting mechanisms - Lack of low-level control over the running host

But yeah, lambda is way more than enough for most common use cases automating the web

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

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

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

#88

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

They have IMO: https://web.archive.org/web/20180823072111/https://cloud.goo... They just don't have access to giant pools of residential IPs, so too many sites end up blocking all the cloud providers by IP range/ASN anyway, even if they could get through a captcha.

google has a large amount of "caching servers (GGC)" located in data centers for residential providers all over the world.. They use these servers for a variety of services.. Most of the traffic I have seen from them have been for their "URL preview" service ..
Post reply on HN