Skip to main content
Momentic is CLI-first. Tests live in your repo as YAML, are authored and edited with the CLI (and your coding agent through MCP), and run locally or in CI. The web app at app.momentic.ai is the dashboard for triage, settings, and integrations.

​
Move your tests with momentic import

Check Node.js before running the CLI or onboarding wizard:
Both require Node.js 22.12.0 or later in the 22.x line, or 24.0.0 or later. Update unsupported versions, including Node.js 20 and 23, in your local runtime and CI. Import into the web project’s directory containing momentic.config.yaml. If you do not have a project yet, the onboarding wizard installs the CLI, logs you in, and scaffolds the configuration:
For an existing project, commit or stash local changes first and confirm that the CLI is authenticated to the workspace you want to export. Run momentic login to select an account, or set MOMENTIC_API_KEY for that workspace. Then run:
This imports the workspace’s web tests, their referenced modules, and environments. Unused standalone modules are not included; check them separately before retiring the cloud project. Review the overwrite prompts: the importer can replace existing test files and both the base URL and variables in environments with matching names. Keep prompts enabled for the first import. An interrupted import can leave some files written; review the diff before retrying or restoring your saved state.
Imported environment variables can include plaintext secrets. Move them to an ignored .env file or your CI secrets before staging files. Follow Secrets to retain the same variable names at runtime.
See momentic import for flags. You can also pass test paths to import individual tests or folder paths (e.g. auth/onboarding) to import that folder’s tests and their referenced modules. The folder hierarchy is recreated on disk. Imports with explicit paths bring in tests and modules; they do not import environments. Configure the required environments before running that selection. In a workspace repository, change into the selected project’s directory before importing. Pass --config if needed to select its configuration; that flag does not change where newly imported files are written.

​
What is deprecated

These surfaces are no longer supported. They may still respond for backwards compatibility but will be removed in a future release.
  • Authoring tests in the cloud editor. Create and edit tests with the CLI (and the local editor it ships with) or your coding agent via the MCP server.
  • Cloud-hosted test runs (momentic queue tests and queue suites). Run with momentic run locally or in CI instead.
  • Momentic Copilot (the cloud-based AI authoring assistant). Use your coding agent with the MCP server for natural-language test authoring.

​
What is not deprecated

The dashboard at app.momentic.ai still handles repository test results and configuration: This deprecation applies to the legacy cloud test editor and queue commands. Mo sessions still run from the web app or qa CLI. Hosted browsers still work with momentic run; your CLI or CI runner controls the test execution.

​
After importing

The import moves test definitions. It does not configure CI jobs or recreate cloud suite schedules. Record the old suite’s test selection, environment, parameters, browser settings, concurrency, and schedule before replacing it.
1

Validate the imported files

Run lint and check that every expected test appears in the local selection:
The importer writes the format selected by fileFormat in your project config. For a legacy project, use the simplified format migration before editing YAML with a coding agent.
2

Run one imported test

Use an actual path from momentic list and the environment used by the cloud run. For example, if your imported environment is named staging:
Confirm the starting URL, test data, assertions, and setup/cleanup behavior. Review recovery and failure classifications as well as the final status. The test’s own url takes precedence over the selected environment’s base URL; see environment selection if the run targets the wrong deployment.
3

Author with the CLI or MCP

Edit imported tests (or write new ones) in the local editor that ships with the CLI, or hand your coding agent the MCP server and describe the behavior in natural language. Tests are YAML files in your repo.
4

Run locally and in CI

Replace momentic queue tests and momentic queue suites with momentic run. Translate each suite into explicit paths, directories, or labels, then use momentic list with the same selection to check its membership. Recreate environment variables, parameters, and schedules in your CI provider using the CI templates.Run the imported selection in CI and compare it with the previous suite before removing the old queue job. Confirm the expected tests and parameterized cases actually ran; account for disabled or skipped tests, quarantine, recovered passes, and failure classifications. Exit code 0 alone does not prove coverage parity. Check an expected failed assertion so the new job’s exit status blocks the pipeline as intended.
5

Triage in the dashboard

Pass --upload-results so runs appear in the dashboard. Open the uploaded run and verify its test count, environment, and results before switching the suite over.

​
Why CLI-first

CLI-first means tests are versioned with your application code, run the same way on a laptop and in CI, and connect to coding agents through MCP. The dashboard’s job is triage and configuration, not authoring or execution.