Runs onWrit CloudDesktopSelf-hosted
On this page
Where it runs
Every Writ run opens a real browser somewhere. That somewhere is called an agent, and you choose it per workflow. Nothing else about the workflow changes.
agent ▸ the machine
The agent is the machine that opens the browser
A workflow is a portable list of steps. An agent is a process that can execute those steps in a real browser and report the result back. The same workflow, unchanged, can run on your laptop this morning and on the cloud fleet tonight. Where it runs decides three things and only three: what it costs, whether it can run while your machine is asleep, and which networks it can reach.
Credentials never travel with the workflow. A persona is decrypted only on the agent that is executing the run, and only for the duration of that run.
venues ▸ three
The three places a run can happen
Desktop
Your own machine
The Desktop app is itself an agent. Runs are free, unlimited and unmetered: billing checks simply do not apply to local runs, and parallelism is bounded by your machine, not your plan. It reaches whatever your machine reaches, including intranet-only systems and services behind your VPN, and it uses your own residential connection. The trade is availability: the run needs the app open and the machine awake.
TOTP second factors are minted on-device, on every plan. Email and SMS code reads need the cloud — a local run that reaches one finalizes as twofa_required. Local runs are never counted against cloud time.
Writ Cloud
The managed fleet
Cloud runs happen on the Writ fleet. They are always available, they scale past what one machine can do, and they are metered by running time from your plan’s included usage first — the wallet is touched only once the pool is spent. Cloud is also where the published surfaces live: a workflow only answers a public REST call, a custom domain, a consumer key or the hosted MCP server if it can run without you.
On a busy fleet, a queued run shows its place in line and an ETA. Cloud runs also carry per-plan duration ceilings — the table further down.
Self-hosted
A fleet you run
You can run the open-core coordinator yourself, in Docker, on your own hardware or your own cloud account. Traffic, browser profiles and extracted data stay inside your perimeter, which is usually what a compliance team is asking for. You take on the operating work in exchange: capacity, upgrades and uptime are yours.
AI selector-repair is a cloud-managed, metered capability: it is absent from the OSS build, and it never uses BYO keys.
AI keys on your machine
On local and self-hosted deployments, AI assist runs against the provider configured on your own machine, and those keys never leave it. Cloud-orchestrated AI runs on the managed gateway and is billed per token. One constant either way: AI selector-repair stays managed.
On cloud runs, automatic 2FA minting and CAPTCHA-solver routing are premium capabilities (Pro and up); below that, the run answers 402 premium_feature_required.
compare ▸ what differs
What actually differs
The workflow, the steps, the personas and the extracted output are identical everywhere.
| Aspect | Desktop | Writ Cloud | Self-hosted |
|---|---|---|---|
| Compute cost | Free and unmetered | Metered from the monthly pool, then the wallet | Your own infrastructure cost |
| Runs while you are away | Only while the app is open | Always | While your fleet is up |
| Network reach | Everything your machine reaches, intranet included | The public internet | Everything your fleet reaches |
| Egress address | Your own connection | Platform egress, residential where a site requires it | Your own connection |
| Published REST endpoints and MCP | Local MCP only | Yes, with custom domains and consumer keys | Yes, on your own hostname |
| AI tokens | Your own keys: nothing billed. The managed gateway: per token. | Billed per token, or BYO keys via your own agent | Your own provider account |
| AI selector-repair | Available — cloud-managed, metered, never your BYO keys | Available — managed and metered | Absent from the OSS build |
caps ▸ cloud only
Per-plan cloud ceilings
Cloud runs and live streaming sessions carry per-plan duration ceilings. Local runs have none — these are cloud limits.
| Plan | Max cloud run | Max streaming session |
|---|---|---|
| Free | 2 min | 5 min |
| Starter | 4 min | 10 min |
| Pro | 5 min | 15 min |
| Growth | 10 min | 30 min |
| Scale | 15 min | 60 min |
| Enterprise | 15 min | 60 min |
choose ▸ a default
Choosing
A reasonable default is: build on Desktop, publish to Cloud.
- Building and debugging a workflow: Desktop. It is free, so iterate as much as you like.
- Anything on a schedule, a monitor that has to catch a change at 3am, or an endpoint other software calls: Cloud.
- A target that only exists on your internal network: Desktop or self-hosted. The cloud fleet cannot reach it.
- Data that must not leave your perimeter: self-hosted.
move ▸ change the agent
Moving a workflow between them
Change the agent on the workflow and run it again. Nothing in the step list changes. Personas and vault secrets are re-decrypted on the new agent, so a workflow that signs in keeps working; a workflow that relied on an intranet host will fail on the cloud fleet, which is the one case where the move is not transparent.
next ▸ related
Related pages
Where to go from here.
Personas, secrets and agents
Encrypted logins, TOTP, the vault, and which machine actually runs the browser.
Billing and usage
How cloud running time and AI tokens are metered, and how to keep spend predictable.
Managed endpoints
Publish a workflow as a versioned REST endpoint with quotas and usage records.
Record a workflow
Record a browser session once, then replay it with typed inputs and extracted output.