> ## Documentation Index
> Fetch the complete documentation index at: https://figranium.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Stateless Execution

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.

## **Default Behavior (Stateful)**

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 Behavior**

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**

| Scenario                                     | Recommended Mode   |
| :------------------------------------------- | :----------------- |
| Persistent login session reuse               | Stateful (default) |
| Testing a login flow from scratch            | **Stateless**      |
| Multi-account automation                     | **Stateless**      |
| Scraping public data without personalization | **Stateless**      |
| Privacy-sensitive workflows                  | **Stateless**      |
| Refreshing auth tokens periodically          | Stateful (default) |

**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 your task in the **Task Editor**.
2. Click the **Settings** panel (gear icon, top-right of the editor).
3. Under the **General** tab, toggle on **Stateless execution**.
4. Save the task.

## **How to Enable via API**

Pass `statelessExecution: true` in the request body when triggering a run:

```json theme={null}
POST /api/tasks/:id/api
Content-Type: application/json

{
  "variables": {
    "username": "user@example.com"
  },
  "statelessExecution": true
}
```

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. Toggle **Stateless execution** on in task settings.
2. Configure **Proxy Rotation** in `Settings > Proxies` and enable it for the task.

## **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.