Skip to content

Refresh browser pool guides and standardize on "browser pools" - #464

Merged
andrewleesteele merged 28 commits into
mainfrom
hypeship/browser-pools-docs-refresh
Aug 5, 2026
Merged

Refresh browser pool guides and standardize on "browser pools"#464
andrewleesteele merged 28 commits into
mainfrom
hypeship/browser-pools-docs-refresh

Conversation

@andrewleesteele

@andrewleesteele andrewleesteele commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Summary

Browser pools weren't surfaced where a user decides to go to production — the concept was called "Reserved Browsers" in the sidebar, and the Create page never mentioned them. And the pools page itself had grown into a tutorial and an API reference wearing one hat, explaining the same handful of facts three and four times over.

This PR is scoped to browser pools documentation. The end-to-end quickstart is #470 (stacked on this branch), and the broader docs IA rework — replacing Basics/Intermediate/Advanced with lifecycle groups — is tracked separately. (Merged main to pick up #469, which moved Chrome policies to a standalone page.)

1. One name: "browser pools", and every other "pool" qualified. The API, SDKs, CLI, and dashboard already said "browser pools" — the docs were the outlier. Renamed the sidebar group, dropped "reserved browsers" as a product name, and swept bare "pool" → "browser pool" in prose. "Pool" is overloaded here, so the other senses are disambiguated too: "connection pool" on the curl networking limits, "managed proxy pool" on bot-detection. ("ISP pool" and the unikernels page's "warm pools" were already unambiguous.)

2. Not described as "warm". Per docs-team feedback on this PR, "warm" implies pools run hot and bill for idle time — the opposite of the actual benefit. Now "ready to use" / "pre-provisioned", and the pricing line leads with the benefit: "an idle browser pool costs nothing between tasks."

3. One page at /browsers/pools. The section was three pages (overview + FAQ + Chrome policies); it's now one, served at /browsers/pools rather than /browsers/pools/overview. The FAQ folded in, Chrome policies left via #469, the nav group collapsed to a single entry, and a redirect covers the old path. The changelog's bare /browsers/pools links — previously 404s — now resolve, because that's where the page actually lives.

4. Deduped. The intro explained "config is pre-applied so acquisition is faster" four times; read-only profiles appeared three times; update/stale-config semantics three times, including a paragraph duplicated verbatim two paragraphs later; refresh_on_profile_update three times. Merged the three profile sections into one "Profiles with browser pools", moved the stale-config warning to "Update a pool" where it belongs, replaced "Pool configuration options" with a short Configuration pointer, and moved Sizing next to the acquire/release lifecycle.

5. Pitched where users move to production, workload-driven. An "On demand or from a browser pool" section on introduction/create (build with browsers.create(), move to a pool once you're repeating the same task), plus pointers from the home page and Scale. Fundamentals first, then pools — not a day-one default, not an afterthought.

6. Scale page rewritten. It was written pre-launch and framed pools around three co-equal factors with a blunt "<50 concurrency → don't bother" gate. Now: benefit (low-latency acquisition, reserved capacity, higher creation throughput; the concurrency-limit tradeoff) → when to use vs on-demand (workload signals, not thresholds) → sizing (links to the pools page), keeping the three architecture patterns and dropping their numeric gates.

7. Content gaps closed.

  • Reuse semanticsreuse: true (default) returns the same browser with cookies/storage/sessions intact, so it's fast but not isolated; reuse: false is clean at the cost of a rebuild. Multi-tenant leak warning added.
  • Why acquiring is faster — pre-applied restart-triggering configs, and no browser-creation rate limit.
  • Read-only profiles — point to the per-user-profiles pattern instead of "use a standalone session," which undersold it.
  • Sizing — watch available_count, target 10–20% available; a small pool still pays off when acquisition latency matters, with no concurrency-number gate.
  • Limitations — new section: no GPU browsers, one fixed config per pool (start_url the only per-acquire override), read-only profiles, reserved capacity holds concurrency slots whether or not acquired, Start-Up/Enterprise only.
  • fill_rate_per_minute example aligned with the documented 25% default (was 10, which read as a competing default).

Verification

  • Merged origin/main; resolved docs.json and took main's canonical browsers/chrome-policies.mdx.
  • docs.json valid; every nav page resolves to a file; the pools entry is a single browsers/pools page; no stale overview/faq/policy-json nav refs.
  • All internal /browsers/pools/overview links repointed; a stale #create-a-pool-of-reserved-browsers anchor fixed; every in-page anchor resolves; externally-linked anchors preserved (#how-browser-pools-work, #create-a-pool, #update-a-pool, #sizing-a-browser-pool, #per-user-profiles-with-pools).
  • Redirects: /browsers/pools/overview/browsers/pools (new), /browsers/pools/policy-json/browsers/chrome-policies (from Move Chrome Policies to Advanced and clarify it applies to individual browsers #469).
  • API details verified against the OpenAPI spec — 25% default fill rate, 600s default timeout. Correction: an earlier revision of this PR claimed size is required on update; it isn't. size is required on create only, and optional on update (param.Opt[int64], "If provided, replaces the number of browsers to maintain in the pool"). The note asserting otherwise has been removed, along with the Go update sample that passed a bare int for that optional field. "Acquire isn't rate-limited" verified against the API's rate-limiter: only POST /browsers is rate-limited.
  • mint dev not booted in this environment, so the pages aren't visually confirmed. Worth a preview pass before merge.

Related

🤖 Generated with Claude Code


Note

Low Risk
Documentation-only changes with redirects for old URLs; no application code or API behavior changes.

Overview
Consolidates browser pools documentation into a single page at /browsers/pools, removes browsers/pools/overview.mdx and browsers/pools/faq.mdx, adds redirects, and collapses the nav from a "Reserved Browsers" group to one entry.

Standardizes terminology across the docs: "browser pools" (not "reserved browsers"), "ready to use" / "pre-provisioned" instead of "warm" or "pre-warmed", and qualified "pool" where it means something else (e.g. connection pool, managed proxy pool).

Rewrites and dedupes the pools guide—lifecycle, limitations, sizing, profiles (including per-user + reuse: false), refresh_on_profile_update, and update/stale-config warnings—while dropping repeated FAQ/API-tutorial content.

Surfaces pools on the production path: new On demand or from a pool on introduction/create, refreshed Scale (benefits vs on-demand, workload-based when-to-use, sizing link; removes numeric concurrency gates), home scaling blurb, and a Browser Pool concept in info/concepts.mdx.

Updates cross-links sitewide from /browsers/pools/overview to /browsers/pools and tightens pricing/projects copy around idle pool billing and concurrency.

Reviewed by Cursor Bugbot for commit 0281a92. Bugbot is set up for automated code reviews on this repo. Configure here.

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.
@vercel

vercel Bot commented Jul 28, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
docs Error Error Aug 5, 2026 4:19pm

@mintlify

mintlify Bot commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
Kernel 🟢 Ready View Preview Jul 28, 2026, 2:37 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

@mintlify

mintlify Bot commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
Kernel 🟡 Building Jul 28, 2026, 2:36 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

@andrewleesteele

Copy link
Copy Markdown
Contributor Author

Note: Hypeship prematurely created this PR...still thinking necessary changes through.

- 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>
cursor[bot]
cursor Bot approved these changes Jul 29, 2026
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>

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Risk assessment: Very Low

Verdict: Very Low risk — prior approval retained (risk did not increase).

Re-evaluation after synchronize

Previous automation approval was on bf5ab05. Latest HEAD is 0ca62af, which removes browsers/pools/quickstart.mdx, drops its docs.json nav entry, and retargets intro/home links to the overview. That narrows scope; it does not raise risk.

Evidence (from full diff vs base)

  • 10 files, all Mintlify docs: .mdx content plus a docs.json nav label rename (Reserved BrowsersBrowser Pools).
  • Content/terminology updates and example code blocks on pools overview, FAQ, create, scale, pricing, concepts, and related pages.
  • No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
  • No CODEOWNERS file requiring a separate owner approval.

Why this level

  • Documentation-only surface with no production logic or shared runtime impact.
  • Blast radius limited to published docs/nav; easy to reason about and revert.

Actions taken

  • Risk unchanged at Very Low → did not dismiss prior approval.
  • Did not re-approve (approval already present).
  • Did not assign or request reviewers.
Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

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>

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Risk assessment: Very Low

Verdict: Very Low risk — prior approval retained (risk did not increase).

Re-evaluation after synchronize

Previous automation approval was on bf5ab05. Latest HEAD is ad048aa. Since that approval, the branch removed the browser-pools quickstart (already assessed) and made a one-line home-page copy reframe in index.mdx. That does not raise risk.

Evidence (from full diff vs base)

  • 10 files, all Mintlify docs: .mdx content plus a docs.json nav label rename (Reserved BrowsersBrowser Pools).
  • Terminology, guidance, and example code-block updates across pools overview/FAQ, create, scale, pricing, concepts, and related pages.
  • No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
  • No CODEOWNERS file requiring a separate owner approval.

Why this level

  • Documentation-only surface with no production logic or shared runtime impact.
  • Blast radius limited to published docs/nav; easy to reason about and revert.

Actions taken

  • Risk unchanged at Very Low → did not dismiss prior approval.
  • Did not re-approve (approval already present).
  • Did not assign or request reviewers.
Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

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>

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Risk assessment: Very Low

Verdict: Very Low risk — prior approval retained (risk did not increase).

Re-evaluation after synchronize

Previous automation approval was on bf5ab05. Latest HEAD is 8f38449. Since that approval, the branch removed the browser-pools quickstart, reframed home-page copy, folded the FAQ into the overview (deleted browsers/pools/faq.mdx), added a short sizing section, and retargeted a profiles link. That does not raise risk.

Evidence (from full diff vs base)

  • 11 files, all Mintlify docs: .mdx content plus docs.json nav updates (Reserved BrowsersBrowser Pools; FAQ page removed from nav).
  • Terminology, guidance, and example code-block updates across pools overview, create, scale, pricing, concepts, and related pages.
  • No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
  • No CODEOWNERS file requiring a separate owner approval.

Why this level

  • Documentation-only surface with no production logic or shared runtime impact.
  • Blast radius limited to published docs/nav; easy to reason about and revert.

Actions taken

  • Risk unchanged at Very Low → did not dismiss prior approval.
  • Did not re-approve (approval already present).
  • Did not assign or request reviewers.
Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

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>

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Risk assessment: Very Low

Verdict: Very Low risk — prior approval retained (risk did not increase).

Re-evaluation after synchronize

Previous automation approval was on bf5ab05. Latest HEAD is fd9c595. Since that approval, the branch removed the browser-pools quickstart, folded/deleted the FAQ, reframed home-page copy, and (latest) spell-out terminology updates replacing bare "pool" with "browser pool" across docs. That does not raise risk.

Evidence (from full diff vs base)

  • 16 files, all Mintlify docs: .mdx content plus docs.json nav updates (Reserved BrowsersBrowser Pools; FAQ page removed from nav).
  • Terminology, guidance, and example code-block updates across pools overview, create, scale, pricing, concepts, and related pages; FAQ deleted.
  • No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
  • No CODEOWNERS file requiring a separate owner approval.

Why this level

  • Documentation-only surface with no production logic or shared runtime impact.
  • Blast radius limited to published docs/nav; easy to reason about and revert.

Actions taken

  • Risk unchanged at Very Low → did not dismiss prior approval.
  • Did not re-approve (approval already present).
  • Did not assign or request reviewers.
Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

andrewleesteele and others added 2 commits July 29, 2026 23:27
…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>

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Risk assessment: Very Low

Verdict: Very Low risk — prior approval retained (risk did not increase).

Re-evaluation after synchronize

Previous automation approval was on bf5ab05. Latest HEAD is a4c7e45. Since that approval, the branch continued documentation-only work (FAQ fold/delete, terminology standardization, page collapse to /browsers/pools, Scale-page rewrite, pools-page restructuring). Latest delta (f6abf40a4c7e45) edits a single file (browsers/pools.mdx): rewrites the intro into a clearer definition / latency / cost framing. That does not raise risk.

Evidence (from full diff vs base)

  • 26 files, all Mintlify docs: .mdx content plus docs.json nav/redirect updates (Reserved Browsers → single browsers/pools entry; FAQ removed; /browsers/pools/overview/browsers/pools).
  • Terminology, guidance, and example code-block updates across pools, create, scale, pricing, concepts, and related pages; FAQ and old overview deleted in favor of one pools page.
  • Latest delta: 1 file, docs prose only (+4 / −2).
  • No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
  • No CODEOWNERS file requiring a separate owner approval.

Why this level

  • Documentation-only surface with no production logic or shared runtime impact.
  • Blast radius limited to published docs/nav; easy to reason about and revert.

Actions taken

  • Risk unchanged at Very Low → did not dismiss prior approval.
  • Did not re-approve (approval already present).
  • Did not assign or request reviewers.
Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

- Drop the "size is always required on update" note: size is optional on
  update (required only on create), and following the note risks resizing
  the pool as a side effect of an unrelated config change.
- Fix the Go update sample, which passed a bare int for an optional field.
- Rework the sizing section: gloss available_count/acquired_count in prose,
  and match the page's bold-lead-in bullet pattern.
- Fold the one-line flush subsection into the update warning that already
  referenced it, and add flush to the API reference pointer.
- Drop the "pre-" from the page description.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Risk assessment: Very Low

Verdict: Very Low risk — prior approval retained (risk did not increase).

Re-evaluation after synchronize

Previous automation approval was on bf5ab05. Latest HEAD is d67b61c. Since that approval, the branch continued documentation-only work (FAQ fold/delete, terminology standardization, page collapse to /browsers/pools, Scale/Create rewrites, pools-page tightening).

Latest delta since the prior assessment (a4c7e45d67b61c): copy and sample fixes in browsers/pools.mdx only — drop incorrect “size always required on update” guidance, correct the Go update sample (kernel.Int(20)), rework sizing bullets, and fold flush into the existing update warning. That does not raise risk.

Evidence (from diff only)

  • 26 files, +402 / −722 — all Mintlify .mdx or docs.json
  • Consolidates browser pools docs onto /browsers/pools, adds overview→pools redirect, updates nav
  • Cross-page link/terminology updates (“browser pool”) and intro/scale/pricing prose
  • No application code, infra, auth/billing logic, schemas, or shared libraries
  • No CODEOWNERS requirement found

Decision

Risk remains Very Low. Prior approval stands; not re-approving.

Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

A browser pool and browsers.create() are two ways of provisioning the same
browser, not two instruments to pick between, so "the right tool" reads
oddly here. Use the verb the section below already uses.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Risk assessment: Very Low

Verdict: Very Low risk — prior approval retained (risk did not increase).

Re-evaluation after synchronize

Previous automation approval was on bf5ab05. Latest HEAD is 327ca95. Since that approval, the branch continued documentation-only work (FAQ fold/delete, terminology standardization, page collapse to /browsers/pools, Scale/Create rewrites, pools-page tightening).

Latest delta since the prior assessment (d67b61c327ca95): one-line copy edit in introduction/scale.mdx ("when a browser pool is the right tool" → "when to reach for a browser pool"). That does not raise risk.

Evidence (from diff only)

  • 26 files, +402 / −722 — all Mintlify .mdx or docs.json
  • Consolidates browser pools docs onto /browsers/pools, adds overview→pools redirect, updates nav
  • Cross-page link/terminology updates and intro/scale/pricing prose
  • No application code, infra, auth/billing logic, schemas, or shared libraries
  • No CODEOWNERS requirement found

Decision

Risk remains Very Low. Prior approval stands; not re-approving.

Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

@AnnaXWang
AnnaXWang marked this pull request as ready for review August 4, 2026 20:40
Comment thread introduction/scale.mdx Outdated
Comment thread browsers/curl.mdx
Browser curl concurrency is constrained by Chromium's internal networking limits:

- **HTTP/1.x (direct)** — About 6 sockets per host group and up to 256 active sockets per pool.
- **HTTP/1.x (direct)** — About 6 sockets per host group and up to 256 active sockets per connection pool.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is connection pool the same as browser pool?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"connection pool" refers to chromium's internal socket pool (HTTP/1.x sockets), unrelated to browser pools.

Comment thread info/concepts.mdx
## Browser
A `Browser` is a cloud-based browser managed by Kernel. They accept Chrome DevTools Protocol connections and can be used to run browser automations or web agents.

## Browser Pool

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

love this

@AnnaXWang

Copy link
Copy Markdown
Contributor

since we are removing browsers/pools/overview -> can we set up a redirect to /browsers/pools so that URLs that are floating in the wild don't break?

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@andrewleesteele

Copy link
Copy Markdown
Contributor Author

Pushed cd11471:

@AnnaXWang re: redirects — the /browsers/pools/overview/browsers/pools redirect was already in docs.json, but you were right to push on the in-the-wild links: this PR also deletes pools/faq.mdx, and there was no redirect for /browsers/pools/faq — so any externally-pasted link to the old FAQ would've 404'd. Added it now. Full coverage of the old paths:

  • /browsers/pools/overview/browsers/pools
  • /browsers/pools/faq/browsers/pools (new)
  • /browsers/pools/policy-json/browsers/chrome-policies
  • /browsers/pools/scaling/introduction/scale

(These are page-level redirects — old per-question FAQ anchors land on the pools page rather than the exact heading.)

re: Bugbot "reserved browsers" — fixed both: introduction/scale.mdx ("keep reserved browsers utilized" → "keep the browser pool utilized") and info/pricing.mdx ("reserved in a browser pool" → "maintained in a browser pool"). Left the two changelog.mdx mentions as-is since they're historical entries describing what the page was named at the time.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Risk assessment: Very Low

Verdict: Very Low risk — prior approval retained (risk did not increase).

Re-evaluation after synchronize

Previous automation approval was on bf5ab05. Latest HEAD is cd11471. Since that approval, the branch continued documentation-only work (FAQ fold/delete, terminology standardization, page collapse to /browsers/pools, Scale/Create rewrites, pools-page tightening).

Latest delta since the prior assessment (327ca95cd11471): adds /browsers/pools/faq/browsers/pools redirect in docs.json, plus two wording tweaks (reservedmaintained in pricing; "reserved browsers" → "the browser pool" in scale). That does not raise risk.

Evidence (from diff only)

  • 26 files, +403 / −722 — all Mintlify .mdx or docs.json
  • Consolidates browser pools docs onto /browsers/pools, adds overview/faq→pools redirects, updates nav
  • Cross-page link/terminology updates and intro/scale/pricing prose
  • No application code, infra, auth/billing logic, schemas, or shared libraries
  • No CODEOWNERS requirement found

Decision

Risk remains Very Low. Prior approval stands; not re-approving.

Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Risk assessment: Very Low

Verdict: Very Low risk — prior approval retained (risk did not increase).

Re-evaluation

Previous automation approval remains active (bf5ab05). Latest HEAD is cd11471. Full diff vs base is still documentation-only; risk has not increased.

Evidence (from diff only)

  • 26 files, +403 / −722 — exclusively Mintlify .mdx and docs.json
  • Consolidates browser pools docs onto /browsers/pools (deletes overview/FAQ pages), collapses nav (Reserved Browsers → single browsers/pools entry), adds redirects for /browsers/pools/overview and /browsers/pools/faq
  • Cross-page terminology/link updates plus Create/Scale/pricing prose and example code blocks
  • No application/runtime code, APIs, auth/billing logic, infrastructure, schemas, CI/deploy config, or model-prompt instruction files
  • No CODEOWNERS file requiring separate owner approval

Why this level

  • Docs-site content and nav/redirects only; no production logic or shared systems
  • Blast radius limited to published documentation IA and copy; easy to reason about and revert

Actions taken

  • Risk remains Very Low → did not dismiss prior approval
  • Did not re-approve (approval already present)
  • Did not assign or request reviewers
Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

@AnnaXWang
AnnaXWang self-requested a review August 4, 2026 21:47

@AnnaXWang AnnaXWang left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you! i would love to move "browser pools" out of advanced and into intermediate but that probably opens a whole can of worms because other concepts under advanced also arguably should move as well.

@andrewleesteele
andrewleesteele merged commit 74cecd3 into main Aug 5, 2026
5 of 6 checks passed
@andrewleesteele
andrewleesteele deleted the hypeship/browser-pools-docs-refresh branch August 5, 2026 16:19

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 0281a92. Configure here.

Comment thread browsers/pools.mdx

### Per-user profiles with browser pools

Because that profile is shared and read-only, it can't hold per-user login state for many users at once. To serve many users from one browser pool, create it with no profile — stealth, proxies, extensions, and viewport still live on the pool — then attach each user's profile to the browser *after* you acquire it, and release with `reuse: false` so the browser is destroyed. Destroying it both persists that user's profile changes and keeps their state from reaching the next acquirer.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dense per-user steps need bullets

Medium Severity

The per-user profiles flow packs several distinct steps into one dense paragraph (create pool without a profile, attach after acquire, release with reuse: false, persistence and isolation effects). This violates the guide rule to use a lead-in plus bullet/numbered list when covering 3+ separable points. The previous page used a numbered list for the same flow.

Fix in Cursor Fix in Web

Triggered by learned rule: Use bullet lists when covering multiple distinct points in guides

Reviewed by Cursor Bugbot for commit 0281a92. Configure here.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Risk assessment: Very Low

Verdict: Very Low risk — prior automation approval retained (risk did not increase).

Evidence from the diff

Inspected 97f3319...0281a92 (26 files, +403 / −722):

  • Documentation only: All changes are .mdx content plus docs.json navigation/redirects. No application code, CI, infra, auth, billing logic, or shared services.
  • Structure: Consolidates browsers/pools/overview.mdx + browsers/pools/faq.mdx into browsers/pools.mdx, with redirects for the old paths.
  • Content: Terminology standardization to "browser pools", refreshed Scale/Create guidance, pricing/concepts copy updates, and cross-link fixes.
  • Latest sync: Merge of main into the feature branch; still documentation-only surface.

Decision

  • Risk remains Very Low (docs-only; no production logic or infra impact).
  • Automation already approved this PR earlier; per policy, not re-approving.
  • Risk did not increase, so approval is not dismissed.
  • No CODEOWNERS file requiring a separate owners review for approval gating.

Note: PR is already merged; this comment records the re-evaluation after the latest synchronize.

Open in Web View Automation 

Sent by Cursor Automation: Assign PR reviewers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants