How Vibium Manages the Browser Process Lifecycle

Vibium manages the full browser process lifecycle for you: its single Go binary launches Chrome for Testing through chromedriver, supervises the tree of processes that spawns, and tears everything down cleanly when your script ends. When you call launch(), the binary detects or downloads Chrome, starts it with WebDriver BiDi enabled, and proxies your commands over a local WebSocket. A single session quietly spins up eight to twelve processes — chromedriver, the main Chrome process, and helpers for GPU, network, storage, crash reporting, and one renderer per tab. On quit(), Vibium asks Chrome to close gracefully, then walks the process tree to kill stragglers and sweep up orphans. The point is that you never manage PIDs, match a driver to a browser version, or hunt down leftover Chrome windows. That lifecycle management is a core reason Vibium feels like one tool rather than a stack of moving parts.

What happens when you call launch()?

Calling launch() triggers a chain that ends with a controllable browser. The Go binary detects an existing Chrome for Testing or downloads it on first run, starts chromedriver, and has chromedriver start Chrome with BiDi enabled. It then opens a WebSocket proxy so your client commands reach the browser.

from vibium import browser_sync as browser
 
# Starts the binary, chromedriver, Chrome, and the BiDi proxy
vibe = browser.launch()
vibe.go("https://example.com")
 
# Tears the whole tree back down
vibe.quit()

From your side it's two lines. Underneath, a small process hierarchy comes to life and is then dismantled. For the full picture of how the binary wears several hats at once, see how Vibium works.

What does the process tree look like?

A live session is a parent-child tree, not a single process. The Go binary sits at the top, chromedriver underneath it, and Chrome for Testing under that — with Chrome spawning its own helpers:

vibium (Go binary)
  └── chromedriver
        └── Chrome for Testing (main process)
              ├── chrome_crashpad_handler (crash reporting)
              ├── GPU helper
              ├── Network helper
              ├── Storage helper
              ├── Renderer helper (one per tab/frame)
              └── ...more helpers

That's why a single browser session shows up as eight to twelve processes in your activity monitor. Knowing the shape of the tree explains why cleanup is more involved than "kill one PID."

How does Vibium clean up when a script ends?

Cleanup is a deliberate, multi-step sequence because killing the parent isn't enough. When chromedriver dies, its children — Chrome and all its helpers — get reparented to PID 1 (launchd on macOS, init on Linux) before they can be killed, which would leave orphaned "zombie" processes. Vibium guards against this:

1. Graceful quit first. It tells chromedriver to close Chrome cleanly (a best-effort DELETE /session).
2. Kill the tree, deepest first. It recursively finds every descendant and kills children before parents, so nothing gets reparented mid-cleanup.
3. Sweep for orphans. It looks for any Chrome or chromedriver process whose parent is now PID 1 and kills those too.
4. Remove temp dirs. It deletes orphaned Chrome temporary directories so disk clutter doesn't accumulate.

The result: a normal quit() leaves nothing behind.

What happens on Ctrl+C or a crash?

Vibium handles interrupts, with one honest exception. The lifecycle covers the common failure modes:

A hard kill -9 is the one case nothing can intercept, because the binary is terminated instantly. Even then, the orphan sweep in the next session's startup finds and kills the leftovers, so they don't pile up across runs. The Go binary itself is just a process that exits cleanly; the tricky part is always its browser children escaping cleanup.

How do I check for or clear leftover processes?

During heavy local development you can confirm nothing is lingering. To see whether any browser processes are still running:

pgrep -lf 'Chrome for Testing'
pgrep -lf chromedriver

To check whether they're orphaned, inspect their parent PID — an orphan reports PPID = 1:

ps -o pid,ppid,comm -p $(pgrep -f 'Chrome for Testing')

In practice you'll rarely need this, because Vibium cleans up on quit() and sweeps on the next launch(). But it's reassuring to know the lifecycle is observable, not magic.

Why does this matter?

Process lifecycle management is the difference between a tool you can run a thousand times in CI and one that slowly fills a machine with stranded Chrome instances. Because Vibium owns the whole tree — start to finish — you don't match driver versions, you don't script your own teardown, and you don't end the day with twenty hidden browsers eating RAM. It's the same single-binary philosophy that removes the ChromeDriver setup step entirely; see installing Vibium and the Vibium vs Selenium comparison for how much manual plumbing this replaces.

Next steps

• How Vibium works (architecture)
• Install Vibium
• Sync vs async in Vibium