CI/CD Integration

Run AegisRunner as part of your pipeline. Under Manage → CI/CD, create a trigger token for the project.

Triggering from CI

POST to the trigger endpoint with your token to kick off a scan or a test run from GitHub Actions, GitLab CI, Jenkins, CircleCI — anywhere that can make an HTTP request. The run shows up in the Runs lens and Activity panel like any other.

The aegis CLI

Prefer a command line over raw HTTP? Install the aegis CLI (zero dependencies, Node 18+):

npm install -g @aegisrunner/cli

Then, with your trigger token in AEGIS_TOKEN:

# run everything, wait, and write a JUnit report for your CI
aegis run --format junit --output aegis-results/junit.xml

# run a smart selection on Firefox
aegis run --strategy smoke --browser firefox

# re-scan the site, or your mobile app, after a deploy
aegis scan --url https://staging.example.com
aegis mobile-scan --platform android --role customer

# re-scan and BLOCK on it — streams live crawl + test-generation progress,
# exits 0 when done (1 if it failed) so a CI step can wait for the new tests
aegis scan --url https://staging.example.com --watch

# scan pages behind a login (password from stdin — never on the command line)
printf %s "$STAGING_PW" | aegis scan --username qa@example.com --password-stdin --watch

Exit code 0 means everything passed, 1 means test failures (fails your pipeline step), 2 means the CLI could not complete. The JUnit file contains real per-case rows — point GitLab artifacts: reports: junit: or Jenkins at it.

Watch a scan live

By default aegis scan fires and returns — a CI token can’t poll scan status. Add —watch and the CLI streams the crawl and AI test-generation phases live (over Server-Sent Events) and blocks until it finishes: exit 0 when the scan completes, 1 if it failed. Use it when a pipeline step should wait for a fresh scan and its generated tests before moving on.

Scan behind a login

To test pages that require signing in, hand the scan a login and it authenticates during the crawl:

Flag	What it does
—username <u>	The login identity — email, username, phone, employee id, anything. The scanner’s AI maps it onto whatever the login form calls its identity field, so there’s nothing to configure per app.
—password-stdin	Reads the password from stdin — keeps it out of your shell history and ps. Set AEGIS_PASSWORD instead if you prefer an env var. A password is never accepted as a plain flag.
—role <name>	Scan as a saved role (Admin / Buyer / …) — uses that role’s stored login, no —username/password needed, and tags the scan and its generated tests with the role.

Credentials passed this way are also saved to the project’s login, so authenticated test runs and later re-scans can sign in too. Works together with —watch, —tunnel, and —url.

Private, staging, or firewalled targets

Testing an app the cloud can’t reach — behind a VPN, on localhost, or on an IP-restricted staging box? The same CLI runs a self-hosted runner inside your network (outbound-only, no inbound port) and can open a temporary aegis tunnel to a local port. See Testing behind a firewall.

Results back to your pipeline

Pair triggers with webhook or issue-tracking integrations (GitHub Issues, Jira) so failures land where your team already works. Tokens are scoped per project and can be revoked anytime.