Manta handbook · 10 of 12
How to Fit Manta Into Your Release Process
Where autonomous runs belong in a real workflow — what to run on a merge, what to run before a release, and how to pace runs so effort and cost match value.
The other pages in this handbook cover individual tasks. This one ties them into a workflow: when to run Manta, at what depth, and how it slots in next to your existing tests. Runs can be started on demand from the dashboard, triggered directly from your CI/CD pipeline, or set to fire automatically on a recurring schedule — so "when to run" is a pipeline you configure, not just a habit you build.
The short version
- On a merge to main — trigger a moderate diff run from your CI pipeline against staging, plus your critical-journey plain-English checks.
- Before a release — a deeper full run against the release candidate, either on demand or as a required pipeline step; review every finding.
- Every week or so — a recurring schedule that fires a full run against staging automatically, to catch anything that drifted.
- After a hotfix — a targeted run over the area you changed, started on demand.
Step 1 — Wire the critical journeys as must-pass checks
Turn your handful of can't-break flows — sign-up, login, checkout, the core loop — into plain-English suites. These run alongside every autonomous run and give you an explicit pass/fail, not just "exploration found nothing obvious."
Step 2 — Automate the trigger
Two ways to get a run started without someone doing it by hand:
- CI/CD API key. Generate one from your organization settings and add a step to your pipeline that calls the run endpoint with it — merge-to-main and release-candidate runs fire on their own. Keys default to no completion email or in-app notification (the pipeline consumes results via the API), or opt one in if you want the normal notification too.
- Schedules. Set a recurring cron schedule — hourly, daily, weekly, monthly, or custom — for a crawl or a test suite/plan execution, no pipeline step required. This is the natural fit for the "every week or so" staging sweep.
Pick whichever matches the trigger: pipeline events (merge, deploy, release) want an API key; a fixed cadence wants a schedule.
Step 3 — Match depth to the moment
- Merge: a moderate diff run. Fast, cheap feedback that catches the obvious breakage in what changed.
- Release candidate: a deep full run. This is the one that matters; spend the credits.
- Between releases: a periodic full run so the picture stays current.
- Hotfix: shallow and targeted to the changed area.
This keeps credit usage proportional to how much the run's result matters.
Step 4 — Make the review a habit
A run only helps if someone looks at it. Assign triage ownership per project (team setup), turn on issue notifications, and treat "review the pre-release run" as a checklist item, not an optional extra. A finding in the area a release changed is almost always a regression from that release.
Where it sits next to your other tests
Unit and integration tests run in CI on every commit. A small scripted end-to-end set runs on merge for exact assertions. Manta covers the broad end-to-end layer — triggered on merge and before release from your CI/CD pipeline, and periodically in between on a schedule. Where autonomous testing fits has the full picture, and continuous testing covers the strategy.
The takeaway
Must-pass checks for the critical journeys, an automated trigger (API key or schedule) instead of someone remembering, run depth matched to the moment, and a standing habit of reviewing the pre-release run. That's the whole workflow.
Start a free run and put it into practice.
Try it on your own app
Point Manta at a URL and see what it finds — no scripts, no setup. Free, no credit card.