Add a Get started section with an end-to-end quickstart - #470
Add a Get started section with an end-to-end quickstart#470andrewleesteele wants to merge 34 commits into
Conversation
Add a Browser Pools Quickstart, move the pool guides from Advanced to Basics, and use "browser pools" as the single name for the concept everywhere in the docs (the API, SDKs, CLI, and dashboard already do). Push pools as the production path from the Create page, the home page, and the Scale guide, and lead with the fact that idle pooled browsers aren't billed.
- Document that reuse: true persists browser state across acquisitions (not isolated) and reuse: false is the clean/per-user path, with a multi-tenant leak warning. - Explain why acquiring is faster than browsers.create(): pre-applied restart-triggering configs and no create-endpoint rate limit. - Point the read-only-profile note at the per-user-profiles pattern instead of a standalone session. - Fold two update-semantics FAQ entries into one pointer to the canonical Update a pool section; align the fill-rate example with the 25% default. - Keep the Browser Pools nav group in Advanced for now. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The pools quickstart is being folded into a future unified Kernel quickstart rather than living as a feature-specific guide. Delete the page and its nav entry, and repoint the six inbound links (home, pricing, concepts, create, scale, and the overview callout) to the browser pools overview. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Position browser pools as the step you reach when taking a working automation to production, after learning to create and drive a browser — rather than "most production workloads run on them from day one," which pushes them before the fundamentals. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move the one piece of guidance the overview lacked — pool sizing via available_count — into a Sizing section, and drop the FAQ page. Its other entries duplicated overview sections (update, reuse, timeout, profiles) or belonged elsewhere (target-site rate limiting, debugging). Repoint the auth/profiles link to the per-user-profiles section. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Apply the naming rule to cross-page references (home, pricing, projects, scale, create, proxies, reference, integrations) and the pools overview intro so the feature is never shortened to "pool" — which collides with connection pools, IP pools, and socket pools elsewhere in the docs. Non-browser-pool uses (curl connection/socket pools, proxy IP/ISP pools) are intentionally left for their own qualifiers. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…s-docs-refresh # Conflicts: # browsers/chrome-policies.mdx # docs.json
With the FAQ folded in and Chrome policies moved out (#469), the section is one page. Move browsers/pools/overview.mdx → browsers/pools.mdx so it serves at /browsers/pools, retitle it "Browser Pools", and collapse the nav group to a single entry. Repoint every /browsers/pools/overview link to /browsers/pools, fix a stale #create-a-pool-of-reserved-browsers anchor, and add a redirect from the old overview path. Changelog's bare /browsers/pools links now resolve to a real page. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Qualify the overloaded uses so "pool" is never mistaken for the browser pools feature: "connection pool" on the curl networking limits, and "managed proxy pool" / "proxy-pool traffic" on the bot-detection page. "ISP pool" (auth) and "warm pools" (unikernels, a generic industry term) are already unambiguous and left as-is. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reframe the ~50-concurrency figure as an illustrative point rather than a gate: a small browser pool is worth it whenever acquisition latency matters and demand is steady. Add a consolidated Limitations section (no GPU browsers, one fixed config per pool with start_url the only per-acquire override, read-only profiles, reserved capacity holds concurrency slots, plan-gated). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Small browser pools still pay off when acquisition latency matters and demand is steady, so lead with that rather than a concurrency number. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace the co-equal concurrency/patterns/throughput framing (and its 1-50/50-100/100+ gate) with: why a browser pool (low-latency acquisition, reserved capacity, higher creation throughput; the concurrency-limit tradeoff), when to use a pool vs on-demand as workload signals rather than thresholds, and a sizing pointer to the pools page. Keep the three architecture patterns, dropping their numeric when-to-use gates. Soften the home-page CTA to name the workloads pools suit instead of "almost any production workload." Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Per docs-team feedback, "warm" implies pools run hot and bill for idle time — the opposite of the actual benefit (idle pooled browsers aren't billed). Replace with "ready to use" / "pre-provisioned" throughout, and reframe the pricing line to lead with the no-idle-charge benefit. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
"browser pools of ready-to-use browsers" doubled "browser(s)"; use "Pre-configure a pool of ready-to-use browsers for instant acquisition." Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
"configure" reads better than "maintain" for setting up a pool; trim "identically-configured" to "identical" to avoid doubling "configure." Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The page explained the same few facts repeatedly: "config is pre-applied so acquisition is faster" appeared four times, read-only profiles three times, update/stale-config semantics three times (including a paragraph duplicated verbatim two paragraphs later), and refresh_on_profile_update three times. - Collapse the intro to two paragraphs and drop the paragraph that restated it above the Steps block; trim the Step callouts that repeated their own step bodies. - Merge "Refresh on profile update", "How it works", and "Per-user profiles with pools" into one "Profiles with browser pools" section. - Move the stale-configuration warning to "Update a pool", where it belongs, and delete the duplicated update paragraph. - Replace "Pool configuration options" with a short Configuration pointer, and move Sizing up next to the acquire/release lifecycle. All externally-linked anchors are preserved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The docs had no code-along path: the home page is a landing page, and each guide covers one stage in isolation. Add a Quickstart that runs install → create and drive a browser → observe it → serve a workload from a browser pool, and put it in a new "Get started" nav group with room for more onboarding pages. Browser pools are the last stage rather than a separate quickstart, so the walkthrough (create the pool once, acquire/drive/release per task, plus the three production gotchas) lives here and the pools page keeps only reference material — its Full example moves into this guide. Drops the stale /quickstart -> / redirect from when the old quickstart was folded into the home page. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The sidebar should lead with Introduction, not the quickstart. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
The general "how do profiles work with browser pools" pointer landed on the per-user subsection, skipping the read-only and refresh-on-update behavior above it. The per-user-specific link further down is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Listing profiles alongside stealth, proxies, and viewport implied they behave the same way. A pool takes one profile, shared read-only, so call that out where the settings are introduced and link to the details. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Apply review feedback: drop the intro's repeat of the settings list, reword the borrowed/topped-up and "unavailable to everything else" phrasing, stop naming profiles twice in the same limitation, spell out that pool capacity comes off the organization's concurrency limit, and use the documented default viewport in the examples. Move Timeout behavior under Release, where reuse is discussed, and lead with the practice: always release, with the timeout as a backstop. Remove the "let it expire" option for rolling configuration, which relied on idle sessions timing out. Lead the profiles section with Managed Auth as the way to fill and maintain a profile, then the one-identity vs per-task choice. Drop the thin Configuration section. Move the walkthrough code out — the full example and the per-user step-by-step both belong in the quickstart — leaving the behavior and the constraint behind. The page is 401 lines, down from 616. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The pools reference page now states the behavior and constraint; the step-by-step and its code belong here, alongside the rest of the browser-pool walkthrough. Points at Managed Auth for keeping those profiles logged in. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Fold profiles into the configuration list as a link, dropping the awkward two-constraints sentence; the profiles section covers it. - Break the second paragraph into shorter sentences. - Replace the Flush, Get details, List, and Delete sections with a single "Managing a pool" table. They were pure call-and-description, which the API reference already covers; the table keeps the behavior notes (force delete, what flush spares) without four code groups. This also absorbs the trailing API reference section. - Fix the update warning, which still said "three ways" after the expire-based option was removed. Code drops from 57% of the page to 49%, and the page to 290 lines from 616 at the start of review — in line with comparable guide pages, which all keep per-operation examples for the calls that carry behavior. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
It described the page as the full API surface, which stopped being true once the CRUD sections collapsed into the operations table. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase after synchronize).
Evidence (from diff only)
File Change quickstart.mdxNew Mintlify docs page (install → drive browser → pools walkthrough with TS/Python/Go examples) docs.jsonAdds Get startednav group; removes/quickstart→/redirect so the new page is reachableindex.mdxAdds a link to /quickstartbrowsers/pools.mdxAdds an Info callout pointing readers to the quickstart Re-evaluation after update
Previously approved at
77c3e06. New HEAD63eda69(plus merge from base) only adjusts the pools Info callout wording after the base branch trimmed that page. Still documentation-only; blast radius unchanged.Why Very Low
- Documentation-only on a Mintlify docs site — no application code, APIs, auth, billing, infra, or runtime logic.
- Small, scoped surface: one new guide page plus navigation/cross-link wiring.
- No shared libraries, schemas, deployments, or security boundaries touched.
- No CODEOWNERS file requiring human ownership review.
Action
Comment only — already approved and risk did not increase, so approval is not dismissed and is not re-issued. No reviewers assigned.
Sent by Cursor Automation: Assign PR reviewers
Sizing sat between Release and Update, splitting the create/acquire/ release walkthrough from the operational sections, and left Profiles stranded between two of them. Move Profiles up to close out the "using a pool" block so the page reads as three groups: what it is, using one, then tuning and operating one. Three of the five limitations restated content covered later in the page. Keep the list as an up-front gate but make those bullets point at their sections instead of explaining again. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase after synchronize).
Evidence (from diff only)
File Change quickstart.mdxNew Mintlify docs page (install → drive browser → pools walkthrough with TS/Python/Go examples) docs.jsonAdds Get startednav group; removes/quickstart→/redirect so the new page is reachableindex.mdxAdds a link to /quickstartbrowsers/pools.mdxAdds an Info callout pointing readers to the quickstart Re-evaluation after update
Previously approved at
77c3e06. New HEAD51eb068merges latest base (hypeship/browser-pools-docs-refresh). Relative to the last assessment commit (63eda69), the only file touched isbrowsers/pools.mdxvia that merge (section reorder/trim on the base branch). This PR’s own delta remains the Info callout plus the quickstart/nav/home wiring above. Still documentation-only; blast radius unchanged.Why Very Low
- Documentation-only on a Mintlify docs site — no application code, APIs, auth, billing, infra, or runtime logic.
- Small, scoped surface: one new guide page plus navigation/cross-link wiring.
- No shared libraries, schemas, deployments, or security boundaries touched.
- No CODEOWNERS file requiring human ownership review.
Action
Comment only — already approved and risk did not increase, so approval is not dismissed and is not re-issued. No reviewers assigned.
Sent by Cursor Automation: Assign PR reviewers
- Say what you'd otherwise do instead of "configuring one per task": the configuration goes on the pool rather than into every browsers.create() call. - Rework the acquisition paragraph so it flows as prose rather than three clipped sentences. - Frame releasing as a best practice rather than an instruction, and drop the reuse aside from the timeout section. - Trim the Managed Auth mention to a pointer; how it works belongs on the auth pages. - Put per-user profiles above refresh-on-profile-update, since it's the more common case. - Replace the operations table with a link to the API reference. - Drop the quickstart link, which has no target on this branch. - Pricing: idle pooled browsers incur no usage charges, not "disk charges". Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase after synchronize).
Evidence (from diff only)
File Change quickstart.mdxNew Mintlify docs page (install → drive browser → pools walkthrough with TS/Python/Go examples) docs.jsonAdds Get startednav group; removes/quickstart→/redirect so the new page is reachableindex.mdxAdds a link to /quickstartbrowsers/pools.mdxAdds an Info callout pointing readers to the quickstart Re-evaluation after update
Previously approved at
77c3e06. New HEAD329a6b3merges latest base (hypeship/browser-pools-docs-refresh). Relative to the last assessment commit (51eb068), the merge brings base-branch edits intobrowsers/pools.mdx/info/pricing.mdx; this PR’s three-dot delta vs base remains documentation-only (quickstart page, nav/redirect wiring, home link, pools Info callout). Blast radius unchanged.Why Very Low
- Documentation-only on a Mintlify docs site — no application code, APIs, auth, billing, infra, or runtime logic.
- Small, scoped surface: one new guide page plus navigation/cross-link wiring.
- No shared libraries, schemas, deployments, or security boundaries touched.
- No CODEOWNERS file requiring human ownership review.
Action
Comment only — already approved and risk did not increase, so approval is not dismissed and is not re-issued. No reviewers assigned.
Sent by Cursor Automation: Assign PR reviewers
- Refer to on-demand browsers rather than browsers.create() in prose, and drop the size/fill-rate parameter mismatch: the code sample and API reference own parameter names and defaults, not the prose. - Cut the fill-rate link from five places to one, in Sizing, where you'd act on it. - Give flush its own short section under Update, where it's the remedy for stale configuration, and restore the two links that pointed at it. - Say "browser pool" at each section's first mention, keeping "the pool" only for back-references; rename the Create, Update, and per-user headings to match, updating the links that referenced them. - Remove three more restatements: the Create lead repeated the Steps block, the Update warning re-explained discard_all_idle, and the per-user lead repeated the read-only paragraph above it. - Soften releasing into a best practice rather than an instruction, and trim the Managed Auth mention to a pointer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase after synchronize).
Evidence (from diff only)
File Change quickstart.mdxNew Mintlify docs page (install → drive browser → pools walkthrough with TS/Python/Go examples) docs.jsonAdds Get startednav group; removes/quickstart→/redirect so the new page is reachableindex.mdxAdds a link to /quickstartbrowsers/pools.mdxAdds an Info callout pointing readers to the quickstart Re-evaluation after update
Previously approved at
77c3e06. New HEAD2b7711cmerges latest base (hypeship/browser-pools-docs-refresh). Relative to the last assessed tip, incoming base merges touch other docs pages (browsers/pools.mdxpolish, plus unrelated base-branch edits pulled in by the merge). This PR’s own delta vs base remains the quickstart page plus nav/home/pools callout wiring above. Still documentation-only; blast radius unchanged.Why Very Low
- Documentation-only on a Mintlify docs site — no application code, APIs, auth, billing, infra, or runtime logic.
- Small, scoped surface: one new guide page plus navigation/cross-link wiring.
- No shared libraries, schemas, deployments, or security boundaries touched.
- No CODEOWNERS file requiring human ownership review.
Action
Comment only — already approved and risk did not increase, so approval is not dismissed and is not re-issued. No reviewers assigned.
Sent by Cursor Automation: Assign PR reviewers
The intro stated the same idea three times — configure once, get pre-configured browsers — and never actually said what a browser pool is. Replace it with three paragraphs doing one job each: what a browser pool is, why acquiring is faster, and what it costs. The Chromium restart becomes part of the start-up point rather than a third parallel clause. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase after synchronize).
Evidence (from diff only)
| File | Change |
|---|---|
quickstart.mdx |
New Mintlify docs page (install → drive browser → pools walkthrough with TS/Python/Go examples) |
docs.json |
Adds Get started nav group; removes /quickstart → / redirect so the new page is reachable |
index.mdx |
Adds a link to /quickstart |
browsers/pools.mdx |
Adds an Info callout pointing readers to the quickstart |
Re-evaluation after update
Previously approved at 77c3e06. New HEAD 8d2a43c merges latest base (hypeship/browser-pools-docs-refresh). Relative to the last assessed tip (2b7711c), the merge only updates browsers/pools.mdx with base-branch wording (opening definition). This PR’s own delta vs base remains the quickstart page plus nav/home/pools callout wiring above. Still documentation-only; blast radius unchanged.
Why Very Low
- Documentation-only on a Mintlify docs site — no application code, APIs, auth, billing, infra, or runtime logic.
- Small, scoped surface: one new guide page plus navigation/cross-link wiring.
- No shared libraries, schemas, deployments, or security boundaries touched.
- No CODEOWNERS file requiring human ownership review.
Action
Comment only — already approved and risk did not increase, so approval is not dismissed and is not re-issued. No reviewers assigned.
Sent by Cursor Automation: Assign PR reviewers


