HN

Comments (112)

• Menu

  losteric
  > 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)
• Menu

  sudb
  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...
• Menu

  hobofan
  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
• smnscu
  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.
• Menu

  cgijoe
  > 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.
• Menu

  timojeajea
  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.
• amarshall
  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?
• Menu

  SomaticPirate
  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
  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.
• Menu

  rbbydotdev
  > 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?
• Menu

  Dibby053
  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?
• Menu

  messh
  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.
• Menu

  sandGorgon
  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.
• Menu

  GrinningFool
  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.
• Menu

  swazzy
  > 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?
• Menu

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

  wewewedxfgdf
  But Firecracker is not compatible with GPU for Chrome, is that right?That means Chrome is slow - quite the tradeoff.
• Menu

  rbbydotdev
  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
• Menu

  andrewstuart
  How many tabs do you use per server?
• Menu

  latchkey
  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.
• Menu

  jauntywundrkind
  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.
• Menu

  stogot
  How do you handle browser sessions?
• zane_shu
  [flagged]
• huflungdung
  [dead]
• eptcyka
  [flagged]
• Menu

  Rasbora
  [flagged]
• nisten
  fancy terms aside... they likely just run alpine linux.
• Menu

  fsuts
  “ click this button, type this text, read this page, take this screenshot.”You left in the Ai’s instructions. lolInteresting read though, thanks