The state does not contain the browser config, since it's configured just before it starts running (and we currently snapshot before Chromium starts).
In our case, we prepare the environment, load files that we need later and then we create the state. Once we start, we instantly start Chromium with the config requested by the customer.
I have tried it before by saving the entire memory state of the VM actively running but man oh man were there alot of bugs. My idea was different I was playing with spinning browsers on spot nodes and swap them over + state if they were revoked.
You thinking custom Chromium startup sequence for that?
Really depends on the server specs. Tab amount relies entirely in memory & CPU availability, not in the infra that runs behind the scenes
But yeah, in one server we can fit hundreds of browsers, or even thousands if we use bigger servers. And each one of them with dozens of tabs, no issue
Something doesn't add up between the pricing and the core pinning for me (or maybe I misunderstood):
Say you're using a m8i.large (2 vCPUs, $0.043/hr on spot pricing). Is the article saying you dedicate a whole physical core to one browser or am I totally misunderstanding here? If so, are you taking a loss on every browser hour?
I've experimented with Android Browsers. The problem is that android VMs are super heavy compared to the resources needed to run just Chromium
Startups are absurdly slow, isolation is harder, etc...
Android bloat is insane, you need to run the entire Java VM to start the browser... It's also harder to fingerprint, and at scale that's something that we need for Browser Use
Cool experiment but not yet production ready, at least for us
Yes, warm pool work, but our goal is to replace them at all.
Warm pools are nice but at the end they also consume resources, And you need to always keep the pool warm, starting browsers to balance, etc...
With the upcoming changes we will keep Chromium startup and the VM will be ready in 50ms, defeating warm pools at all
Also some customers need special parameters and features, increasing warm pools complexity. The happy path will be fast but the edge case will be extremely slow , and we want to guarantee fast speeds to matter which features you need on the requested browser.
Do you see much of a difference between started Chromium instances with the same configuration in terms of the contents of allocated memory? Are they deterministic?
If not, could you template the memory and apply runtime patches (like timers or other initialized values) before releasing the process to run?
Would forcing the isolates to allocate memory better help at all, such as reducing fragmentation making your 2MB page sizes more effective?
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
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
> Main blockers right now is fingerprint injection and profile injection, solved already.
Do you do this at the chromium/V8 level or CDP?
I've been having mixed success with CDP and was thinking of going to the level below, but it feels like just getting Chromium itself to baseline chrome detection profile is significant work
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.
I get why it can look like we're “lying” to website operators, that’s a fair concern.
But stealth, as we see it, isn’t about deception for abuse. It’s about making automated access behave closer to how real users interact with the web, in an ecosystem where most anti-bot systems default to blocking everything that isn’t explicitly whitelisted.
Right now, the model is broken. Unless you have a direct partnership, you're often locked out, even for legitimate use cases like research, monitoring, or building user-facing tools on top of public data.
We’re not supporting harmful behavior (credential stuffing, DDoS, piracy, etc.). The goal is to enable responsible access to publicly available information without forcing every use case into closed-door agreements.
There’s also a real tradeoff happening. Increasingly aggressive anti-bot measures (like harder CAPTCHAs) degrade the experience for actual users, while not necessarily stopping sophisticated automation, robots solve CAPTCHAs better than humans.
So the question isn’t “bots vs no bots” — it’s what kinds of automated access should exist, and under what norms. Right now, that line is blurry, and we think there’s room for better balance.
Happy to engage on where that line should be drawn.
> So the question isn’t “bots vs no bots” - it’s what kinds of automated access should exist, and under what norms.
I think it's pretty simple: if a website clearly isn't welcoming automated access, like when they set up UA filters and such, it should not be automatically. Stealth browsers that bypasses those filters are abusing the site.
