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

# Examples

> Copy-paste patterns for real AI-agent workflows: code interpreters, data analysis, ephemeral databases, browser automation, dev-env previews.

<Note>
  Every snippet on these pages is drop-in runnable. Set `PODFLARE_API_KEY`
  once (create one on the [dashboard](https://dashboard.podflare.ai/keys))
  and each page has working code you can paste straight into your editor.
</Note>

## What people actually build

Podflare sandboxes are hardware-isolated microVMs. That means each one is a
full Linux box — you can install packages, spin up servers, mount
filesystems, run ML inference, crawl websites, provision databases.
In practice, five workflows come up over and over:

<CardGroup cols={2}>
  <Card title="Code-interpreter agents" icon="robot" href="/examples/code-interpreter">
    Claude's `code_execution` tool, OpenAI Agents SDK's function tools,
    Vercel AI SDK's `tool()`. One helper per framework, the same
    isolated microVM underneath.
  </Card>

  <Card title="Data & analytics" icon="chart-line" href="/examples/data-analysis">
    pandas / matplotlib chart-in-reply, DuckDB against remote CSVs and
    parquet. No DB server, no infra per tenant.
  </Card>

  <Card title="Database work" icon="database" href="/examples/database">
    Ephemeral Postgres per sandbox for testing generated SQL, RLS
    policies, migrations. Local Supabase (Postgres + PostgREST +
    Auth) for full-stack app testing.
  </Card>

  <Card title="Web automation" icon="window" href="/examples/web-automation">
    Headless Chromium via Playwright — scrape, screenshot, fill
    forms. Boot a Next.js dev server and screenshot agent-generated
    UIs.
  </Card>

  <Card title="Dev environments" icon="code-branch" href="/examples/dev-environments">
    Clone a branch, run tests, return results. Perfect drop-in for
    PR-review bots and "run my test suite" agents.
  </Card>
</CardGroup>

## Why a sandbox instead of running agent code locally

Four reasons that show up the moment you have real users:

1. **Isolation.** The agent is going to execute code that came from an
   LLM. You don't trust the LLM with your production environment,
   your files, your credentials, or your network.
2. **Per-session state.** Each user conversation gets its own
   filesystem, installed packages, and process tree. No "did user A's
   `pip install` break user B's session?" debugging.
3. **Horizontal reset.** When a session ends, the sandbox is gone —
   all state, all side effects. No cleanup scripts, no orphaned
   processes, no accumulated cruft.
4. **Speed.** Warm-pool sandbox restore is \~12 ms on bare metal.
   The sandbox exists before your agent asks for one.

## Pattern library

These are the small, composable patterns you'll see in the examples.
Most real agents are combinations of two or three of these:

* **One-shot exec** — run a single snippet, return stdout/stderr/exit\_code.
* **Persistent REPL** — keep the sandbox alive across agent turns; DataFrames
  and files survive.
* **Fork-and-explore** — `Sandbox.fork()` spawns N copies of a running
  state so the agent can try N paths in parallel, then commit the
  winner back to the parent.
* **Upload / download** — push input files in, pull output files out.
* **Background services** — boot Postgres / Next.js / an HTTP API
  inside the sandbox; tear down with the sandbox.

## Shared prerequisites

Every example on this site assumes:

```bash theme={null}
# Python
pip install podflare

# TypeScript
npm install podflare
```

```bash theme={null}
# The SDK reads PODFLARE_API_KEY automatically.
export PODFLARE_API_KEY=pf_live_...
```

Mint a key on [dashboard.podflare.ai/keys](https://dashboard.podflare.ai/keys).
Free tier gets a \$200 credit — more than enough to run every example
on this page end-to-end.