Lightpanda: a Zig headless browser that trades web compatibility for speed and memory

What Lightpanda actually is

Lightpanda is a headless browser written in Zig, not a wrapper around Chromium or WebKit. The README is explicit: "Not a Chromium fork. Not a WebKit patch. A new browser." That distinction matters because it means the project controls the entire stack, from parsing to rendering to the CDP protocol. The target user is someone building AI agents or automation scripts that need to navigate pages, click elements, fill forms, and extract data, but who does not need a full desktop browser. The project positions itself as a faster, lighter alternative to headless Chrome for exactly those workloads. It is not trying to replace the browser you use for development or debugging. It is a server that speaks Chrome DevTools Protocol and accepts connections from Puppeteer or Playwright clients, plus a native agent mode that does not need an external driver.

How the CDP server and Puppeteer integration work

The core mechanism is a CDP server started with the `serve` subcommand. You run `./lightpanda serve --obey-robots --log-format pretty --log-level info --host 127.0.0.1 --port 9222`, and then a Puppeteer script connects via `browserWSEndpoint: "ws://127.0.0.1:9222"`. The README shows a script using `puppeteer-core` where the rest of the Puppeteer API, like `createBrowserContext`, `newPage`, `goto`, and `evaluate`, stays the same. That is a significant compatibility promise. The browser implements enough of the CDP protocol for Puppeteer to drive it. The `fetch` subcommand is a simpler path: it dumps a URL to html, markdown, png, or pdf, with flags for waiting (`--wait-until`, `--wait-ms`, `--wait-selector`, `--wait-script`). For automation, the CDP route is the one that matters because it lets your existing Puppeteer or Playwright code run against a different backend. The README does not list which CDP methods are implemented, so you should assume partial coverage until you test your specific calls.

The agent mode and PandaScript

Beyond CDP, Lightpanda has a native agent mode. You run `./lightpanda agent` with a task like `--task "top story on news.ycombinator.com?"`, and the agent drives the browser directly. Because the agent runs in the same process as the browser, every tool call is a direct operation, which is how it keeps the speed and memory advantage. The agent supports multiple LLM providers: Anthropic, OpenAI, Gemini, Google Vertex AI, Mistral, Hugging Face, the Vercel AI Gateway, any OpenAI-compatible endpoint via `OPENAI_BASE_URL`, and local models via Ollama or llama.cpp. There is also a `--no-llm` flag that drops you into a REPL. The output of a session is a PandaScript file, which the README describes as "vanilla JavaScript with a small set of native browser primitives." You save it with `/save` and replay it with `lightpanda run <script>.js`. The claim is that scripts are deterministic and token-free, so you can prototype with an LLM and then run the script without a model. That is a practical design: the LLM is a development tool, not a runtime dependency. The trade-off is that the agent is only as good as the underlying browser's ability to handle the pages you point it at.

Memory and speed claims, and what they do not tell you

The README includes a benchmark table: requesting 933 real web pages on an AWS EC2 m5.large instance, Lightpanda used 123MB peak memory for 100 pages versus 2GB for headless Chrome, and took 5 seconds versus 46 seconds. That is roughly 16 times less memory and 9 times faster. These are striking numbers, but they come from a single instance type and a specific page set. The README links to a demo repository with benchmark details, but the table alone does not say which pages were excluded or how many failed to render. The speed and memory advantages likely come from the browser not implementing full rendering features, so it does less work per page. That is not a flaw if your pages are simple. It is a risk if your automation targets modern single-page apps that rely on complex JavaScript and CSS. You should run the benchmark on your own workload before trusting the numbers for your use case.

Installation paths and the glibc trap

You can install Lightpanda via Homebrew (`brew install lightpanda-io/browser/lightpanda`), Arch AUR (`yay -S lightpanda-nightly-bin`), or download a nightly binary from GitHub releases. There are Linux and macOS builds for x86_64 and aarch64. The README gives a curl command for Linux and macOS, followed by a `version` check to verify the binary. A notable constraint: the Linux binaries are linked against glibc, so they fail on musl-based distros like Alpine with `cannot execute: required file not found`. The README suggests using a glibc base image like `debian:bookworm-slim` or `ubuntu:24.04`, or building from source. Windows has no native binary; you must use WSL2, and the README notes that WSL forwards `localhost:9222` automatically, so your automation client can run on the Windows host. There is also an official Docker image: `docker run -d --name lightpanda -p 127.0.0.1:9222:9222 lightpanda/browser:nightly`. The Docker route is the cleanest for a server deployment, but the nightly tag means you are tracking a moving target.

Native MCP support and its limits

Lightpanda includes a native MCP server that communicates over stdio using JSON-RPC 2.0. You add it to an MCP client configuration with a command pointing to the lightpanda binary and `args: ["mcp"]`. That lets an AI assistant or agent framework use the browser as a tool. The README mentions HTTP transport and independent sessions for serving several agents, but that section is truncated, so I cannot describe those features in detail. The stdio transport is the confirmed part. That is a useful integration point if you already use MCP-based tooling. The limitation is that MCP over stdio means one process per client, which could be a resource concern if you run many concurrent agents. The README hints at independent sessions, but without the full text, I would verify that feature before relying on it.

A real alternative: headless Chrome or Playwright's own browser

The obvious alternative is headless Chrome itself, which the benchmark compares against. Chrome gives you full web compatibility, every CDP method, and years of debugging. The cost is memory and speed, as the benchmark shows. Another alternative is Playwright's bundled Chromium, which is similar to Chrome but with a different automation API. The difference in approach is fundamental: Chrome is a complete browser with a headless mode, while Lightpanda is a minimal browser built for a specific niche. If your automation must work on any site, including those with heavy JavaScript, Chrome is the safer choice. If your workload is bulk extraction from many pages where most are static or lightly scripted, Lightpanda's lower memory footprint could let you run more concurrent instances on the same hardware. The README does not claim full compatibility, so you should treat it as a specialized tool, not a drop-in replacement.

Licence and maintenance considerations

Lightpanda is licensed under AGPL-3.0. That is a strong copyleft licence: if you modify the browser and offer it as a network service, you may need to release your modifications. For internal automation that does not distribute the software, it is less of a concern, but you should check with your legal team if you plan to offer a hosted service built on Lightpanda. The project is actively maintained, with releases 0.3.5, 0.3.6, and 0.3.7 pushed between July and August 2026, and the last push on the default branch matches the 0.3.7 release date. That suggests a steady release cadence. The version numbers are still below 1.0, so API changes are possible between releases. The README does not mention a migration guide or a stable API promise. You should pin a specific version in your deployment and test upgrades before rolling them out.

Editorial conclusion

Adopt Lightpanda if your workload is high-volume scraping, structured extraction, or AI agent navigation where page count and memory dominate and the target sites are simple enough to render without full JavaScript. Do not adopt it if you need pixel-perfect rendering, complex CSS, heavy client-side frameworks, or sites that break without complete browser features. Before committing, verify that your target pages load and that the dump modes (html, markdown, png, pdf) produce what you need, and check the AGPL-3.0 license against your distribution plans. Run the benchmark script from the demo repository on your own hardware, because the published numbers come from one EC2 instance and may not reflect your traffic.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes