What is browser orchestration?
Browser orchestration is the layer that coordinates multiple browser sessions and steps in a single workflow: scheduling, fan-out, retry policies, parallelism, state, and observability across the whole orchestration. Sits above the browser primitive the way Kubernetes sits above containers — necessary the moment a workflow is more than 'one browser, one task.'
What is browser orchestration?
Single-session browser work fits inside one Function call: spin up a browser, do the work, return the result. The work that doesn't fit — fan out across 500 sources, chain a browser action with a database write with another browser action, hold state across human approvals — needs a coordination layer above the individual session. Browser orchestration is that layer. The browsers are the workers; the orchestration is what schedules them, fans them out, collects their output, retries the failures, and tracks the state of the whole thing.
Why orchestration becomes necessary
Single-session browser code stays simple: one workflow, one browser, one return value. Three pressures push teams from there into orchestration territory:
- Fan-out. "Run this workflow against 500 different account IDs." A single browser doing them sequentially takes hours; orchestrating them in parallel takes minutes. The orchestrator owns the parallelism and the result aggregation.
- Multi-step pipelines. A workflow where step 1 is a browser action, step 2 is an API call, step 3 is a database write, step 4 is another browser action. Each step has its own failure mode; the orchestrator decides how each interacts.
- Long-running state. A workflow that takes hours, waits on a human, or holds state across restarts. The orchestrator owns the workflow's identity even as the underlying workers come and go.
If your workflow only ever has one of these properties, you don't need an orchestrator yet. Two or three of them, and the orchestrator is the cleanest way to model the work.
What an orchestrator owns
Five responsibilities the orchestrator handles so the workflow code doesn't have to:
- Workflow definition. A representation of the steps and their dependencies — a DAG, a state machine, or a sequence of
await step(...)calls in a durable function. - Step scheduling. Decides which step runs next based on which have completed and which are ready.
- Parallelism and fan-out. When 500 accounts need the same workflow, the orchestrator spawns 500 parallel sub-runs and collects their results.
- Retry and failure policy. Per-step retry budgets, exponential backoff, alerting on persistent failure, fallback paths.
- State and observability. Per-workflow state, per-step logs, replayable history. The audit trail of what ran, when, and what happened.
The browser primitive — Notte's Function, Session, or Agent — handles "run one browser thing." The orchestrator handles everything else.
Where browser orchestration sits in the stack
Three layers, increasing scope:
| Owns | Examples | |
|---|---|---|
| Browser primitive | One session, one run | client.Session(), client.Agent(session=...) |
| Function / API surface | Single deployable workflow | client.Function(...) |
| Orchestration | Many functions, fan-out, multi-step pipelines, state | Temporal, Inngest, Trigger.dev, Vercel Workflow, n8n, Airflow |
Notte ships the bottom two layers; orchestration is typically a layer above, integrated through the Notte SDK as steps. A Temporal workflow that calls client.Function.run(...) for each step is the canonical pattern.
Common orchestration patterns
Three shapes most teams converge on:
- Fan-out / fan-in. Trigger workflow → spawn N parallel browser runs → wait for all → aggregate. Best for "do this for many sources."
- Sequential pipeline. Step 1 (browser) → Step 2 (API) → Step 3 (database) → Step 4 (browser). Each step is its own runtime; the orchestrator passes state forward.
- Saga with compensations. Long-running multi-step workflow where each step has a "what to do if a later step fails" compensating action. Most common in payment-and-fulfillment workflows that go through a browser.
Durable execution is the underlying runtime property that makes patterns 2 and 3 reliable; orchestration is the user-facing layer that exposes those patterns cleanly.
When you don't need orchestration
The discipline is not reaching for it too early. A workflow that:
- runs in a single browser session, and
- doesn't fan out, and
- doesn't span multiple services, and
- completes in under a few minutes
…is fine as a Function with a scheduled cron. Adding Temporal or Inngest is unnecessary complexity until at least one of the three pressures (fan-out, multi-step, long-running) actually applies.
Common pitfalls
- Reaching for orchestration before you need it. A simple Function plus cron handles most "scheduled scrape" work. Don't introduce a workflow engine until the workflow shape demands it.
- Hand-rolling the orchestrator instead of using one. "I'll just write some Python with
asyncioand a queue" works for the first month and rots after. The mature engines (Temporal, Inngest) handle the dozen edge cases you haven't thought of. - Skipping the durability story. An orchestrator without durable execution underneath loses workflow state on restart. Half a system.
- Browser sessions as orchestrator state. A long-running session held open for hours is fragile. Persist what needs to survive (cookies, profile state) and let sessions be ephemeral; let the orchestrator hold the workflow state, not the browser state.
Key takeaways
- Browser orchestration coordinates multiple browser sessions and steps across a single workflow — fan-out, retry, parallelism, state, observability.
- The layer above the individual browser primitive; necessary once a workflow has fan-out, multi-step, or long-running properties.
- Notte ships the browser primitives + the Function deployment shape; orchestration is typically a layer above, integrated via Temporal / Inngest / Vercel Workflow / Trigger.dev.
- Don't over-engineer: stay on a Function-plus-cron until at least one of the three pressures actually applies.