DEV Community

Discussion on: AI Browser Automation Without BrowserBase: What We Built Instead

Collapse
 
rendershot profile image
Ohad Badihi

The cost numbers check out for small workloads. What flips it back at bigger scale is the work to keep it running. You get a great per-render price, but you also inherit the headaches — Chromium leaks memory over time, containers run out of RAM and die, traffic spikes take everything down at once. For 1k pages a day on an internal tool, self-hosting is the obvious win. For 100k pages a day with paying customers waiting on screenshots, paying someone else to babysit the browsers starts looking reasonable again. The anti-detection point is the other big one — that's a treadmill nobody wants to be on.

Collapse
 
refaatalktifan profile image
refaat Al Ktifan

Fair points. We hit all of those.

Chromium memory leaks, we kill the browser process every N tasks, not just close tabs. Each pool instance runs with a hard container memory limit so a leak takes down one worker, not the service. Ugly but stable.

Scale changes the math. For internal tools and back-office automation where we use this, the ops overhead is minimal. For high-volume production pipelines with SLAs, managed infrastructure earns its price.

The anti-detection point is the real divider. We scope strictly to first-party sites and partner integrations. The moment you need fingerprint rotation and proxy management, you're in a different problem space entirely and self-hosting stops making sense.
CHECK: github.com/ulixee/hero

Collapse
 
rendershot profile image
Ohad Badihi

Wrote up the operational tax part in more detail here, including the exact memory-restart pattern: dev.to/rendershot/headless-chromiu...