A cloud browser is a browser that runs on managed infrastructure and exposes a remote control interface. For an AI agent, the useful unit is an isolated session with its own state, timeout, and evidence.
The browser can outlive one model turn or worker process. Your agent keeps its reasoning loop while the browser provider manages Chromium, network configuration, and session cleanup.
The minimum useful interface
A production cloud browser should provide four capabilities:
- Explicit lifecycle: create a session, connect to it, set a timeout, and release it.
- Framework access: attach Playwright, Puppeteer, Selenium, or a computer-use loop through a supported protocol.
- State boundaries: isolate cookies and storage by session, with an option to persist selected state in a profile.
- Run evidence: expose a live viewer and a replay for completed work.
Remote Chrome without those controls can still run a script. It leaves more lifecycle, storage, and observability work in your application.
How a Steel session fits
import Steel from "steel-sdk";
const client = new Steel({
steelAPIKey: process.env.STEEL_API_KEY,
});
const session = await client.sessions.create({
timeout: 900_000,
});
try {
console.log(session.id);
console.log(session.sessionViewerUrl);
// Connect a browser library or computer-use loop here.
} finally {
await client.sessions.release(session.id);
}Steel's Sessions API creates an isolated browser and returns connection and viewer details. Sessions use a five-minute timeout by default; pass timeout in milliseconds when the workflow needs longer. The maximum available duration depends on the account's limits, so set the shortest useful timeout rather than assuming every run can remain open for a full day.
Release is part of the workflow contract. Calling it explicitly frees capacity and gives downstream processing a clear end to the run.
When persisted state helps
Fresh sessions are appropriate for independent jobs. Use a profile when retries or later jobs need the same cookies, local storage, extensions, credentials, or browser settings.
Steel profiles snapshot the browser user-data directory when a persisted session is released. A later session can load the returned profileId. Profiles have documented size and idle-retention limits, so they should hold browser state rather than general file archives.
Persisting state also changes the security boundary. Treat a reusable profile like an authenticated browser: scope who can reference it, rotate it when access changes, and avoid sharing one profile across unrelated users.
When a local browser is enough
Local Playwright or Chromium remains the simplest option when:
- one machine owns the entire job;
- the workflow is short and stateless;
- you can reproduce failures from local traces;
- network identity and human handoff do not matter.
Move to a managed browser when browser lifecycle becomes shared infrastructure: multiple workers need sessions, operators need a live view, or failures require evidence tied to a job ID.
Self-hosting and managed infrastructure solve different operational problems. Steel Local versus Steel Cloud covers that deployment choice without changing the session model.
Operational limits
A cloud browser does not make selectors stable, authorize access to a target site, or remove the need for application-level safety checks. Your code still owns retries, task policy, idempotency, and any approval required before a consequential action.
Start with the Sessions API overview, create one bounded session, and record its ID alongside the job that requested it.