What is Strikekit?

Strikekit is a precision QA workspace for teams. It keeps test suites organized in the cloud, runs them on your machine (behind your firewall), and shares run results as proof across the team.

Cloud-managed test suites. Local execution via strikekit-agent. Shared proof for every run.

You work in the web app — no day-to-day CLI typing required. The browser starts and monitors runs; a local agent + runner execute tests on your computer.

Group: Authentication

    Scenario: User login @smoke
        Given I navigate to "https://example.com/login"
        When I fill "username" with "chamodh"
        And I fill "password" with "1234"
        And I click on "Login"
        Then I should see "Welcome back"

Suites are plain-English .stk files. The web app manages versions, pairing, live runs, and reports.

The core idea

Tests do not run in Strikekit’s cloud by default. The browser controls the run; execution stays local via the agent.

Architecture

• Agent listens on localhost only (127.0.0.1:19527) — no public ports.
• You stay in the browser; the agent has no product UI of its own.

What you can do in the web app

Organization & team

• Create an account, verify email, create an organization or join via invite
• Multi-tenant workspace with roles / RBAC
• Invite members, manage team (Settings → Team)
• Billing / plans, usage visibility

Projects & versioned suites

• Create projects under your org
• Upload versioned .stk suite files (semver-style version keys), including main.json manifests and assets
• Cloud is the source of truth for shared suite versions

Local runs (Run tests)

Both stream live pass/fail / logs (NDJSON) into the Run tests dashboard.

Sync & run flow

Reports

• After a run, upload ReportV1 JSON to the cloud
• List / view step-level results and errors
• Excel export
• Shared proof for the team

QA + Jira (plan-dependent)

• Connect Jira under Settings → Integrations (OAuth)
• Sync QA tickets into the QA queue
• Run tests linked to a ticket (issueKey)
• Transition tickets and attach reports as evidence

Dashboard areas

Typical sidebar: Dashboard, Projects, Run tests, QA, Reports, Usage, Audit, Billing, Settings (General, Team, Integrations, System). What you see depends on permissions and plan features.

Illustrative mix of team activity (example only — not live metrics):

How to use it (quick start)

Getting started journey

1. Sign up

1. Open the Strikekit web app
2. Create an account / start trial
3. Create an organization or accept a team invite

2. Create a project and upload suites

1. Go to Projects
2. Create a project
3. Upload a versioned .stk suite (with main.json)

3. Install local tools

You need both:

1. strikekit-agent — background service
2. strikekit runner — executes tests

Install from the Download page / GitHub releases (Windows, macOS, Linux; GUI installer or one-liner scripts).

Default runner paths:

• Linux / macOS: /usr/local/bin/strikekit
• Windows: C:\Program Files\Strikekit\strikekit.exe

Verify the agent:

strikekit-agent status
curl http://127.0.0.1:19527/v1/health

4. Pair this computer

1. Sign in to the web app on the same machine where the agent is running
2. Open Run tests
3. Click Pair this computer
4. Browser links to the local agent with a short-lived pairing code

Re-pair after agent upgrades or config changes.

5. Run

• Sync & run — select project + version → Sync & run
• Local folder — choose/enter a path → Run

6. Review & share

• Watch live results in the dashboard
• Upload / open the report
• Optionally link to a Jira issue

Most important things to know

1. Two binaries, not one — Agent ≠ runner. Agent pairs/syncs/spawns; runner executes strikekit run main.json.
2. Execution is local — Suites are managed in the cloud; runs happen on your machine. The agent does not open inbound ports to the internet.
3. You must pair before running — Pairing binds your signed-in browser session to this computer’s agent.
4. Same machine for browser + agent — Pairing and sync talk to 127.0.0.1. Use the web app where the agent is installed.
5. Sync & run vs Local folder — Shared team versions → Sync & run; local paths without download → Local folder.
6. .stk + main.json — Suites are the Strikekit package format; the runner entrypoint is typically main.json.
7. Agent is a background service — Linux user systemd unit, macOS LaunchAgent, Windows Service. No separate desktop app to open.
8. Config under ~/.strikekit/ — agent.yaml and synced projects under projects/{projectId}/ (Windows: %USERPROFILE%\.strikekit\).
9. Permissions & plans matter — Nav and features (Jira, SSO, audit, limits) depend on RBAC and plan (Free / Pro / Enterprise).
10. CI/CD is self-managed today — Run the runner from any shell/CI machine with the tools installed. There are no built-in native GitHub Actions / GitLab / Jenkins / Azure DevOps app integrations yet.
11. What gets stored after a run — Live steps over WebSocket; ReportV1 JSON for list/view/Excel. Video / network-trace cloud storage is not in the current product.
12. Security in one line — Localhost-only agent + Origin checks + short-lived pairing codes + HttpOnly cookie for agent requests + outbound-only cloud calls.

Glossary

Language & local CLI (optional)

The web app is the primary control surface. Under the hood, scenarios still use the Strikekit language (navigate, fill, click, should, …). Power users and CI can call the runner directly:

strikekit run main.json
strikekit run --browsers chrome path/to/scenario.stk

See Language, Commands, Qualifiers, and Examples for the .stk language. Install and editor setup remain under Getting started.

Start here