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

Original Article ↗ Hacker News Discussion ↗

Overall focus

  • Discussion centers less on the article’s mechanics (already known) and more on:
    • Why Firecracker VMs vs containers/Lambda.
    • Startup-time tricks and scaling strategies.
    • Security/isolation tradeoffs.
    • Ethical implications of “stealth” browsers and bot evasion.

Firecracker, nested virtualization, and EC2 choices

  • Some note that EC2 itself is a VM; Firecracker here runs as a VM-in-VM via nested virtualization.
  • Only certain EC2 instance families currently support nested virtualization; supply is limited and some report reduced stability vs metal.
  • Others highlight that metal instances have better performance but are slow to start/stop.
  • Several comments stress Firecracker’s stronger isolation vs containers, especially for untrusted browser workloads and frequent container-escape CVEs.

Containers vs microVMs for browsers

  • Multiple posters ask why not just use Docker/containers.
  • Arguments against containers:
    • Not considered a strong security boundary; share host kernel.
    • Slower startup and heavier resource use vs Firecracker snapshots.
  • Counterpoints:
    • Docker escapes are “very hard” according to some; disagreement exists on how weak the boundary really is.
    • For some workloads, Chromium in containers or simple subprocesses is workable, just harder to scale and secure.

Performance, snapshots, warm pools

  • Firecracker VM startup (20 ms) is fast; browser startup (300 ms) dominates.
  • Snapshotting of post-OS, pre-Chromium state is used to cut startup; future work aims to snapshot with Chromium already initialized, targeting ~50 ms end-to-end.
  • Debate over “warm pools” of pre-running browsers:
    • Proponents: simple, near-zero latency if pool sizing is right.
    • Opponents: idle capacity is costly, complex to tune for many feature combinations; snapshots may beat warm pools in both cost and speed.

Browser engine, GPU, and Android

  • Chromium retained primarily for “stealth” and anti-detection; alternatives like Lightpanda seen as easier to fingerprint.
  • GPU passthrough is not available in Firecracker; workloads rely on CPU and software rasterization, which is considered acceptable for most automation.
  • Android browser VMs are reported as very heavy, slow to start, and harder to scale; currently not production-ready for this use case.

Ethics and impact of stealth automation

  • Major subthread debates whether bypassing anti-bot measures is ethical:
    • Critics: services like this increase bot traffic, drive harsher CAPTCHAs/anti-bot tech, externalize costs to site operators, and often rely on residential proxies with questionable consent.
    • Defenders: distinguish between abusive mass scraping and light, purpose-driven automation (price monitoring, ticket watching, link checking, archival, privacy tools, counterfeit detection, legacy SaaS automation).
    • Some argue ToS violations ≠ inherent unethical behavior; context and intent matter.
    • Others see it as entitlement to others’ resources “because you want it.”
  • Concerns raised that escalating bot/anti-bot arms races make the web more hostile for humans, but some users claim automation is now necessary because many websites have become so user-unfriendly.

Alternative approaches and cost comparisons

  • Some run Chromium in AWS Lambda container images, citing simpler architecture and automatic scaling; tradeoff is cold starts and 15-minute limits.
  • For short screenshot jobs, Lambda billed per millisecond is reported as cheaper; for longer-running automation, per-minute VM billing may win.
  • Other alternatives mentioned: Cloudflare Workers-like products, Shellbox-style sandboxes, Kubernetes + Kata, or just processes with Chrome’s own sandbox.
  • View that EC2 (plus Firecracker) is “more scalable than your wallet,” while others note opportunity cost of idle capacity and the value of spot/preemptible pricing.

Security and broader web ecosystem

  • Repeated emphasis that containers are not widely treated as hard security boundaries, whereas microVMs are.
  • Some see bot traffic as a long-standing cost of running any public service; others argue that scale and impact have worsened significantly.
  • Thread surfaces broader frustration with anti-user web practices (tracking, ads, CAPTCHAs) and the increasing shift toward AI and automation as a more pleasant interface to web content.