Skip to main content
Every Komos run happens in a managed browser session. Choose the environment that fits the job so your automations stay reliable and compliant.
The legacy Chrome extension path is fully retired—runs only execute in the Cloud Sandbox or a managed self-hosted runner (Windows or macOS host).

​
Komos Cloud Sandbox

  • Cloud-hosted Chromium that spins up instantly, even when your team is offline.
  • Fresh session for every run - no risk of leftover cookies or cached data leaking between automations.
  • Perfect for schedules, API-triggered runs, and long flows that need guaranteed uptime.

​
Persistent Cloud Sandbox

  • Long-lived cloud-hosted Chromium that keeps state between runs: cookies, downloaded files, browser profile, in-progress work all survive.
  • Ideal for tasks that need a persistent login (SaaS dashboards, internal portals you’ve authenticated to once) or where re-staging state on every run would be wasteful.
  • Same Daytona compute as the Cloud Sandbox; the difference is one box per persistent environment vs. fresh boxes per run.

​
When to choose persistent over a fresh sandbox

  • You log into a vendor portal once and want subsequent runs to resume that session.
  • The task downloads files (CSV, PDF, training data) you want to keep across runs.
  • You install browser extensions or tweak settings that should persist.
  • You want predictable resume latency (warm box = fast) for scheduled or recurring work.

​
Concurrency

  • Each persistent environment runs one task at a time. If a second run starts while the first is still in progress, it queues and starts automatically once the first finishes — same as a self-hosted runner.
  • You can bind multiple tasks to the same persistent environment (e.g. several Salesforce-related tasks share one logged-in box).

​
Lifecycle

  • Create a persistent environment from the Environments page; give it a friendly name like “Lead enrichment” or “Invoice processing.”
  • Bind it to a task on the Run Settings tab as the Default runner.
  • Rebuild wipes the saved state and creates a fresh box on the next run, while keeping the same environment identity and task bindings — useful if you want to pick up a newer Chromium build.
  • Remove permanently deletes the environment and unbinds it from every task.

​
Status meanings

  • Idle - Online: warm and ready, next run starts fast.
  • Idle - Offline: cold/stopped, next run waits for the box to start (a few seconds longer).
  • Running: a run is currently using it.
  • Broken: an error happened — try Rebuild.
  • Destroyed: removed.

​
Limitations to know about

  • Chromium version is whatever was in the Daytona snapshot when the box was created. To upgrade, click Rebuild (state is lost) or Remove and create a new environment.
  • One environment per task at a time — for parallel runs, create separate environments.
  • State on disk only: things you’d expect to find in ~/.config/chromium, the user data dir, Downloads/. In-memory state (a half-loaded page) doesn’t survive between runs.
  • First run cold-start: creating the underlying box takes ~30-90 seconds. Subsequent runs resume in seconds.

​
Self-hosted Runner (Windows or macOS)

  • Installs a lightweight Komos agent on any desktop you control (physical or virtual).
  • Reuses domain-joined sessions, hardware tokens, Okta/SAML credentials, and any thick-client apps already present.
  • Ideal for flows that require intranet access, customer-specific VPNs, or desktop-only software.
  • Keep the host online and allow the Komos service to run in the background so tasks can claim it when needed.
  • Windows tips: run the provided PowerShell script (.\\start.ps1) from an elevated session, keep the VM unlocked, and let the Komos agent stay active so recordings and runs can resume instantly.
  • macOS tips: run ./start.sh on macOS 13+ (Apple Silicon or Intel), grant screen-recording + automation permissions, and keep the Terminal session or LaunchAgent online so the CLI can reconnect automatically.
  • Download the runner: use the public bundles shown in the “Add Self-hosted Runner” modal:
    • Windows: windows-runner.zip (then run .\\start.ps1)
    • macOS: mac-runner.zip (then run ./start.sh)

​
SSO and internal sites

If your automation needs to reach an internal site behind SSO (Okta, OneLogin, or similar), run it on a Windows VM that already has the necessary browser profiles and IdP sessions. We support both Komos-provided and customer-hosted Windows runners. Configure a service account on that VM, keep the runner online, and tasks will reuse the authenticated session to load intranet pages. For enterprise setup help, contact [email protected].

​
Which environment should I use?

  • Choose Cloud Sandbox for unattended work that doesn’t need to remember anything between runs: simple scrapes, schedule-driven reports, ephemeral browsing.
  • Choose Persistent Cloud Sandbox when the task needs a saved login, downloaded files, or any browser state to carry over between runs — and the destination doesn’t require your corporate network.
  • Pick the Self-hosted Runner when the automation depends on your corporate network, native software, security hardware, or any credential that only lives on your desktops.
  • Set a default on the task detail page and override it per run whenever you need to switch.

​
Setup checklist

  • Cloud Sandbox is ready to go out of the box—no installation required.
  • Persistent Cloud Sandbox: create one from the Environments page, give it a name, then bind it to a task as the Default runner. The first run materializes the underlying box (~30-90 s); later runs resume in seconds.
  • Self-hosted runners (Windows and macOS) need the Komos desktop runner installed, outbound access to the Komos gateway, and a signed-in session that stays unlocked for the duration of the run.
  • After picking an environment, run a quick dry run to confirm waits, prompts, and credentials behave the way you expect.