Ephemeral vs. Session mode
By default, eachfetch() call runs in ephemeral mode. Cookies and connection state are isolated per call. This is a good fit for one-off requests.
For multi-step flows (like login sequences), use sessions to persist state.
| Scenario | Recommended | Why |
|---|---|---|
| One-off request, no cookie carryover | Ephemeral (default) | Fresh TLS/cookie jar per call |
| Multi-step login or reuse cookies | Session | Shared cookie jar and TLS cache |
| Parallel jobs that must stay isolated | Ephemeral or per-job session | Avoid cross-talk between tasks |
Creating a session
Auto-disposing sessions
UsewithSession() to automatically close the session when done:
Session options
Sessions accept the same options asfetch() for default behavior:
Per-request overrides
Within a session,browser, os, and proxy are fixed at creation time.
You can still override per-request values like timeout, headers, redirect, and body:
Session isolation
Each session maintains its own:- Cookie jar: cookies are not shared between sessions
- TLS cache: connection state is isolated
- Connection pool: HTTP/2 multiplexing within the session
Best practices
Always close sessions
Call
session.close() or use withSession() to prevent resource leaks.One session per flow
Use a dedicated session for each logical user flow or task.
Parallel isolation
For parallel scraping, create separate sessions to avoid cookie cross-contamination.
Reuse for performance
Sessions reuse connections, making subsequent requests faster.