Prepare multiple environments
Most BrowserBee integration problems in production come from environment mix-ups: the wrong token, the wrong base URL, or unclear ownership. This guide gives you a clean default setup.
The minimum environment model
At minimum, keep these separate:
- development for local work and exploratory integration
- production for live automation and user-impacting workloads
If your team has staging or preview systems, treat them as first-class environments as well.
Recommended configuration shape
Use the same variable names everywhere:
BROWSERBEE_BASE_URL=
BROWSERBEE_API_TOKEN=
Only the values should change per environment.
Recommended file and secret layout
| Environment | Where to store config |
|---|---|
| Local development | local .env file ignored by Git |
| CI / preview | repository or environment secrets |
| Staging / production | environment-scoped secrets or cloud secret manager |
Promotion strategy
The safest promotion path is:
- prove the request flow in development
- promote the exact request pattern to staging if present
- switch only the base URL and token for production
- verify again with low-risk calls before enabling automation
This makes debugging easier because only the environment-specific configuration changes between stages.
Guardrails worth adding
- explicit environment names in logs
- one token per environment
- deployment-time validation that required BrowserBee variables are present
- smoke tests that call a low-risk read endpoint
Next steps
- Review Manage API tokens.
- Review Connecting to the API.