Maestro Deck’s local desktop runner is free and needs no cloud account; its paid cloud execution is optional. Keep that distinction separate from Maestro Cloud: a free local runner does not establish another service’s billing terms, and Maestro Cloud is not a required add-on for local use. Start locally, then evaluate hosted execution when your release workflow needs it.
- Maestro Deck is best for developers who want a free local runner for Maestro YAML end-to-end tests.
- Is Maestro Cloud free or paid? Identify the service first; free local testing does not establish hosted-service terms.
- Keep local debugging separate from the decision to pay for cloud execution or connect CI.
- Check the execution environment explicitly: simulators and emulators are not physical devices.
Is Maestro Cloud free, or is it a paid add-on to Maestro Deck?
Local execution is free. Hosted execution is a separate decision, not a prerequisite for writing and running flows. The Maestro Deck desktop runner and inspector support writing and executing Maestro YAML end-to-end flows for iOS, Android, and web apps.
For your 2026 evaluation, separate the desktop application, the testing framework, and the hosted service. Similar names do not make their accounts, licenses, or commercial terms interchangeable.
| Option | Best for | What you get | Trade-off |
|---|---|---|---|
| Maestro Deck local runner | Developers writing and debugging flows locally | Free desktop execution and inspection for Maestro YAML flows | You manage the local test environment |
| Maestro Deck Cloud | Teams choosing hosted execution or connecting release automation | Optional paid cloud execution | You must evaluate service terms and execution requirements separately |
The comparison answers the practical purchasing question: you do not need to choose a hosted service before you can start local end-to-end testing. It does not establish current commercial terms for the separately named Maestro Cloud service.
Do not use one provider’s local-use terms as evidence of another service’s cloud entitlement. Match the exact service name to its official documentation before creating an account or approving spending.
Why this matters
A release workflow has separate jobs: author the test, debug the test, and execute it when a build needs validation. Buying hosted execution does not remove the work of defining a reliable flow. Keeping execution local does not automatically connect that flow to your release pipeline.
Start with the job blocking you now. If you cannot reliably exercise login on your development build, work on the flow and app state. If the flow already works and your team needs execution from CI, evaluate how a hosted service fits the build process.
This distinction prevents a common evaluation mistake: comparing a desktop authoring workflow with a hosted execution service as though they solve exactly the same problem. They overlap at test execution, but your responsibilities differ.
Free local execution: write and debug before choosing cloud
The free local runner is the starting point for developers who need to inspect an app and get a YAML flow working. You do not need a cloud account to use it locally.
Use the desktop workflow to answer concrete questions. Can the flow reach the intended screen? Does the assertion check the outcome you actually care about? Does the test start from a known state rather than depending on your previous manual session?
Keep the first flow narrow. Choose a user action with a visible outcome, such as signing in and reaching an authenticated screen. Avoid turning the first test into a tour of every feature; a long flow makes the first failure harder to isolate.
A useful local workflow is:
- Choose an outcome. State what the user must be able to complete.
- Prepare app state. Decide which account, permissions, and session state the test expects.
- Inspect the screen. Identify the elements the flow must interact with.
- Run the flow. Check that the test reaches the intended outcome.
- Inspect the failure. Separate an app defect from an incorrect test assumption.
The benefit is direct control over the test while you develop it. The limitation is ownership: your machine, app build, and test environment remain your responsibility. Free software does not remove setup or maintenance work.
Optional paid cloud execution: add it for a defined workflow
Choose hosted execution when you can name the release-workflow problem it solves. Examples include running tests from CI or moving execution away from a developer’s interactive desktop session. Neither goal requires you to stop debugging locally.
Before adopting cloud execution in 2026, write down the trigger, the app build, the target environment, and the result your pipeline needs. A successful upload is not the same as a completed test, and a completed test is not useful if nobody can act on its failure.
For any service under consideration, verify the documented answers to these questions:
- How does the service receive the app build and flow files?
- Which simulator, emulator, browser, or physical-device environments are explicitly supported?
- How does CI authenticate without exposing credentials in the repository?
- How does the pipeline learn whether execution passed or failed?
- Which failure details can the developer inspect afterward?
- What happens when an execution request cannot start?
These are evaluation criteria, not claims that a particular provider supports every behavior. Confirm each required capability before treating the service as a release dependency.
The upside is hosted execution that fits a team workflow. The trade-off is another service integration to configure, secure, and maintain. Check the current pricing before choosing paid execution; do not infer billing rules from the word cloud.
Evaluate optional cloud execution
Keep local testing free. Review cloud terms when your workflow needs hosted runs.
Why the right execution choice varies
The decision is not simply free versus paid. It depends on where the test must run and who maintains that environment. Use these factors to decide whether local execution still meets your needs.
- Development stage. A flow under active repair needs close inspection. Stabilize its assumptions before expanding where it runs.
- Execution trigger. A developer starting a test manually has different requirements from a pipeline waiting for a result.
- Environment ownership. Local execution leaves setup with your team. Hosted execution requires checking what the provider manages and what remains yours.
- Target coverage. Match the required operating system and browser to documented support. Do not substitute an emulator for a physical-device requirement without reviewing the test objective.
- Test data. Decide where credentials, accounts, and app data are allowed to go before sending them to a hosted environment.
- Failure handling. Determine who investigates failures and which evidence that person needs. A pass-or-fail result alone does not explain a broken screen interaction.
For a 2026 release plan, prioritize the factor that currently blocks dependable execution. Do not add hosted infrastructure merely because it appears to be the next step after installing a desktop tool.
Is the desktop runner the same as the Maestro framework?
Maestro Deck is a desktop runner and inspector for Maestro YAML flows, not another name for the Maestro framework. Keep the application, the flow format, and the hosted execution service distinct when reading documentation.
A practical division of responsibility helps. Framework documentation explains the supported flow syntax and command behavior. Desktop documentation explains how to write, inspect, and execute flows in that application. Hosted-service documentation explains submission, authentication, execution environments, and service terms.
Do not assume that a command shown for one execution path also configures another. Verify the documented integration before copying instructions into a release pipeline. Shared terminology does not establish affiliation, feature parity, or interchangeable accounts.
Does free local use mean the source is open source?
Source-available and open source are different licensing terms. Maestro Deck is described as source-available; do not relabel it open source because the local application is free.
Free use describes an offer. Source availability describes access to code. The license determines what you are permitted to do with that code, including modification and redistribution.
For a 2026 internal review, record those questions separately. If your organization needs permission to redistribute a modified version or embed components in another product, inspect the applicable license rather than relying on a product summary.
Can I keep debugging locally after adopting hosted runs?
Keep local debugging as part of the workflow even when you choose hosted execution. A failed release check still needs investigation, and a short local reproduction gives you a focused place to work on the flow.
Keep the relevant build, test data, and starting state aligned when investigating a failure. If local and hosted runs exercise different conditions, a local pass does not resolve the hosted failure. Identify the difference before changing assertions or adding retries.
What should I verify before connecting CI?
Define the result contract before wiring a test into a release gate. Decide what counts as a test failure, an execution failure, and a run that never started. Your pipeline should not confuse those outcomes.
Use a small, deliberate acceptance checklist for the integration:
- A known-good build completes the intended flow.
- A deliberately broken assertion is reported as a failure.
- Missing credentials produce an actionable execution error.
- The person investigating can find the relevant failure details.
- The release process handles the result according to your team’s policy.
This is a proposed validation procedure, not a claim about a provider’s behavior. Run it against the service and integration you actually select.
Keep secrets out of flow files committed to version control. Follow the selected service’s documented method for supplying credentials, and use test accounts appropriate for the environment. Hosted execution should not become an excuse to send production access details into an unreviewed workflow.
FAQ
Can I use Maestro Deck without paying for cloud execution?
Yes. Maestro Deck provides a free local desktop runner and inspector, and local use does not require a cloud account. Paid cloud execution is optional.
Is Maestro Cloud automatically included with a free local runner?
Do not assume a free local runner includes Maestro Cloud access. Verify the exact hosted service and its official terms separately from local-use terms.
Do I need cloud testing to write Maestro YAML flows?
No. You can write and execute Maestro YAML flows locally. Choose hosted execution separately when it meets a release-workflow requirement.
Does running tests from CI mean I must stop testing locally?
No. Keep local execution for writing and debugging flows, and evaluate hosted execution for the automation you need. Confirm the selected service’s documented CI integration before adopting it.
Are simulators and emulators the same as physical devices?
No. Simulators and emulators are not physical devices. Check the provider’s documented environment support against the behavior your test must validate.
Does source-available mean open source?
No. Source-available and open source are different licensing terms. Read the applicable license before assuming permission to modify, redistribute, or reuse code.
Where should I check current cloud billing terms?
Check the pricing and official documentation for the exact service you intend to use. In 2026, keep that review separate from the decision to use a free local desktop runner.
One last thing
Test the failure path before trusting the release check. Deliberately break an assertion and confirm that the result reaches the person or pipeline responsible for stopping the release.
A workflow that only demonstrates a passing run has not yet demonstrated how it handles a regression. Prove that behavior before expanding coverage or committing more execution work to a hosted service.
