# BUGBOT Source: https://docs.browserbase.com/.cursor/BUGBOT # Docs writing and positioning guide **Severity: blocking.** Every rule in this file is mandatory. Flag violations as bugs, not suggestions. Do not approve a PR that violates any of these rules. ## Positioning Browserbase docs are a demand-capture surface. They may use a customer's problem language when needed for discovery or clarity, but they must always resolve that problem using Browserbase's approved product language. * **Ladder to the roof.** Every page must support the core narrative: "The web wasn't built for agents. Browserbase is." Position Browserbase in browser agents, not the entire agents category. * **Lead with one pillar.** For developers, lead with browsers that work where APIs cannot. For leadership, lead with one platform instead of five vendors. At most one other pillar may support the lead. * **Keep browsers at the center.** Do not position Browserbase as generic computer-use software or commodity infrastructure. Do not use roads, pipes, raw compute, or similar metaphors that reduce Browserbase to price per session. * **Use only approved proof.** Do not invent statistics, customer names, performance claims, or superlatives. The approved proof points are 35m+ browser sessions per month; 10,000 customers; Ramp, Microsoft, and Lovable; SOC-2 Type II; Stagehand up to 2x faster with approximately 30% lower cost on repeated actions; and Functions with under 5ms latency to the browser. * **Use the 15/85 or 25/75 API statistic only as an illustrative hook.** Never use it as a headline or as a claim Browserbase must defend. For leadership audiences, prefer the trend framing that 80% of an agent's context lives on the web. * **Never name competitors in public copy.** This includes comparison copy unless PMM has explicitly reviewed it. Do not name Firecrawl, Browser Use, Kernel, HyperBrowser, Steel, Browserless, Anchor, Parallel, Exa, or Tavily. * **Do not oversell agent intelligence.** Browserbase promises browsers, identity, observability, and infrastructure, not smarter agents. ## Writing style These rules are non-negotiable. Flag every violation, even minor ones. * **Brevity is mandatory.** Every sentence must earn its place. Cut filler words ("just," "simply," "basically," "actually," "in order to," "it should be noted that"). If a sentence can be shorter without losing meaning, it must be. * **Sentence case for all titles and headings.** Only capitalize the first word and proper nouns (e.g., "How Browserbase took over the world" not "How Browserbase Took Over the World"). Flag any title-cased heading as a bug. * **Conversational tone, not casual.** Text should sound natural if spoken aloud. Contractions are encouraged ("you'll," "it's," "don't"). No slang, no filler phrases like "let's dive in" or "as you can see." * **Sound like an engineer stating a fact.** Lead with the outcome, prefer explicit language over clever phrasing, and avoid keynote language such as "revolutionizing how AI interacts with the digital world." * **Active voice only.** Flag any use of passive voice (e.g., "the session is created" should be "Browserbase creates the session" or "you create the session"). * **Second person ("you") for the reader.** Always address the reader as "you," never as "we." Flag any use of "we" to mean the reader. * **Oxford comma required.** Always use a comma before "and" or "or" in a list of three or more items. Flag missing oxford commas. * **Capitalize product names** (Browserbase, Stagehand, Playwright, Functions, Search, Identity, etc.) but default to lowercase for everything else. Flag inconsistent capitalization. * **No em dashes.** Flag every U+2014 em dash character in docs copy, frontmatter, tables, and code comments as blocking. Use judgment to recommend the clearest rewrite with a period, colon, comma, parentheses, or a rephrased sentence. Plain hyphens are allowed when they are semantically correct, such as compounds, ranges, product names, and command flags. Do not recommend replacing an em dash with a hyphen that still acts like an em dash. * **Exception:** em dashes are allowed inside fenced example content that readers copy verbatim: system prompts, model prompts, sample task strings, and pasted config/log snippets. The Agent copies these into its own runtime, so preserve authorial voice. * **`Agent` casing.** Capitalize `Agent` and `Agents` when the word refers to the Browserbase product/feature or a concrete instance of it. Lowercase only when discussing agents as a generic industry concept. Flag mismatches. * Write "Create an Agent," "your first Agent run," "the Agent's goal," "Job Finder Agent," "an Agent renders each page." * Write "browser agents adapt to sites that change" or "the SDK for browser agents" (generic category). * API endpoint names track the OpenAPI spec: "Run an Agent," "Create an Agent," "List Agents." * **No secrets in example prompts.** Never embed credentials, API keys, tokens, or personal data directly in example prompts, task strings, or code samples. Use `%variableName%` placeholders (Agent variables) or environment variables (`$BROWSERBASE_API_KEY`). Flag inline credentials as blocking. * **No placeholder or dead links.** Flag any `](#)` or obviously broken href as blocking. Use canonical paths for repeated destinations: * Stagehand: `/welcome/quickstarts/stagehand` * Dashboard: `https://www.browserbase.com/overview` * Agents overview: `/platform/agents/overview` * Agents API endpoints under `/reference/api/...`. * **Never use "we," "us," or "our" for Browserbase.** Always refer to the company by name. This applies to first-person plural in any form: subject ("we"), object ("us"), possessive ("our"), and contractions ("we're," "we've," "we'll"). Flag every instance. * Write "Browserbase recommends" not "we recommend." * Write "Browserbase provides" not "we provide." * Write "Browserbase's infrastructure" not "our infrastructure." * Write "Browserbase supports both transports" not "we support both transports." * Exception: direct quotes from customers or team members in case studies. ## Tagline * Current: "Give your agents access to the whole web." * Deprecated (flag if seen): "Agents can now browse and interact with the web like humans." * Deprecated (flag if seen): "Autonomously read, write, and perform tasks on the web with a headless browser." ## Structure and formatting * Make content easy to skim: use bullet points, break up text, include images/videos/tables where helpful. * Headlines should outline a clear structure and make sense on their own. * Lead with the main information. Get to the point fast, add details later. Front-load keywords for scanning. * Make customer choices and next steps obvious. ## Code examples * Default to SDK code examples over raw API calls whenever possible. * Label every Node.js code block as `Node.js`, including snippets written in TypeScript or JavaScript. Keep the syntax language for highlighting, then add the visible label, such as `typescript Node.js` or `javascript Node.js`. Never present these snippets as `TypeScript`, `TS`, `JavaScript`, or `JS`. * Define OpenAPI `x-codeSamples` in the owning API route schema under `apps/api/src/routes/`. Never edit generated code samples only in `apps/docs/reference/api/openapi.v1.yaml`; `pnpm run gen-swagger` overwrites that file. After changing route schemas, run `pnpm run gen-swagger` from `apps/api/`, and commit the generated spec. * Highlight the pieces that are changing and link out to related docs. ## SEO * Write with new users, search terms, and AI consumption in mind. ## Terminology Use these terms consistently: | Use this | Not this | | ------------------------------------------------------------------------- | --------------------------------- | | browser agent | web agent | | agents | AI (in most external copy) | | headless browsers | serverless browsers | | Verified, for the customer-facing access feature | Stealth Mode or Agent Identity | | Agent Identity, for Web Bot Auth, Signed Agents, and agent-owned accounts | Verified or stealth | | SDK for browser agents (Stagehand) | browser automation framework | | agents | agentic workflows | | browser agent platform (Browserbase) | browser automation infrastructure | * When listing platform primitives, always put browsers first. * Capitalize `Browser Agent` and `Browser Agent Platform` when naming the category. Never use `Web Agent`. * Use `agents` in headings and body copy. `AI Agent` and `AI Agents` are allowed only in SEO or tab titles and on first-touch surfaces for non-AI-native readers. * Don't lead with Search or Fetch as standalone products; browsers are the core. * Do not blur Agents and Stagehand. Agents is the managed API product. Stagehand is the SDK and AI browser driver. * Never include Director in product lists or copy. Director is sunset. * `Automation` is allowed when it describes the user's outcome, speaks to legacy automation or RPA users, or matches demand-capture search terms. * `Scraping`, `scraper`, `crawler`, and related terms require case-by-case PMM review. They may match a customer's use-case language, but must not appear in an H1, page title, or sidebar title. * Don't position around benchmarks that can't be defended ("best search API," "fastest fetch"). ### Access and identity language * Docs may use `stealth`, `blocked`, `bot detection`, `anti-bot`, and similar customer language only to name or explain the problem. Never use these terms to name Browserbase, the platform, or a Browserbase product. * Ladder from the customer's words to Browserbase's answer: their problem (`stealth`, `blocked`, or `CAPTCHA`) to **Verified**, then to the differentiation of **Agent Identity** and Web Bot Auth. * The only valid positioning frame for `stealth` is educational: identity is stronger than stealth. Never claim that Browserbase has better stealth. * `CAPTCHA` and `CAPTCHA solving` are allowed when describing a solution, such as "solving CAPTCHAs." * Never use bot-protection vendor or product trademarks in public copy, including `reCAPTCHA`, `hCaptcha`, `Turnstile`, and `Cloudflare`. * Preserve exact API parameters, error messages, code identifiers, and quoted third-party text when technical accuracy requires them. Do not promote those identifiers into headings or product names. ### Restricted use cases Never create or approve use-case pages, demos, examples, growth hooks, SEO or SEM copy, or sales promises around: * Apple domains, including iTunes and the App Store * Entertainment, including Netflix and PlayStation * Banking and other financial institutions * Google domains without explicit approval * Streaming * Event ticketing, including Ticketmaster (travel such as flights is allowed) * LinkedIn * Mailing Flag any copy that touches a restricted use case for PMM review before it ships. ## Product descriptions Use these canonical descriptions when referring to Browserbase products: * **Browserbase**: the complete platform to run agents that use the web like humans. * **Browsers**: the core; browsers that work where APIs can't. * **Agents**: API for reusable browser agents, with no code or deployment. * **Search and Fetch**: primitives that give agents fast, token-efficient web context. * **Functions**: run code next to the browser and deploy instantly, with under 5ms latency to the browser. * **Model Gateway**: access to major models via a single Browserbase API key with unified billing. * **Agent Identity**: the attestation layer for Web Bot Auth, Signed Agents, and agent-owned accounts. * **Verified**: the customer-facing feature that gives agents reliable access when websites block automation. * **Stagehand**: the SDK and AI browser driver for browser agents. * **Browse.sh**: the open web skills catalog, accessed through the Browse CLI. # Billing Source: https://docs.browserbase.com/account/billing/plan-management Manage your subscription, invoices, and payment details ## Upgrade your plan To upgrade to Developer or Startup plans, go to [Settings](https://www.browserbase.com/settings), then **Usage & billing > Change plan**. Upgrading to a Scale plan requires the Browserbase team. [Book a demo](https://www.browserbase.com/contact) to get started. You can also reach us at [sales@browserbase.com](mailto:sales@browserbase.com). [Verified](/platform/identity/agent-identity) is available on Scale plans. Learn what Verified includes and how it works. ## Invoices ### Understanding your invoice Here's the breakdown of your monthly bill: * Base Plan Cost * Proxy Costs * Browser Time Costs A Developer Plan with overages appears like this on an invoice: Stripe Invoice You can also manage this on your Organization settings page under "Manage Billing": [https://www.browserbase.com/orgs/\{slug}/settings/billing](https://www.browserbase.com/orgs/\{slug}/settings/billing) ### Adding VAT to invoices To add your tax ID to future invoices: 1. Go to **Settings** > **Usage** > **Manage organization plan** 2. Click **Manage billing** to open the Stripe customer portal 3. Click **Update information** and add your tax ID Your tax ID will appear on all future invoices. Need your tax ID added to a previous invoice? Reach out via the [support page](https://portal.usepylon.com/browserbase/forms/talk-to-an-engineer) or [support email](mailto:support@browserbase.com). ## Cancel your plan To cancel your Browserbase plan, go to [Settings](https://www.browserbase.com/settings), then **Usage & billing > Change plan**. # Plans Source: https://docs.browserbase.com/account/billing/plans Your guide to Browserbase plans, pricing, and usage limits ## Pick a plan Browserbase scales from solo builders to enterprise teams. Start free, no credit card needed. Includes 3 concurrent sessions. Small projects and hobby usage: unlocks proxies. Production workloads: 100 concurrent and priority support. Enterprise volume, [Verified](/platform/identity/overview), and compliance (SSO, HIPAA, DPA). ## What's included Each plan includes a monthly allocation of browser hours and proxy bandwidth (and more). Go beyond it and pay-as-you-go [overage rates](#browser-allocations) apply. No caps. No cut-offs. Hosted [Functions](/platform/runtime/overview) are free on every plan. Need help estimating your plan? [Reach out here ↗](https://www.browserbase.com/contact). ### Browser allocations Browser hours and proxy bandwidth are allocations, not limits. If you exceed them, pay-as-you-go overage rates apply. | | Free \$0 | Developer \$20 | Startup \$99 | Scale plan | | ----------------- | -------- | -------------- | ------------ | ----------- | | **Browser Hours** | 1 hr | 100 hrs | 500 hrs | Flexible | | *Hours overage* | N/A | \$0.12/hr | \$0.10/hr | Custom | | **Proxy** | 0 GB | 1 GB | 5 GB | Usage-based | | *Proxy overage* | N/A | \$12/GB | \$10/GB | Custom | Browser time is billed by the minute and proxy bandwidth by the MB, rounded, with a one-minute and one-MB minimum per session. ### Browser capacity limits How many browsers you can start, run at once, and for how long. | | Free \$0 | Developer \$20 | Startup \$99 | Scale plan | | -------------------- | -------- | -------------- | ------------ | ---------- | | **Concurrency** | 3 | 25 | 100 | 250+ | | **Session Duration** | 15 mins | 6 hrs | 6 hrs | 6+ hrs | | **Session Creation** | 5/min | 25/min | 50/min | 150+/min | Each plan limits how many sessions you can create per minute. If you attempt to create too many sessions in a short time, you might temporarily hit your cap, even if you haven't reached max concurrency. > For example: On the Startup Plan, your session creation limit is 50 per minute and your max concurrency is 100. It will take about 2 minutes to spin up all 100 sessions. In most workflows, this won't be an issue. If your sessions are short-lived, consider using the [keep-alive feature](/platform/browser/long-sessions/overview#keep-alive-sessions) to reuse sessions instead of creating new ones. ### API allocations Agents, Search, Fetch, and Extract each have a monthly allocation, and then pay-as-you-go overage rates. | | Free \$0 | Developer \$20 | Startup \$99 | Scale plan | | --------------------- | ----------- | -------------- | -------------- | ---------- | | **Agents** | 3 calls | 15 calls | 50 calls | Custom | | **Search** | 1,000 calls | 1,000 calls | 1,000 calls | Custom | | **Search rate limit** | 2/sec | 2/sec | 2/sec | Custom | | *Search overage* | N/A | \$7/1k calls | \$7/1k calls | Custom | | **Fetch** | 1,000 calls | 1,000 calls | 10,000 calls | Custom | | **Fetch rate limit** | 5/sec | 5/sec | 5/sec | Custom | | *Fetch overage* | N/A | \$1/1k calls | \$0.5/1k calls | Custom | | *Extract overage* | N/A | \$4/1k calls | \$4/1k calls | Custom | Routing through proxies costs more. Fetch with proxies is \$4/1k calls, and Extract with proxies is \$7/1k calls. ### Identity & bot detection How well your sessions avoid bot detection and solve captchas, from Basic to Verified. | | Free \$0 | Developer \$20 | Startup \$99 | Scale plan | | ------------------------------------------- | -------- | -------------- | ------------ | ---------- | | [**Verified**](/platform/identity/overview) | No | Basic | Basic | Verified | | **Captcha** | No | Auto | Auto | Auto | ### Account Settings that live on your Browserbase Organization, such as data retention, projects, and support tier. | | Free \$0 | Developer \$20 | Startup \$99 | Scale plan | | ------------------ | -------- | -------------- | ------------ | ------------- | | **Data Retention** | 7 days | 7 days | 30 days | 30+ days | | **Projects** | 1 | Up to 2 | Up to 5 | 5+ | | **Support** | Email | Standard | Priority | High Priority | > Tip: Monitor your usage from [your dashboard ↗](https://www.browserbase.com/overview) to avoid surprises. ### Security & compliance | | Free \$0 | Developer \$20 | Startup \$99 | Scale plan | | --------- | -------- | -------------- | ------------ | ------------------- | | **SOC2** | Yes | Yes | Yes | Pen Tests & Reports | | **HIPAA** | No | No | No | BAA Available | | **DPA** | No | No | No | Available | | **SSO** | No | No | No | Available | ## Custom plans For high-scale workloads or specific compliance needs, [book a demo ↗](https://www.browserbase.com/contact) with the Browserbase team. The team will help tailor a plan that fits your technical and business requirements. You can also reach us at [sales@browserbase.com](mailto:sales@browserbase.com). # Bring your own storage (BYOS) Source: https://docs.browserbase.com/account/enterprise/byos-setup-guide Configure your own AWS S3 buckets for storing Browserbase artifacts Bring Your Own Storage (BYOS) allows enterprise customers to store Browserbase artifacts in their own AWS S3 buckets, providing complete control over data residency and compliance. BYOS is available only on Enterprise plans. [Contact the Browserbase team](https://www.browserbase.com/contact) to enable BYOS for your organization. Artifacts without configured external storage automatically use Browserbase's internal storage. *** ## What gets stored Browserbase generates several types of artifacts during sessions: | Artifact Type | Description | Permissions needed | Status | | ------------------------ | ---------------------------------------- | ------------------ | ----------- | | **downloads** | Files downloaded during sessions | Write only | Available | | **extensions** | Browser extensions loaded into sessions | Read only | Available | | **uploads** | Files uploaded to sessions | Read/Write | Available | | **contexts** | Session context files (cookies, storage) | Read/Write | Available | | **recording-renditions** | Session recording MP4 downloads | Write only | Available | | **logs** | Console logs and CDP debug output | Write only | Coming Soon | You can configure some or all artifact types for external storage. Unconfigured types will use Browserbase's internal buckets. **Session logs** are currently stored in Browserbase's managed infrastructure; BYOS support for logs is planned for a future release. Browserbase enables recording downloads (`recording-renditions`) per project. Contact your account manager to turn them on. *** ## Setup instructions ### Step 1: Create S3 buckets Create S3 buckets in your AWS account for the artifact types you want to store externally. ```bash theme={null} # Create buckets in your desired regions aws s3 mb s3://company-browserbase-downloads --region us-east-1 aws s3 mb s3://company-browserbase-contexts --region us-west-2 # A single bucket can store multiple artifact types # They'll be separated by path prefix (downloads/, contexts/, extensions/, uploads/) aws s3 mb s3://company-browserbase-storage --region us-east-1 ``` ### Step 2: Generate external ID Generate a cryptographically random external ID for secure role assumption: ```bash theme={null} openssl rand -hex 32 ``` Store the External ID securely. You'll need it for both the IAM role configuration and when providing credentials to Browserbase. ### Step 3: Create IAM role Create an IAM role that Browserbase will assume to access your buckets. **Trust Policy** (`trust-policy.json`): ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::BROWSERBASE_ACCOUNT_ID:role/svc_byos_accessor" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "YOUR_EXTERNAL_ID_FROM_STEP_2" } } } ] } ``` This follows the [AWS third-party access pattern](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html). The principal is Browserbase's dedicated BYOS accessor role, which is used by all internal services that need to access your buckets. Contact Browserbase via your account manager or [support@browserbase.com](mailto:support@browserbase.com) for Browserbase's AWS account ID. The role name `svc_byos_accessor` is fixed and should not be changed. This is Browserbase's internal service role that assumes your customer role. ```bash Create Role theme={null} aws iam create-role \ --role-name browserbase-byos-access \ --assume-role-policy-document file://trust-policy.json ``` **Role name must start with `browserbase-`**. For security, Browserbase can only assume roles matching the pattern `browserbase-*`. Examples: `browserbase-byos-access`, `browserbase-storage`, `browserbase-prod`. ### Step 4: Configure S3 permissions Attach permissions to your IAM role for bucket access. **Permissions Policy** (`permissions-policy.json`): ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid": "BrowserbaseReadAccess", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::company-browserbase-extensions", "arn:aws:s3:::company-browserbase-extensions/*" ] }, { "Sid": "BrowserbaseReadWriteUploads", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::company-browserbase-uploads", "arn:aws:s3:::company-browserbase-uploads/*" ] }, { "Sid": "BrowserbaseWriteAccess", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::company-browserbase-downloads", "arn:aws:s3:::company-browserbase-downloads/*" ] }, { "Sid": "BrowserbaseReadWriteAccess", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::company-browserbase-contexts", "arn:aws:s3:::company-browserbase-contexts/*" ] } ] } ``` **Why ListBucket?** This permission on the bucket itself (without `/*`) is required for: * Paginating through large numbers of objects efficiently * Checking if objects exist before operations * Proper error handling when artifacts are missing Without it, Browserbase can't determine if a missing artifact is due to permissions or if it truly doesn't exist. ```bash Attach Policy theme={null} aws iam put-role-policy \ --role-name browserbase-byos-access \ --policy-name browserbase-s3-access \ --policy-document file://permissions-policy.json ``` ### Step 5: Submit configuration Send this information to your Browserbase account manager or [support@browserbase.com](mailto:support@browserbase.com): ```json theme={null} { "role_arn": "arn:aws:iam::123456789012:role/browserbase-byos-access", "external_id": "a1b2c3d4e5f6...", "project_ids": ["proj_abc123", "proj_def456"], "buckets": [ { "artifact_type": "downloads", "bucket_arn": "arn:aws:s3:::company-browserbase-downloads", "region": "us-east-1" }, { "artifact_type": "contexts", "bucket_arn": "arn:aws:s3:::company-browserbase-contexts", "region": "us-west-2" }, { "artifact_type": "uploads", "bucket_arn": "arn:aws:s3:::company-browserbase-uploads", "region": "us-east-1" }, { "artifact_type": "extensions", "bucket_arn": "arn:aws:s3:::company-browserbase-extensions", "region": "us-east-1" } ] } ``` **Required fields:** * `role_arn`: The IAM role ARN from Step 3 * `external_id`: The external ID from Step 2 * `project_ids`: Array of project IDs that should use this BYOS configuration * `buckets`: Array of bucket configurations with artifact\_type, bucket\_arn, and region *** ## Configuration examples ### Minimal setup (downloads only) ```json theme={null} { "role_arn": "arn:aws:iam::123456789012:role/browserbase-byos-access", "external_id": "a1b2c3d4...", "project_ids": ["proj_abc123"], "buckets": [ { "artifact_type": "downloads", "bucket_arn": "arn:aws:s3:::company-downloads", "region": "us-east-1" } ] } ``` ### Complete setup (all available artifact types) ```json theme={null} { "role_arn": "arn:aws:iam::123456789012:role/browserbase-byos-access", "external_id": "a1b2c3d4...", "project_ids": ["proj_abc123", "proj_def456"], "buckets": [ { "artifact_type": "downloads", "bucket_arn": "arn:aws:s3:::company-downloads", "region": "us-east-1" }, { "artifact_type": "contexts", "bucket_arn": "arn:aws:s3:::company-contexts", "region": "us-east-1" }, { "artifact_type": "extensions", "bucket_arn": "arn:aws:s3:::company-extensions", "region": "us-east-1" }, { "artifact_type": "uploads", "bucket_arn": "arn:aws:s3:::company-uploads", "region": "us-east-1" } ] } ``` ### Multi-region setup ```json theme={null} { "role_arn": "arn:aws:iam::123456789012:role/browserbase-byos-access", "external_id": "a1b2c3d4...", "project_ids": ["proj_abc123"], "buckets": [ { "artifact_type": "downloads", "bucket_arn": "arn:aws:s3:::company-downloads-us", "region": "us-east-1" }, { "artifact_type": "contexts", "bucket_arn": "arn:aws:s3:::company-contexts-eu", "region": "eu-central-1" }, { "artifact_type": "uploads", "bucket_arn": "arn:aws:s3:::company-uploads-ap", "region": "ap-southeast-1" } ] } ``` ### Single bucket for all types ```json theme={null} { "role_arn": "arn:aws:iam::123456789012:role/browserbase-byos-access", "external_id": "a1b2c3d4...", "project_ids": ["proj_abc123", "proj_def456", "proj_ghi789"], "buckets": [ { "artifact_type": "downloads", "bucket_arn": "arn:aws:s3:::company-browserbase-storage", "region": "us-east-1" }, { "artifact_type": "contexts", "bucket_arn": "arn:aws:s3:::company-browserbase-storage", "region": "us-east-1" }, { "artifact_type": "extensions", "bucket_arn": "arn:aws:s3:::company-browserbase-storage", "region": "us-east-1" }, { "artifact_type": "uploads", "bucket_arn": "arn:aws:s3:::company-browserbase-storage", "region": "us-east-1" } ] } ``` *** ## Troubleshooting **Check:** 1. Trust policy principal includes Browserbase's AWS account ID 2. External ID in trust policy matches what you provided to Browserbase 3. Role has permissions for specific bucket ARNs 4. Both bucket-level and object-level permissions are granted **Common Fix:** Ensure your bucket policy or role policy includes both: ``` arn:aws:s3:::bucket-name (for ListBucket) arn:aws:s3:::bucket-name/* (for GetObject/PutObject) ``` **Symptom:** `PermanentRedirect` or "bucket must be accessed via specific endpoint" **Fix:** * Verify the region in your configuration matches your bucket's actual region * S3 buckets are region-specific and must be accessed via the correct endpoint **Check:** 1. Artifact type is correctly configured 2. Bucket path structure: `{artifactType}/{sessionId}/{key}` 3. Write permissions (`s3:PutObject`) are granted 4. No bucket policies blocking access *** ## FAQs Yes, use the `project_ids` field to specify which projects should use a BYOS configuration. You can create multiple configurations with different `project_ids` arrays to route different projects to different buckets. Yes, Browserbase separates artifact types using path prefixes (e.g., `downloads/`, `contexts/`, `extensions/`, `uploads/`), so they won't conflict in a shared bucket. Historical artifacts remain in Browserbase's internal storage. Only new artifacts created after BYOS is enabled will be stored in your buckets. Contact support if you need to migrate existing data. No, configure only the types you want to store externally. Unconfigured types automatically use Browserbase's internal storage. Yes, delete the IAM role or modify the trust policy to remove Browserbase's principal. This immediately prevents access, but active sessions may fail if they can't write artifacts. You control retention through S3 lifecycle policies on your buckets. Browserbase doesn't delete artifacts from your external buckets. You manage the full lifecycle. Browserbase organizes artifacts with this path structure: ``` {artifact_type}/{sessionId}/{key} ``` **Examples:** * `downloads/session-abc123/document.pdf` * `contexts/session-abc123/cookies.json` * `extensions/session-abc123/extension.crx` * `uploads/session-abc123/input-file.csv` This structure allows you to use the same bucket for multiple artifact types, separated by path prefix. **CloudTrail Logging:** * Audit `AssumeRole` calls from Browserbase by AWS account ID * Track S3 operations (`GetObject`, `PutObject`) * Monitor failed access attempts for security **CloudWatch Alarms:** * Alert on failed `AssumeRole` attempts * Monitor `4xx` error rates on your buckets * Track storage growth **S3 Lifecycle Policies:** * Configure automatic archival to Glacier for cost savings * Set expiration rules based on compliance requirements **Encryption:** ```bash theme={null} aws s3api put-bucket-encryption \ --bucket your-bucket \ --server-side-encryption-configuration '{ "Rules": [{ "ApplyServerSideEncryptionByDefault": { "SSEAlgorithm": "AES256" } }] }' ``` # Enterprise security Source: https://docs.browserbase.com/account/enterprise/security SOC 2 Type II, HIPAA compliance, zero-trust browser isolation, and enterprise-grade security for Browserbase infrastructure. Browserbase is secure infrastructure for browser agents at scale. Leading companies in finance, healthcare, and government trust Browserbase with sensitive data. For full details, visit the [Trust Center](https://trust.browserbase.com/). ## Security architecture at a glance | Feature | Implementation | | -------------------- | --------------------------------------------------------------- | | **Isolation** | 1 browser per VM | | **Network security** | Individual subnets and strict firewall rules | | **Logging control** | Optional; disable logs and session video recordings at any time | | **Data residency** | Configurable by region (US/EU/Asia) | | **Model control** | BYO-LLM with full interceptor customization | | **Compliance** | SOC 2 Type II, HIPAA, third-party pen testing | *** ## Why enterprises trust Browserbase ### Enterprise-grade compliance * **SOC 2 Type II Certified** * **HIPAA compliant**: Business Associate Agreements (BAAs) available * Comprehensive third-party **penetration testing** with successful results * Full access to security documentation (e.g., auditor attestations, compliance portal access) provided on request ### Secure by design #### Zero trust browser isolation Browserbase follows a zero-trust architecture, assuming that any browser may be compromised. This design philosophy ensures comprehensive containment and minimizes risk. * **Browser isolation**: Each browser runs in a dedicated VM, providing strong isolation at the hardware virtualization layer. * **Network isolation**: Every browser runs in an isolated subnet with strict firewalls to prevent lateral movement. * **No browser reuse**: After each session, the virtual machine is killed and recreated from scratch, ensuring every browser session is completely fresh. * **No GPU access**: To avoid known security risks associated with shared GPU memory attacks. #### Patch management * Continuous updates with fast turnaround for critical CVEs * Browserbase patches Chrome versions proactively and automatically. * Compatibility testing for enterprise environments ensures stability across browser updates ### Transparent data handling * **Zero data retention**: [Disable logging](/reference/api/create-a-session#body-browser-settings-log-session) and [session recording](/reference/api/create-a-session#body-browser-settings-record-session) via the [Create Session API](/reference/api/create-a-session) to ensure no data is recorded. * **Configurable browser regions**: Choose your closest data center to minimize latency and ensure data sovereignty * US West * US East * EU (Germany) * Asia (Singapore) ### Guardrails for AI web browsing Browserbase offers AI-assisted browsing via Stagehand. It's designed for safe, deterministic agent workflows. #### Stagehand benefits * **Atomic, auditable steps**: Workflows are built as a series of deterministic, cacheable commands * **Self-healing actions**: If a selector changes, Stagehand retries using an LLM fallback only for that atomic step * **No full-page hallucinations**: Minimizes AI unpredictability by limiting LLM scope * **Prompt templating**: Sensitive data can be parameterized and injected at runtime to avoid LLM exposure * **Bring your own model (BYO-LLM)**: Maintain full control with your preferred model, keys, and compliance framework *** ## Summary Browserbase is designed for scalable browser agents, architected with security and trust at its core. With enterprise-grade controls, strict isolation, and transparent compliance, organizations can confidently scale sensitive workloads without compromising security. For regulated industries, sensitive workflows, or AI-powered browser agents under strict oversight, Browserbase is the secure infrastructure you can depend on. **Questions?** Contact the security team or request full compliance documentation through the [Trust Center](https://trust.browserbase.com/). # Zero data retention (ZDR) Source: https://docs.browserbase.com/account/enterprise/zero-data-retention Run Browserbase sessions for regulated workloads without persisting logs, recordings, or replay data. Zero Data Retention (ZDR) lets your account run Browserbase sessions without persisting **session logs**, **session recordings**, or **replay artifacts** to Browserbase's managed storage. Combined with [Bring Your Own Storage (BYOS)](/account/enterprise/byos-setup-guide), ZDR gives Enterprise customers full control over where every artifact produced by a session lives, including the option for no artifact to leave your environment at all. ZDR is available only on Enterprise plans. [Contact the Browserbase team](https://www.browserbase.com/contact) to learn more about Zero Data Retention for your organization. *** ## What ZDR covers When ZDR is enabled, Browserbase **does not persist** the following artifacts: | Artifact | Behavior under ZDR | | ------------------- | --------------------------------------------------------------------------------- | | **Session logs** | CDP and console output are not written to Browserbase storage | | **Video recording** | No `.mp4` is encoded or stored | | **Replay (DOM)** | No RRweb replay is captured; the Replay API returns `404 Not Found` | | **Live View** | Still available in real time. Live View streams the session, it does not store it | The browser session itself runs normally. Your automation, downloads, and uploads work the same way. ZDR only changes whether Browserbase keeps a record of what happened inside the session after it ends. **Downloads, uploads, contexts, and extensions** are separate artifact types. If you need those stored under your control as well, pair ZDR with [BYOS](/account/enterprise/byos-setup-guide) so they're written to your own S3 buckets. *** ## How to enable ZDR You can opt individual sessions out of logging and recording by setting `logSession` and `recordSession` to `false` when you [create a session](/reference/api/create-a-session). This works on every plan and is useful for sensitive workflows where you don't want Browserbase to persist logs or recordings. If you'd also like artifacts (downloads, contexts, uploads, and extensions) stored exclusively in your AWS account, pair ZDR with [BYOS](/account/enterprise/byos-setup-guide). The two features work together. ```typescript theme={null} import Browserbase from "@browserbasehq/sdk"; const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY }); const session = await bb.sessions.create({ projectId: process.env.BROWSERBASE_PROJECT_ID!, browserSettings: { logSession: false, recordSession: false, }, }); ``` ```python theme={null} from browserbase import Browserbase bb = Browserbase(api_key=os.environ["BROWSERBASE_API_KEY"]) session = bb.sessions.create( project_id=os.environ["BROWSERBASE_PROJECT_ID"], browser_settings={ "log_session": False, "record_session": False, }, ) ``` ```bash theme={null} curl -X POST https://api.browserbase.com/v1/sessions \ -H "X-BB-API-Key: $BROWSERBASE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "projectId": "'"$BROWSERBASE_PROJECT_ID"'", "browserSettings": { "logSession": false, "recordSession": false } }' ``` Both flags default to `true`. Setting either to `false` is permanent for that session. You cannot re-enable logging or recording after the session has started. *** ## What changes for your team * **Live View** continues to work for real-time debugging of in-flight sessions. * **Session Replay** and **Recording** endpoints return `404 Not Found` for ZDR sessions because there is no recording to fetch. * **Session Logs API** returns no entries for ZDR sessions. * **Dashboard** still shows session metadata (status, start/end time, region, and duration), but the replay viewer will be empty. * **Support investigations** are limited under ZDR. If you open a support ticket, Browserbase will not have logs or replay to reference. Browserbase recommends keeping logs and recording enabled for non-production projects so issues can be reproduced and triaged. Once a ZDR session ends, the logs and replay data are gone. Browserbase does not retain them, even for support. Make sure your own observability (application logs, Stagehand `history` and `metrics`, and custom telemetry) captures everything you need before disabling these features. *** ## Pairing ZDR with BYOS ZDR removes Browserbase-managed logs and recordings. BYOS routes the remaining session artifacts (downloads, uploads, contexts, and extensions) into S3 buckets you own. Together they give you a configuration where: * No session logs or recordings exist on Browserbase storage. * Browserbase writes all other session artifacts directly to your AWS account, under your KMS keys, with your lifecycle policies. * Browserbase retains only operational metadata (session ID, project, timing, and region) needed to run the platform and bill usage. See the [BYOS setup guide](/account/enterprise/byos-setup-guide) for how to provision the buckets and IAM role. *** ## Compliance and contracts ZDR is part of Browserbase's Enterprise security posture. See [Enterprise security](/account/enterprise/security) for the full picture, including SOC 2 Type II, HIPAA BAA availability, and the [Trust Center](https://trust.browserbase.com/). If your contract or compliance program requires written confirmation that ZDR is enabled for your account, ask your Browserbase contact. Browserbase can provide attestation as part of your enterprise agreement. *** ## FAQ No. Disabling logs and recording slightly reduces CPU and network overhead inside the session VM, but the difference is not user-visible. Yes. Set `logSession: false` / `recordSession: false` per-session for the workloads that need it. You can apply this selectively in your code based on project, environment, or workflow. No. Live View streams the session in real time without storing it, so it remains fully functional. ZDR only suppresses the persisted replay/recording. Yes. Stagehand creates Browserbase sessions under the hood, so the same `logSession` and `recordSession` settings apply via `browserbaseSessionCreateParams`. ZDR controls what Browserbase stores. Those providers govern any data you send to third-party LLMs (OpenAI, Anthropic, etc.). Use [BYO-LLM](/account/enterprise/security#guardrails-for-ai-web-browsing) to route AI calls through your own keys and provider agreements. *** **Questions?** Contact the Browserbase team to learn more about ZDR, or request full compliance documentation through the [Trust Center](https://trust.browserbase.com/). # Teams Source: https://docs.browserbase.com/account/team/roles Manage team members, roles, and project access ## Add teammates Select the Organization you want to add a team member to. Select "Settings" from the menu. Click "Invite members" from the Pending Invitations section. Type in the email address of the team member you want to add and send the invitation. ## User roles There are three roles a user can have within an organization: Admin, Contributor, and Viewer. | | Admin | Contributor | Viewer | | ----------------------------- | ----- | ----------- | ------ | | Invite new users | ✅ | ❌ | ❌ | | Manage users | ✅ | ❌ | ❌ | | Create projects | ✅ | ❌ | ❌ | | View sessions | ✅ | ✅ | ✅ | | Stop sessions | ✅ | ✅ | ❌ | | View plan usage | ✅ | ✅ | ❌ | | Run scripts in the playground | ✅ | ✅ | ❌ | | Change project settings | ✅ | ✅ | ❌ | | View API key | ✅ | ✅ | ❌ | | Regenerate API key | ✅ | ❌ | ❌ | User roles **only** affect what permissions a user has within the dashboard itself. They don't change who can interact with sessions via the API. That's what your API key is used for. You can manage and change what roles members have in your organization from [Settings > Members](https://www.browserbase.com/settings). Navigate to your organization using the switcher in the main menu, then select Members. When inviting new users, you'll also assign a role to them at the same time. ## Project access When you invite a new user to your organization, you can select which projects the user should have access to in addition to their role: Users that have "all projects" selected will be able to access all current projects in addition to any projects created in the future. If you need to restrict a user to only existing projects, select them individually in the drop down. Admins can't have their project access restricted. Users need either the contributor or viewer role to restrict their project access. ## Single sign-on (SSO) For enterprise teams, Browserbase supports SAML 2.0-based Single Sign-On so your team can log in with your corporate identity provider. Learn how to configure SSO for your organization. # SSO (single sign-on) with SAML Source: https://docs.browserbase.com/account/team/sso Learn how to enable SAML 2.0-based Single Sign-On for your Browserbase organization Browserbase supports **SAML 2.0-based Single Sign-On (SSO)** so your team can log in with your corporate identity provider (IdP). SSO is available only on Enterprise plans. [Get in touch](https://www.browserbase.com/contact) with the Browserbase team to enable SSO on your account. ## Supported identity providers Any **SAML 2.0-compliant IdP** is supported, including: * Okta Workforce * Microsoft Entra ID (formerly Azure AD) * Google Workspace (SAML) * Custom SAML providers ## How setup works Setting up SSO requires coordination between your IT team and Browserbase support. Here's the process: **Example:** Acme Corp wants to enable Okta SSO for their Browserbase organization. ### Step 1: Your IT team shares IdP configuration Your IT administrator sends the following details from your identity provider to [support@browserbase.com](mailto:support@browserbase.com): * **Sign-on URL (SSO URL)** - Where Browserbase redirects users for authentication * **Entity ID / Issuer** - Your IdP's unique identifier * **X.509 Signing Certificate** - Used to verify SAML assertions ### Step 2: Browserbase provides service provider details The Browserbase team responds with configuration values your IT team needs: * **Assertion Consumer Service (ACS) URL** - Where your IdP sends authentication responses * **Entity ID (Audience URI)** - Browserbase's unique identifier * **Metadata URL** - Complete SAML configuration (preferred method) ### Step 3: Your IT team configures the SAML application Your administrator creates a new SAML application in your IdP (e.g., Okta, Azure AD) using the Browserbase SP details. ### Step 4: Joint testing Both teams coordinate to test the login flow and verify that user attributes are mapped correctly. ### Step 5: Browserbase enables SSO Once testing is successful, the Browserbase team enables SSO for your organization. ## Required attributes Browserbase requires the following attributes in the SAML assertion: * **Email address** – The user's email * **First name** – The user's given name * **Last name** – The user's surname ### Okta configuration In your Okta SAML application, navigate to **SAML Settings** and configure the **Attribute Statements** section: | Name | Name Format | Value | | ----------- | ----------- | ---------------- | | `mail` | Unspecified | `user.email` | | `firstName` | Unspecified | `user.firstName` | | `lastName` | Unspecified | `user.lastName` | **Name** is the attribute name Browserbase expects. These must match exactly as shown (`mail`, `firstName`, `lastName`). **Value** is the Okta expression that retrieves the data from your directory. The values shown above (`user.email`, `user.firstName`, `user.lastName`) are Okta's default user profile attributes. If your organization uses custom attributes, adjust the Value accordingly (e.g., `user.primaryEmail` or `appuser.email`). ### Other identity providers For other SAML providers (Microsoft Entra ID, Google Workspace, etc.), ensure your attribute statements use the same attribute names: * `mail` for email address * `firstName` for given name * `lastName` for surname The source values will differ based on your IdP's attribute schema. ## Testing **SP-initiated login** (recommended): Start from the Browserbase login page → redirected to your IdP → redirected back after successful authentication. ## Just-in-Time (JIT) provisioning Browserbase supports **JIT provisioning** for all SAML providers. The first time a user authenticates through your IdP, a Browserbase account is automatically created for them, with no manual invitation required. User attributes (name, email) are also kept in sync on every sign-in, so updates in your directory propagate automatically. JIT is enabled by default on all SSO connections. Make sure JIT is also enabled on your IdP side (see your IdP's documentation, e.g. [Okta's JIT guide](https://help.okta.com/en-us/content/topics/security/jit-overview.htm)). ## Next steps 1. Collect your IdP configuration values. 2. Share them with Browserbase at [support@browserbase.com](mailto:support@browserbase.com). 3. The Browserbase team will reply with the SP details. 4. Test and finalize the integration together. Once complete, your users can securely log in to Browserbase with SSO. # Set up 1Password Nightly Autofill for Director Source: https://docs.browserbase.com/integrations/1password/director Enable agentic autofill in 1Password to securely authenticate with Director AI.