Summary
The docs have no code-along path. The home page is a landing page, and each guide covers one stage in isolation — so there's nowhere to send someone who just wants to get a browser running and then take it to production.
This adds a Quickstart in a new
Get startednav group: install and authenticate → create and drive a browser → watch it → pointers for stealth/proxies/auth → serve a workload from a browser pool.Browser pools are the last stage of this guide rather than a quickstart of their own, so the walkthrough lives here and
/browsers/poolsstays reference-only. Its "Full example" moves into this guide, and the pools page gets a short pointer back.Also drops the stale
/quickstart→/redirect, left over from when an earlier quickstart was folded into the home page — without removing it, the new page would be shadowed. The home page's "start here" now links into the guide.Content notes
finally(an unreleased browser staysacquireduntil timeout and the pool drains),reuse: truehands the same browser — cookies and logins included — to the next caller, and idle pooled browsers aren't billed but their capacity still counts against the concurrency limit.brew install kernel/tap/kernel/npm install -g @onkernel/cli,kernel login,kernel api-keys create, andKERNEL_API_KEYfor the SDKs.Get startedsits belowOverview, so the sidebar still leads with Introduction.Base branch
This is stacked on
hypeship/browser-pools-docs-refresh(#464) rather thanmain, because the pools-page edits here depend on that branch renamingbrowsers/pools/overview.mdx→browsers/pools.mdx. Merge #464 first, then this. Its diff shows only the quickstart changes.Verification
docs.jsonis valid JSON; every nav entry resolves to a file;quickstartis in the nav; no stale/quickstartredirect remains.quickstart.mdx; all internal links andCardhrefs resolve, including/browsers/pools#sizing-a-browser-pool.mint devnot booted in this environment, so the page isn't visually confirmed — worth a preview pass.Needs a human call
#278 ("Redesign quickstart with agent-first one-command approach") also creates
quickstart.mdx. I left it untouched. Close it, or fold its one-command approach into this guide before merge — the home page already carries a copy-prompt setup box that covers similar ground.🤖 Generated with Claude Code