Skip to main content
By default, Figranium maintains persistent browser profiles on disk across task runs. Stateless Execution allows you to bypass this for tasks that require a clean, isolated browser environment.

​
What is Stateless Execution?

When enabled, Figranium launches the browser context without loading any existing cookies, local storage, IndexedDB, or session data. Once the task completes, all session data generated during the run is discarded and not saved back to the global storage state. Think of it as opening a private/incognito window for each task run.

​
Stateful vs Stateless

Stateful (default)

Without stateless mode, Figranium:
  1. Launches the browser using a persistent profile directory on disk (data/browser-profile for agent mode, data/browser-profile-scrape for scrape mode).
  2. Runs the task with the full browser context available (logged-in sessions, preferences, etc.).
  3. The browser profile is updated automatically — cookies and storage persist to disk as the session progresses.
  4. The next task run starts with those saved cookies already loaded from the profile directory.
This is ideal for tasks that require a persistent login — you log in once, and subsequent runs reuse the session without re-authenticating.

Stateless

With stateless mode enabled:
  1. The browser starts as a true incognito session — launched in-memory with no disk profile directory at all (no cookies, no local storage, no session).
  2. After execution, all generated cookies and storage are thrown away — nothing is written to disk.
  3. No persistent browser profile is ever read from or written to.
Each run is completely independent and isolated from every other run.

​
Use Cases

Common use cases explained:
  • Testing Logins: Confirm your login flow works for a brand-new user, with no saved cookies interfering.
  • Multi-Account Management: Run tasks for different accounts without manually clearing cookies between runs.
  • Scraping Public Data: Avoid being served personalized content based on previous browsing history stored in cookies.
  • Privacy: Prevent cross-task data leakage when automating sensitive workflows for different users or organizations.

​
How to Enable in the Editor

1

Open task settings

Open your task in the Task Editor and click the Settings panel (gear icon, top-right of the editor).
2

Toggle stateless execution

Under the General tab, toggle on Stateless execution.
3

Save the task

Save the task to apply the change.

​
How to Enable via API

Pass statelessExecution: true in the request body when triggering a run:
You can also bake statelessExecution: true into the saved task definition itself, so every run — whether triggered from the UI, API, or scheduler — always runs stateless.

​
Combining with Proxy Rotation

Stateless execution pairs naturally with proxy rotation. Each run:
  • Starts fresh with no cookies (looks like a brand-new visitor)
  • Routes through a different proxy IP (looks like a different device/location)
This combination is effective for tasks that need to avoid rate limiting or per-account blocking. To enable both:
1

Enable stateless execution

Toggle Stateless execution on in task settings.
2

Configure proxy rotation

Configure Proxy Rotation in Settings > Proxies and enable it for the task.

​
Isolating Multiple Identities Instead

If your goal is not a clean browser but rather separate cookies per account or tenant, stateless execution is the wrong tool — every run would have to log in from scratch. Use a named session snapshot instead: pass sessionId with the run to persist cookies into data/sessions/<sessionId>.json and restore them on the next run with the same name. See Named Session Snapshots for details.

​
Performance Consideration

Stateless tasks take slightly longer per run when they require authentication, because they must log in from scratch every time. For tasks that run frequently and need a logged-in state, use stateful mode (default) and implement a separate “Refresh Login” task on a schedule to keep cookies fresh. Use stateless mode only when each run truly requires an isolated environment.