Browser self-targets

A browser self-target runs the flow directly on the browser task image. There is no separate application container. Path-only flow URLs resolve against http://127.0.0.1:3000 by default, or against the base_url supplied with the target.

Select it when creating a run:

{
  "target": { "kind": "browser" },
  "idempotency_key": "browser-image-smoke-1",
  "flows": [{ "slug": "browser-image-smoke", "tag": "main" }]
}

Send that body to POST /v1/runs. See the API reference for authentication and polling.

Start, check, and drive the application

exec "…" in browser and bash "…" in browser run setup commands in the same task that owns the browser. A flow can seed data, start a server, verify its health, and then drive its UI:

---
name: Browser-image smoke
url: /
---

### Start the application

```rfl
exec "node ./scripts/seed.mjs" in browser timeout=30s
bash "npm run start > /tmp/app.log 2>&1 &" in browser timeout=30s
bash "curl --fail http://127.0.0.1:3000/health" in browser timeout=10s
```

### Verify the interface

```rfl
open /
expect role=heading name="Dashboard"
```

bash is an alias for exec. Both use /bin/sh -c, run as the unprivileged pwuser, and start in /app. in browser is the only image reference a browser self-target accepts.

Command boundary

• Commands are limited to 32 KB.
• Output is limited to 64 KB; when it overflows, the tail is kept.
• A timeout terminates the command’s process group.
• The child process receives a safe base environment plus the team’s declared ${VAR} values, not the runner’s control-plane environment.

The shell shares the browser task’s filesystem, network, task role, user, and process namespace. Use it only for trusted code. Arbitrary customer images run through the separate custom image harness, which has its own container boundary.