Bugmole Cloud or your own machines

Bugmole can run your tests in two places. You choose per project, and you can switch any time.

Your resources first, or Bugmole's

On Tests, the line under the run button says whose resources are used first. Choose Change to pick:

• My resources: your machine running bugmole serve (or CI) and your own model key. When no machine of yours is connected, a run or exploration goes to Bugmole Cloud instead, and AI work uses your plan's credits when your key fails.
• Bugmole's: Bugmole Cloud, your plan's cloud minutes and AI credits. When the cloud can't take the work (minutes or a monthly limit used up, a domain not verified, results kept on your own storage), it waits for your machine instead, and AI work uses your own model key when credits run out.

When work goes to the other one, the dashboard says why. If Bugmole Cloud isn't available for the project, Why not the cloud? explains what to change.

The choice applies to Explore this URL as well, and it's remembered for the project. Re-runs, including Apply fix and Ask AI to fix, go wherever the original run went.

Cloud runs need Bugmole storage

A cloud runner starts from a clean machine, so it reads your plans from Bugmole storage and saves screenshots, videos and logs there. Projects created when you sign up use Bugmole storage from the start.

If a project keeps its files in your own bucket (Amazon S3, Cloudflare R2 or Google Cloud Storage), Bugmole Cloud is unavailable for it. To change that, open Settings → Projects (in your account menu) and set the project's storage to Bugmole storage.

To use Bugmole storage from the CLI, run bugmole init --storage-provider bugmole, or set this in .bugmole/config.yaml:

storage:
  provider: bugmole

It needs no bucket of yours: files go through your Bugmole account, and the CLI signs in with the project's API key (BUGMOLE_API_KEY).

How cloud minutes are counted

• A run's minutes are counted from when a cloud machine picks it up until it finishes.
• Minutes are rounded up, with one minute as the smallest charge.
• A run that never started (for example because no machine was available) isn't counted.
• One run on four browsers uses one machine, so its minutes are the time the whole run took.
• Each cloud run can take up to 60 minutes.

On Free, cloud runs stop when the month's 300 minutes are used up. They start again the next month; runs on your own machines keep working in the meantime.

On paid plans, runs continue past the included minutes at the plan's per-minute rate, up to your monthly spending limit. See Plans and limits.

You'll get an email when a workspace reaches 80% and 100% of its included minutes.

When your app isn't public

Cloud runners reach your app over the internet. For an app on localhost or behind a VPN, run on your own machines instead. A preview deployment or a staging site with a public address also works.

Sign-in for runs

A cloud runner starts empty: it has none of your environment variables, so on its own it stops at your sign-in page. Give the project a sign-in flow and the secrets it types under Settings → Sign-in for runs, and Bugmole signs in before it explores and before every run, so flows found behind sign-in run signed in on each browser. Flows can type the same secrets with {{secret.NAME}}.

This works the same on your own machine: bugmole serve gets the flow and the values for a run or exploration it has claimed, signs in, and keeps the values on that run only. A value you set on the machine itself (a BUGMOLE_FLOW_SECRET_NAME variable, or the config's secrets: map) still wins there. Each time values are given to a worker it's recorded in the audit log.

The sign-in flow is an ordinary flow that references secrets by name and never holds a value:

url: https://staging.your-app.com/login
name: "Sign in"
---
- launchApp
- tapOn: "Email"
- inputText: "{{secret.APP_EMAIL}}"
- tapOn: "Password"
- inputText: "{{secret.APP_PASSWORD}}"
- tapOn: "Sign in"
- assertVisible: "Dashboard"

End it on something only a signed-in person sees. If the flow uses a secret the project doesn't have, the exploration stops with a message naming it.

Where the secrets live

• In Bugmole's database, encrypted with AES-256-GCM. Each project has its own key, held only by Bugmole's servers, and each value is bound to its project, environment and name, so it can't be copied anywhere else.
• A secret can be project-wide or belong to one environment. A run in that environment uses the environment's own value in place of the project-wide one; explorations use project-wide values.
• Secret names are capital letters, digits and _ (APP_PASSWORD), up to 64 characters. Values can be up to 4,096 characters.

Who can read them

• Nobody through the dashboard or the API. Secrets are write-only: the list shows each name, its environment, who last changed it and when, and when a run last used it, never the value. Replace a value by setting it again.
• Project owners and admins set, replace and delete secrets in the dashboard. Members see the names. API keys can't write or read them.
• A Bugmole Cloud runner, and only for the one run or exploration it is running for that project, with the short-lived token it was started with. Once the job ends, the token reads nothing more.
• Your own workers don't receive them. bugmole serve and CI jobs keep reading BUGMOLE_FLOW_SECRET_NAME from their own environment.

Every change and every release to a runner is in the audit log, with the secret's name and never its value.

What the runner does with them

The runner puts them in its own environment as BUGMOLE_FLOW_SECRET_NAME for as long as the job runs, and replaces every value with [secret] in logs, step results, manifests and the progress it reports. Flows that type a secret record no Playwright trace, since a trace keeps what was typed. The sign-in itself leaves no evidence behind: its browser session is deleted with the container when the job ends. Screenshots and video still show what was on screen, and password fields show dots.