↓ Skip to main content
BrowserBee
  1. Documentation/
  2. Core concepts/

Browser profiles

Browser profiles are the primary BrowserBee resource and define the browser runtime your teams can target.

What a browser profile represents
#

A BrowserBee profile is a named, versioned browser runtime definition. It combines the browser identity with the operational defaults your teams expect when they automate against it.

Profiles include:

  • a stable profile_key
  • a customer-facing name
  • the browser channel
  • the target version
  • a lifecycle status
  • supported capabilities
  • supported platforms
  • optional runtime configuration

Lifecycle statuses
#

BrowserBee uses three statuses today:

StatusMeaningRecommended customer action
availableReady for normal useSafe default for active automation
previewAvailable for evaluationUse with limited rollout and explicit ownership
deprecatedScheduled for retirementPlan migration away from the profile

Why profile_key matters
#

profile_key is the canonical identifier used in BrowserBee API routes. Pick a format that stays readable when your catalog grows, for example:

  • chrome-stable-linux
  • firefox-beta-macos
  • edge-stable-windows

Changing keys later is far more disruptive than changing display names, so choose a format your team can keep for the long term.

Configuration defaults
#

Profile configuration supports operational runtime defaults such as:

  • timeout_seconds
  • retry_attempts
  • headless
  • viewport.width
  • viewport.height

Treat these as shared defaults for predictable execution, not as a substitute for test-level intent.

Operational guidance
#

For most customers, the best default profile strategy is:

  1. one stable profile per browser and platform combination you actively support
  2. preview profiles only for controlled trials
  3. deprecation as an explicit lifecycle step before removal

That approach keeps your inventory understandable for both release engineers and test authors.