Vibeleaderboard
Index / tool

Kernel

kernel.sh
Visit kernel.sh
Category
Developer Tools
Rank

Previous survey · No. 750 ·

Listed in
#14 Control a browser
Type
TOOL
Use case
Workflow Automation
Interfaces
API · Client SDK
Date

About

Kernel provides managed browser infrastructure for AI agents and web automation. It offers reusable sessions, fast browser startup, anti-bot handling, and autoscaling browser fleets through a hosted SDK and API.

What it does

This repository holds the browser images behind Kernel's hosted service: a Chromium build packed into a Docker container, or into a Unikraft unikernel (a tiny single-purpose virtual machine), with a Go control server alongside it. Automation libraries such as Playwright and Puppeteer attach over the Chrome DevTools Protocol on port 9222. A person can watch or take over the same session through a live view streamed over noVNC or WebRTC, and the server can record the whole screen to an MP4 file. The unikernel build sleeps when network traffic stops and snapshots its state, so a session can resume with cookies and open pages intact.

Why it's ranked here

Apache 2.0 source for the same images a commercial browser company says powers its hosted product, which is uncommon in this category. The code goes well past a Dockerfile: the Go server wires in screen recording, an outbound-traffic allowlist, scale-to-zero control and optional telemetry export, and the tree carries a long end-to-end suite covering reconnects, Playwright, recording audio and WebMCP. What it does not show is the hosted pitch. Anti-bot handling and fleet autoscaling are not visible in the files read, so those claims rest on the vendor, not on this code.

What's good

The unikernel path is the distinctive part. The README claims cold restarts under 20 milliseconds and a standby mode that snapshots the whole browser, which suits agents that pause for long stretches and need their logged-in state back. The control server publishes its own OpenAPI spec as YAML and JSON, so clients can be generated rather than hand-written. Small operational details live in code: the launcher clears Chromium's stale lock files after a hard kill, waits for the display and window manager before starting, and adds a private-network proxy bypass by default unless one is already set.

Tradeoffs

Self-hosting is not light. The unikernel image needs at least 8 GB of memory, the headless Docker script runs the container privileged with a 2 GB shared-memory mount, and the server exits outside the container because it waits for Chromium's debugging port. On Unikraft the live view gets a public URL that anyone holding it can open, which the README itself flags. Audio over WebRTC is listed as broken. The live-view admin password falls back to "admin" when no environment variable sets it, only one recording runs at a time, and the recording server does not support Windows.

How to use it well

Best for teams that want to run their own agent browsers, or check what a hosted provider actually runs, and are already comfortable with Docker or Unikraft Cloud. Point an existing Playwright or Puppeteer script at the exposed debugging port and keep the rest of the code unchanged. Use the read-only live view for anything a human should only watch, set your own admin password, and delete unikernel instances when done since their URLs are public. If the need is a managed fleet with stealth and scaling handled for you, this repository is the engine, not the service.

Technical notes+

server/cmd/api/main.go builds a chi router with request-ID, logging, recovery and scaletozero.Middleware (a debounced Unikraft Cloud controller), mounts the oapi-codegen strict handler, and serves the spec embedded by server/openapi.go at /spec.yaml and /spec.json. A second router proxies /json/version and /json/list to the upstream Chromium found by tailing /var/log/supervisord/chromium, and startup exits if no upstream appears within 10 seconds. Telemetry flows through a ring-buffered event stream (RingCapacity 8192) with optional S2 and OTLP sinks, both off until enabled per session; the egress policy is reloaded from disk so a process restart does not come back unfiltered. The Neko auth client reads NEKO_ADMIN_PASSWORD and defaults to "admin". server/cmd/chromium-launcher/main.go removes the Singleton lock files, runs pkill -9 -x chromium, waits for display :1 and mutter (headful only), then execs Chromium with --remote-allow-origins=* through runuser as the kernel user unless RUN_AS_ROOT is true. server/go.mod targets Go 1.25.0 and replaces the Neko server module with Kernel's fork. AGENTS.md notes the port 9222 proxy routes every WebSocket to the browser-level target, and carries operating instructions addressed to Cursor agents (benign, not aimed at reviewers). images/chromium-headless/run-docker.sh runs the container with --privileged and --tmpfs /dev/shm:size=2g.

Observed

License
Apache License 2.0
Language
Go control server; Chromium browser images
Packaging
Headful and headless Docker images, plus Unikraft unikernel builds
Interfaces
Chrome DevTools Protocol on port 9222; REST API with an embedded OpenAPI spec; noVNC or WebRTC live view
Platform support
Recording server supports macOS and Linux; Windows not supported (server/README.md)
Memory requirement
Unikernel image needs at least 8 GB (README.md)
Tests
End-to-end test directory in the tree, run with testcontainers-go against pre-built images
Hosted features
Anti-bot handling and autoscaling are not described in the files read
Known limitation
README lists WebRTC audio streaming as non-functional

Read from README.md, LICENSE, server/go.mod, server/README.md, images/README.md, server/cmd/api/main.go, server/cmd/chromium-launcher/main.go, server/openapi.go, images/chromium-headless/README.md, images/chromium-headless/run-docker.sh, AGENTS.md.

What it can do

  • Bypass anti-bot detection systems

    Web requests from AI agents or automation scripts → Successful web page access without bot blocking

  • Create reusable browser sessions

    Web automation workflow requirements → Persistent browser session that can be reused across multiple requests

  • Spin up browser instances rapidly

    Browser initialization request → Ready-to-use browser instance

  • Autoscale browser resources

    Variable web automation workload demand → Dynamically adjusted browser capacity to match demand

  • Provide browser infrastructure for AI agents

    AI agent web interaction requirements → Managed browser environment for AI agent operations

  • Enable web automation systems

    Web scraping or automation tasks → Reliable web automation execution environment

Intel on Kernel

More in Intel

Tags

browser-automationai-agentsinfrastructureanti-botautoscaling

Tech Stack

Node.js

Media

Kernel

Comments (0)

No comments yet

Editorially curated, with community endorsements as a secondary signal. Corrections welcome.