diff --git a/docs.json b/docs.json index f184da18..d299faea 100644 --- a/docs.json +++ b/docs.json @@ -119,7 +119,10 @@ { "group": "Overview", "pages": [ - "index" + "index", + "overview/products", + "overview/concepts", + "overview/why-kernel" ] }, { @@ -305,13 +308,6 @@ ] } ] - }, - { - "group": "Info", - "pages": [ - "info/concepts", - "info/unikernels" - ] } ] }, diff --git a/images/overview/agent-stack.svg b/images/overview/agent-stack.svg new file mode 100644 index 00000000..7b678d73 --- /dev/null +++ b/images/overview/agent-stack.svg @@ -0,0 +1,49 @@ + + + + +agent framework +runs the loop: ask the model, act, repeat + +model + +system prompt + +tools + +skills + +browser automation framework + +KERNEL +browser infrastructure + +chromium vm + +stealth + +proxies + +profiles + +auth + +payments + +the internet +real websites + + + + + + + + + + +drives + +https +your agent drives KERNEL browsers with playwright, computer controls, cdp, webdriver bidi, or mcp tools. + diff --git a/images/overview/cookbooks.svg b/images/overview/cookbooks.svg new file mode 100644 index 00000000..6cf6d1b9 --- /dev/null +++ b/images/overview/cookbooks.svg @@ -0,0 +1,17 @@ + + + +cookbooks + + +playwright + computer use + +human-in-the-loop credentials + +agentic payments + + + + +github.com/kernel/cookbooks + diff --git a/images/overview/quickstart.svg b/images/overview/quickstart.svg new file mode 100644 index 00000000..8b327157 --- /dev/null +++ b/images/overview/quickstart.svg @@ -0,0 +1,15 @@ + + + +give your agent the internet + +copy prompt + + + + +$ kernel login +$ npx skills add kernel/skills +$ kernel browsers create + + diff --git a/index.mdx b/index.mdx index 801dbaa8..b447681d 100644 --- a/index.mdx +++ b/index.mdx @@ -5,74 +5,47 @@ description: "" mode: "wide" --- -We build crazy fast, open source infra for AI agents to access the internet. Trusted by Cash App, Framer, and 11,000 teams. +KERNEL is the internet runtime for agents. we provide crazy fast, open source browser infra for your agents to access and act on the internet. each chromium browser is pre-configured with anti-detection defaults, runs in its own vm with isolated resources, and can be driven with browser automation frameworks, computer controls, or cdp and webdriver bidi directly. beyond browsers, KERNEL provides a platform of infrastructure primitives so your agents have what they need on real websites: stealth and proxies, authentication, payments, live view, replays, and more. - - - We spin up cloud browsers in <30ms with GPU acceleration when needed. - - - choose Managed Auth or Fill from Vault for browser agents. +## why we built it this way + +most browser infrastructure runs chromium in containers orchestrated by kubernetes, with warm pools to hide slow starts. we [pioneered](https://www.kernel.sh/blog/scale) a different approach: running chromium on unikernels, single-purpose vms that carry only what the browser needs. + +a unikernel carries the browser and nothing else, so there's little to boot or keep running. running every browser this way has many benefits, including: + +- **lifecycle actions are fast.** a browser is created in about 30ms at p50 and 105ms at p99 ([benchmarks](https://www.kernel.sh/benchmarks)), so you can create one per task instead of keeping a warm pool alive to hide start-up time. +- **code on the vm is safe to hand an agent.** every browser is its own vm, isolated at the hypervisor rather than sharing a host kernel with other tenants, so the [browser repl](/browsers/repl), [process execution](/browsers/process-execution), and root access over [ssh](/browsers/ssh) stay contained to that session. +- **idle browsers go into standby.** five seconds after the last client disconnects, a browser enters [standby](/browsers/standby): it keeps its state and stops accruing usage cost until a client reconnects. + +## open source + +we value open source and transparency, so we publish the browser image and the vm runtime behind KERNEL browsers on github. you can read exactly what runs your agent's browser, run it yourself, or contribute. + + + + the chromium images behind KERNEL browsers. - - We solve CAPTCHAs and manage residential proxies to help you see fewer of them. + + the vm runtime we built to run browsers. - - You can view sessions live and record them as MP4s for debugging. + + our fork of the cloud hypervisor virtual machine monitor. -## start here + + + +## get started - - - Spin up a browser and pick the shape — headless, stealth, GPU, profiles. + + + browsers, stealth, proxies, auth, payments, and everything else, each linking to its docs. - - Drive it with computer use, playwright execution, CDP, or WebDriver BiDi. + + hand setup to your coding agent with one prompt, or create your first browser yourself. - - Watch it live, record replays, and capture screenshots. + + end-to-end recipes you can clone and run, from computer use fallbacks to agentic payments. - -import { CopyPromptButton } from '/snippets/copy-prompt-button.jsx'; - -
-

fast setup

-
-
- - -
-
-

- copy and paste this into your AI coding agent (Cursor, Claude, Windsurf, etc.). it installs the Kernel CLI and skills, authenticates you, and opens a live browser session that you or your agent can interact with. -

-
- -
-
-
-
- -## prod setup - -Our [app platform](/apps/develop) is a serverless compute service for running agent loops triggered on demand or by scheduled events without having to provision or manage sandboxes. Your agent runs co-located with its browser to minimize network latency. - -Scaffold a project from a template: - -```bash -kernel create --template computer-use -``` - -Deploy and invoke it on demand: - -```bash -kernel deploy agent.ts -kernel invoke my-agent my-task --payload '{"url": "https://example.com"}' -``` - -### scaling - -[browser pools](/browsers/pools) keep browsers ready to use and pre-configured, so you skip start-up latency on every task and idle browsers aren't billed. reach for them once you're running the same workload repeatedly, need low-latency acquisition, or are scaling steady, high-frequency traffic — on-demand `browsers.create()` stays the right call for occasional, bursty, or one-off work. diff --git a/integrations/overview.mdx b/integrations/overview.mdx index 3e74f71e..d9dc1370 100644 --- a/integrations/overview.mdx +++ b/integrations/overview.mdx @@ -7,6 +7,8 @@ mode: "wide" Kernel browsers work with any tool that speaks the Chrome DevTools Protocol or WebDriver BiDi. The guides below cover the integrations with first-class support. For anything else, see [how you drive the browser](/introduction/control). For every integration from one vendor on one page, see [Claude](/integrations/claude/overview) and [Vercel](/integrations/vercel/overview). +Sections follow the pieces of a browser agent described in [important concepts](/overview/concepts). + diff --git a/overview/concepts.mdx b/overview/concepts.mdx new file mode 100644 index 00000000..2625a253 --- /dev/null +++ b/overview/concepts.mdx @@ -0,0 +1,61 @@ +--- +title: "How KERNEL Fits Between Your Agent and the Internet" +sidebarTitle: "Important Concepts" +description: "The agent framework decides what to do; KERNEL provides the browser infrastructure that carries it out on real websites" +mode: "wide" +--- + +A browser agent has three layers. The **agent framework** decides what to do: it runs the loop that asks a model for the next action and carries out the tool calls the model returns. **Browser infrastructure** runs the browser that performs those actions. **The internet** is the set of websites the agent works on. KERNEL provides the browser infrastructure, underneath whichever agent framework you use. + +Knowing which layer does what tells you where a feature belongs and which piece to change when something goes wrong. + + + an agent framework, holding the model, system prompt, tools, skills, and browser automation framework, drives KERNEL browser infrastructure, which carries the chromium vm, stealth, proxies, profiles, auth, and payments, and connects to the internet over https. + + +## Agent framework + +The agent framework, or harness, runs the loop: it sends context to the model, runs the tool call the model returns, feeds the result back, and repeats until the task is done. You either build your own with a framework, such as the [Claude Agent SDK](/integrations/claude/claude-agent-sdk), the [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/), or the [Vercel AI SDK](/integrations/vercel/ai-sdk), or use a finished agent that already has one, such as [Claude Code](/integrations/claude/claude-code-and-desktop), [Codex](https://developers.openai.com/codex), or [Replit](/integrations/replit). + +A harness's key pieces include: + +- **Model:** decides the next action from the system prompt, the conversation, tool results, and screenshots. It doesn't drive the browser itself: it returns a tool call and the harness carries it out. +- **System prompt:** the instructions sent with every request to the model: its role, its rules, and the format of its answers. +- **Tools:** functions the model can ask the harness to call, like "navigate to this URL", "click here", or "run this code". +- **Skills:** instructions and reference files the agent loads only when a task needs them, unlike the system prompt, which is sent every turn. +- **Browser automation framework:** turns tool calls into actions on the page, through the DOM with selectors (Playwright, Puppeteer) or through the screen with clicks at coordinates (computer use). Most agents combine the two: DOM actions for most steps, and computer use where the DOM doesn't cooperate. + +## Browser infrastructure + +Browser infrastructure is where the agent's decisions actually get carried out. The agent framework decides to open a page, fill a form, or click a button; browser infrastructure runs the browser that does it, and gives the agent what it needs to reach and interact with real websites. Its key pieces include: + +- **Browser:** the Chromium instance the agent drives, isolated from every other session. +- **Stealth and proxies:** anti-detection, CAPTCHA handling, and an IP address that fits the site, so the browser isn't blocked. +- **Credentials and state:** saved logins, credentials, and payment methods the browser can use without exposing them to the model. +- **Observability:** live view, replays, and telemetry, so you can see what happened when something goes wrong. +- **Scale:** running many browsers concurrently, and absorbing bursts when an agent creates a large number of browsers at once. + +## The internet + +Real websites weren't built for agents. They check for bots, and the useful pages often sit behind logins that need passwords, MFA codes, or payment details. Those credentials have to be used without exposing them to the model or leaking them into logs. The agent framework decides what to do; browser infrastructure is what gets it through, securely. + +## Which piece to change + +| What you see | Where to look | +| --- | --- | +| The agent picks the wrong action or ignores a rule | The model or the system prompt | +| The agent doesn't know how to use an API or a site | Skills | +| The agent can't do something at all | Tools | +| A selector breaks or a page action fails | The browser automation framework, the site's behavior, or the browser's state. Try [computer controls](/browsers/computer-controls) where the DOM doesn't cooperate. | +| The site blocks the browser, shows a CAPTCHA, or the login is lost | Browser infrastructure: [stealth](/browsers/bot-detection/overview), [proxies](/proxies/overview), [authentication](/auth/overview) | +| The agent is slow between actions | Where the loop runs: see [how you drive the browser](/introduction/control) | + +## Where KERNEL fits in the agent stack + +| Area | What KERNEL provides | +| --- | --- | +| Working with your agent framework | [Integrations](/integrations/overview) for the frameworks and agents you already use, and guides for each [computer use model](/integrations/computer-use/overview). The [MCP server](/reference/mcp-server) exposes KERNEL as tools, [Agent Skills](/skills/overview) teach coding agents how to use it, and [cookbooks](/cookbooks) include working prompts for common browser tasks. | +| Browser execution | [Playwright execution](/browsers/playwright-execution), the [Browser REPL](/browsers/repl), and [computer controls](/browsers/computer-controls) all run against the same browser, so an agent can mix DOM and screen actions. [WebMCP](/browsers/webmcp) lets an agent call the structured tools a site exposes. The [code execution platform](/apps/develop) runs your agent co-located with its browser. | +| Access and authentication | [Stealth](/browsers/bot-detection/overview), [proxies](/proxies/overview), and [Web Bot Auth](/browsers/bot-detection/web-bot-auth) help the browser get through, and [Config Registry](/config-registry) recommends configurations that have worked on a site. [Profiles](/browsers/profiles), [vaults](/vaults/overview), [authentication](/auth/overview), and [payments](/browsers/payments) carry state and credentials into a session. | +| Observability | [Live view, replays, and telemetry](/introduction/observe) show what happened in a session. | +| Scale | Each plan has a set [concurrency limit and browser create rate](/browsers/concurrency-and-limits), and both go up when you [upgrade your plan](/info/pricing). [Browser pools](/browsers/pools) keep pre-configured browsers running, so acquiring one is instant and doesn't count against the create rate. | diff --git a/overview/products.mdx b/overview/products.mdx new file mode 100644 index 00000000..9c7805c9 --- /dev/null +++ b/overview/products.mdx @@ -0,0 +1,63 @@ +--- +title: "See All Features" +description: "Cloud browsers, and everything your agents need to stay unblocked, log in, pay, and scale on real websites" +mode: "wide" +--- + +KERNEL is browser infrastructure for AI agents. Its features cover four jobs: running browsers, getting through real websites, carrying state, logins, and payments into a session, and seeing what happened afterward. + +## Run browsers + + + + Headful by default, with headless and GPU-accelerated options. + + + Pre-configured browsers kept ready, so acquiring one skips start-up latency and the browser create rate limit. + + + Deploy your agent next to its browser and invoke it on demand or on a schedule. + + + +## Get through real websites + + + + Anti-detection defaults on every browser, plus a managed CAPTCHA solver. + + + Datacenter, ISP, residential, mobile, or bring-your-own. + + + Give it a URL and get browser and proxy settings that have worked on that site. + + + +## Carry state, logins, and payments + + + + Persisted browser state — cookies, storage, logins, history, open tabs — that you load into any browser. + + + Credentials and payment items a browser can fill into a page without the values passing through your agent. + + + Fill logins from a vault, or let managed auth log in and attempt to reauthenticate eligible connections. + + + Let agents complete checkouts through Link by Stripe or AgentCard, without card numbers passing through your app or model. + + + +## See what happened + + + + Watch or take over a running session, and record any session as an MP4. + + + Structured events for navigation, network, CDP, captcha, and proxy activity. + + diff --git a/overview/why-kernel.mdx b/overview/why-kernel.mdx new file mode 100644 index 00000000..7fce21cd --- /dev/null +++ b/overview/why-kernel.mdx @@ -0,0 +1,38 @@ +--- +title: "Why KERNEL?" +description: "Fast, secure browser infrastructure for agents, paired with the agent framework you already use" +--- + +KERNEL provides isolated cloud browsers for AI agents. It works underneath the agent framework you already use, with anti-detection, managed authentication, and tools for running browsers at scale. Your framework runs the loop and KERNEL runs the browser, so you can pick the best of each instead of settling for a browser bundled with a framework, or a framework bundled with a browser. See [integrations](/integrations/overview) for the frameworks and agents KERNEL works with, and [important concepts](/overview/concepts) for how the pieces fit. + +KERNEL is also built for speed, across the browser lifecycle and inside a running session. A browser is created in about 30ms at P50 and 105ms at P99, and your code can run in the browser's VM instead of across the network, so each action skips the round trip. On ComputeSDK's independent throughput benchmark, KERNEL led the providers tested on actions per second inside a running session. See [benchmarks](https://www.kernel.sh/benchmarks) for how KERNEL compares. + +## What sets KERNEL apart + +- **Headful by default.** Every browser has a real display and runs the full rendering pipeline. Sites that check for signs of a headless browser don't find them, computer use models see the page as it actually rendered, WebGL, canvas, and video work, and [live view](/browsers/live-view) and [replays](/browsers/replays) show the real session. Switch to [headless](/browsers/headless) per session when a job doesn't need it, or add [GPU acceleration](/browsers/gpu-acceleration) for graphics-heavy sites. +- **Each browser is its own VM.** Every browser runs isolated at the hypervisor, with its own kernel and filesystem, instead of sharing a host with other tenants. That's what makes a 30ms start and strong isolation possible at the same time, and it's why [file I/O](/browsers/file-io), [shell access](/browsers/ssh), and GPU access are safe to use inside a session. +- **Platform primitives, with managed services built on them.** [Profiles](/browsers/profiles) keep browser state between sessions, [vaults](/vaults/overview) hold credentials and payment items, and [browser pools](/browsers/pools) keep configured browsers ready. Managed services such as [managed auth](/auth/overview), [payments](/browsers/payments), [stealth](/browsers/bot-detection/overview), and the [code execution platform](/apps/develop) build on them. + +To put these to work, the how it works guides walk through each stage of a browser's life: [configure](/introduction/configure) it, [control](/introduction/control) it, [scale](/introduction/scale) it, [observe](/introduction/observe) it, and [manage](/introduction/manage) it across your team. + +## Why not just run Chrome yourself? + +You can. Running one Chrome locally is easy, and it's the right call while you're prototyping. The work starts when the automation has to run unattended, more than once, at more than one at a time. These are the problems you'd need to solve yourself: + +| What you hit | Running it yourself | On Kernel | +| --- | --- | --- | +| Start-up latency | Keep starts fast as you scale: image pulls, Chromium launch, and warm capacity to hide them | Browser creation in 30ms at P50 and 105ms at P99 ([performance](/browsers/performance)), or pre-configured browsers in a [browser pool](/browsers/pools) for instant acquisition | +| Isolation | Keep one session's page, files, and processes away from every other session on the same host | Each browser is a [microVM](/info/unikernels) with its own kernel and filesystem | +| Bot detection | You maintain the patches, the fingerprints, and a proxy contract | [Anti-detection](/browsers/bot-detection/overview) on every browser, plus a managed solver and [proxies](/proxies/overview), including bring-your-own | +| Sensitive credentials | Keep passwords and card details out of your agent's context and logs, and run the secret store that holds them | [Vaults](/vaults/overview) store sensitive information and fill it into the page without the values passing through your agent, [managed auth](/auth/overview) handles logins end to end, and [profiles](/browsers/profiles) persist state across sessions | +| Idle cost | Avoid paying for a running browser while you wait for end-user input | [Standby mode](/browsers/standby) suspends the browser and stops usage charges 5 seconds after the last client disconnects | +| Debugging a failure | Add your own logging and screen recording, then try to reproduce the failure | [Live view](/browsers/live-view), [replays](/browsers/replays), and [telemetry](/browsers/telemetry/overview) for the session that actually failed | +| Scaling | Provision more hosts, then build the autoscaling, image pipeline, and cleanup jobs around them | [Upgrade your plan](/info/pricing) to raise your [concurrency limit and browser create rate](/browsers/concurrency-and-limits), with custom limits on Enterprise. | + +## When KERNEL isn't the answer + +If the task can be done through an API or an MCP server, use that instead. It's faster and more reliable than driving a page. An API existing isn't enough on its own: it has to support the work you need, and many don't expose everything the site does. Use a browser when the task can only be done through the site itself, whether or not it needs a login: a portal with no API, data the API doesn't return, or a task where a computer use model has to see the page to take actions. + + + Every feature, each linking to its documentation. +