All articles

Running automations

Cloud runs vs local runs (desktop app)

Where Tyrbo automations execute, when to route browser steps to your own computer, and how device linking works.

Every Tyrbo automation is orchestrated in the cloud — triggers, schedules, integration steps, and run history always live there. What you choose is where the browser steps execute: on Tyrbo's cloud browser fleet, or on your own computer through the Tyrbo desktop app.

Cloud runs

By default, browser steps run on Tyrbo's managed browser workers. This is the right choice for most automations:

  • Runs happen around the clock — your computer can be off.
  • Logged-in sites work via saved sessions: an encrypted session exported from the recorder keeps cloud replays signed in.
  • Nothing to install or maintain.

When to run locally

Route browser steps to your own machine when the site demands it:

  • Sites that block datacenter traffic. Some sites reject requests from cloud IP ranges. A local run comes from your home or office connection, like any normal browsing.
  • Logins that must stay on your device. The desktop app uses a real, persistent browser profile on your machine. Sign in once — including MFA — and replays reuse that profile. Your credentials and session never leave your computer.

Even for local runs, the cloud still orchestrates: integration steps and their secrets stay in the cloud, and only the browser portion of the run is handed to your device. Results stream back into the same run history.

  1. Download and install the Tyrbo desktop app (macOS and Windows).
  2. Open it and sign in via the device-link flow: the app shows a short code, and you approve it at app.tyrbo.ai/link.
  3. Give the device a name — it registers with your organization as a named worker you can route steps to.

The link is stored securely in your operating system's keychain, so the app stays signed in across restarts. You can link multiple devices and see all of them in the web app.

Route steps to a device

In the automation editor, set the browser steps you need to run locally to local execution and pick the device. At run time, the cloud queues that portion of the run for the device; the desktop app holds a live connection, executes the browser steps, and streams step results and artifacts back.

The replay engine on the desktop is byte-identical to the cloud one — same selector handling, same self-healing, same artifacts — so a flow behaves the same wherever it runs.

What runs cost

Runs whose browser work executes entirely on your own device cost a flat 5 credits — your machine does the browsing, the cloud only orchestrates. Cloud runs cost a flat 10 credits with the first 5 minutes of cloud browser time included; longer sessions meter at 1 credit per additional started minute, up to a 30-minute cap. Only time a cloud browser spends actually working counts — waiting for your device to come online is never billed. The editor shows a cloud/local chip on every browser node and the run estimate says where a run will execute, so there's never a surprise. See Billing, credits, and overage.

If your device is offline

Local steps are queued per device. If the device is offline when a run reaches its local portion, the run waits for the device to reconnect rather than silently skipping steps. Keep the desktop app running (it's fine in the background) on any machine that automations depend on.

Recording locally

The desktop app can also record flows using its own bundled browser — useful when you want to record against the same persistent profile the replays will use. Recordings from the desktop app import into drafts exactly like extension recordings: see Import recordings into editable drafts.