Deployment

How VigilQA is deployed depends on where your application under test is hosted. This page covers both scenarios — they can coexist for different projects.

How it works

The VigilQA dashboard is hosted centrally at api.sentinelflux.in. It manages everything: knowledge base, test docs, run scheduling, run history, analysis, and user management. Tests are never executed on the dashboard server.

Test execution is handled by a runner daemon — a lightweight process (vigilqa runner) that polls the dashboard for queued runs, executes pytest locally against your application, and streams results back in real time. The runner must be on a machine that can reach your application under test.

Who installs what: The dashboard is already running — you do not install or manage it. The only question is where the runner lives, which depends on whether your application is publicly reachable.

Choose your scenario

Scenario A

Application is publicly accessible

Your staging or production URL is reachable from the internet (e.g. https://staging.acme.com). The VigilQA team operates a central runner that can reach it. You log into the dashboard, configure your project, and trigger runs — no infrastructure to set up on your side.

Scenario B

Application is behind a firewall or internal network

Your application is only reachable inside your corporate network (e.g. http://internal.acme.com). You install a runner inside your network. The runner polls the dashboard, runs tests locally against your internal URL, and posts results back. The dashboard itself never needs to reach your application.

Scenario A — Public application

Nothing to install. The VigilQA central runner on our infrastructure handles test execution.

Task	Responsibility
Dashboard	VigilQA (already hosted at api.sentinelflux.in)
Runner	VigilQA (central runner, reaches public URLs)
Test code	VigilQA team authors and deploys
Triggering runs, viewing results	You — via the dashboard in your browser
Installing software	Nothing required on your machines

To get started: log in, add your project, build the knowledge base, and trigger your first run. See the Quick Start guide.

Scenario B — Internal application

You install one runner process inside your network. It connects outbound to the dashboard — no inbound ports, no firewall rule changes needed.

Task	Responsibility
Dashboard	VigilQA (already hosted at api.sentinelflux.in)
Runner	You — installed on a machine inside your network
Test code	VigilQA team — delivered as a versioned archive
Runner token	Generated in dashboard, shared with you by your VigilQA contact
Triggering runs, viewing results	You — via the dashboard in your browser

Prerequisites (runner machine)

A machine inside your network that can reach your application under test
Outbound HTTPS access to api.sentinelflux.in (port 443)
Python 3.10 or later — python.org/downloads
pip (bundled with Python — verify with pip --version)
For web UI tests: Playwright with Chromium (see install steps below)
For mobile tests: Appium server running locally or accessible on your network

Step 1 — Install the runner

Your VigilQA contact will provide a wheel file (.whl). Install it with pip — this automatically pulls all required open-source dependencies from PyPI:

pip install vigilqa-<version>-py3-none-any.whl

If your project includes web UI tests, install Playwright and the Chromium browser:

pip install playwright
playwright install chromium

Tip: Run these commands inside a Python virtual environment to keep the runner isolated from other Python packages on the machine.

Step 2 — Extract the test suite

Your VigilQA contact will also provide a test suite archive for your project. Extract it to a working directory:

tar -xzf vigilqa-tests-<project>-<version>.tar.gz -C /opt/sf-runner

The extracted layout will look like:

/opt/sf-runner/
  products/
    <your-project>/
      tests/
        web/
        api/
      pages/
      locators/
      config/
        env_qa.yaml     ← edit this before starting

Step 3 — Configure your application URL

Edit config/env_qa.yaml inside the extracted directory. Set the base URL and any credentials needed to reach your internal application:

web:
  base_url: "http://internal.acme.com"
api:
  rest_base_url: "http://internal-api.acme.com"
credentials:
  username: "test-user@acme.com"
  password: "your-test-password"

Important: Use a dedicated test account, not a personal or admin account. The runner will log in and perform actions against your application during test execution.

Step 4 — Generate a runner token

In the dashboard, go to Settings → Runners → Create Token. Give the token a name (e.g. acme-internal-runner) and scope it to your project. Copy the token — it is shown only once.

Step 5 — Start the runner

Use the setup wizard to configure the runner as a background service:

vigilqa runner-init

The wizard prompts for your API URL, token, and working directory, then writes a runner.env configuration file and registers a system service (systemd on Linux, launchd on macOS) so the runner starts automatically on boot.

Alternatively, start the runner manually for testing:

cd /opt/sf-runner
vigilqa runner \
  --api-url https://api.sentinelflux.in \
  --token sfr_<your_token> \
  --work-dir /opt/sf-runner

Once running, the daemon polls the dashboard every 30 seconds. When a run is triggered from the dashboard, the runner claims it, executes pytest against your internal application, streams live progress, and posts the full report when done. Everything is visible in the dashboard — no VPN or direct access to the runner machine is needed to view results.

Verifying the connection

After the runner starts, go to Settings → Runners in the dashboard. Your runner should appear with a green Online status and a recent Last seen timestamp. If it shows offline, check that the machine has outbound HTTPS access to api.sentinelflux.in and that the token is correct.

Both scenarios together

Scenario A and Scenario B can run simultaneously. If you have multiple projects — some with public URLs and some internal — each project is configured with its own preferred runner in the dashboard (Settings → Run Config → Runner). The dashboard routes each queued run to the correct runner automatically. Runner tokens are scoped to specific projects, so runners only ever claim runs they are authorised for.

Upgrading the runner

When a new version is available, your VigilQA contact will provide an updated wheel and test suite archive. To upgrade:

# Stop the runner service first, then:
pip install vigilqa-<new-version>-py3-none-any.whl --force-reinstall
tar -xzf vigilqa-tests-<project>-<new-version>.tar.gz -C /opt/sf-runner
# Restart the runner service

Your configuration in env_qa.yaml and runner.env is preserved across upgrades.