Platform Overview
Proofarc is the Unified Release Engineering Platform. One place to author, run, and reason about everything that gates a release — tests, scans, performance runs, compliance evidence, readiness scoring. Built around a simple idea: every quality activity should feed the next one.
The Pipeline
Define Tests → Execute → Convert to Performance → Scan for Security
↓ ↓ ↓ ↓
All results feed into one Readiness Score (0-100)
↓
Automatically mapped to Compliance Controls
↓
Ship or Don't Ship
Why this matters
In a typical setup, you:
- Write API tests in one tool
- Rewrite the same scenarios for performance testing in another tool
- Run security scanners separately
- Manually compile results for compliance audits
- Have a meeting to decide if it's safe to release
In Proofarc, you:
- Write API tests once (YAML)
- Click "Convert to Performance Test" — same endpoints, same auth
- Security scanners run against the same targets
- Compliance evidence is auto-generated
- One score tells you: ready or not ready
Core Concepts
Proofarc separates three kinds of things that traditional tooling conflates: what you build, where you run it, and how you organize the work.
Applications
An Application is the deployable thing your team owns — a REST API,
a web UI, a mobile app. Applications are top-level and canonical:
one user-service row, regardless of how many teams or release contexts
reference it. The Application carries its git URL, default branch,
registry, and Jira key once — no duplication.
Reference: Applications & branch tracking.
Projects
A Project is a grouping concept — the team or release context that uses one or more Applications. Projects link to Applications through memberships (with a tracking mode: LATEST or PINNED to a branch). A Project doesn't contain Applications; it tracks them.
Reference: Projects & Environments.
Tests belong to Applications
API scenarios, UI tests, performance scenarios, and mobile tests all
carry an application_id. They live in a Project for grouping, and
point at the Application they cover. That's what lets you ask
"what tests cover user-service?" across every Project.
Reference: How tests map to applications.
Environments
Each Project has environments: development, QA, staging, production.
An Environment Target says "this is how the user-service
Application is deployed in this environment" — the URL, the auth
config, the credentials. Same Application, three environments → three
Environment Targets.
For network-shaped targets (hosts, subnets, K8s clusters, container
registries), Environment Targets link to a canonical Infrastructure
Target. That keeps findings on auth-host-prod deduplicated across
environments.
Reference: Infrastructure targets.
Test Types
| Type | How it works |
|---|---|
| API Scenarios | YAML or JSON-defined HTTP request sequences with assertions and variable extraction |
| UI Tests | Browser automation via Selenium or Playwright, defined in YAML |
| Mobile Tests | Appium-based mobile app testing |
| Performance Tests | Load testing — converted from API scenarios or defined standalone |
| Security Scans | Vulnerability scanning with multiple tools (auth inherited from targets) |
Readiness Scoring
The platform computes a 0-100 readiness score from weighted milestones:
- Security (findings count + severity)
- API Tests (pass rate + contract coverage)
- UI Tests (pass rate + cross-engine compatibility)
- Performance (response times + error rates)
- Code Quality (practices + review quality)
- Compliance (framework control status)
Prediction
Before tests run, Proofarc predicts:
- Which tests will fail — based on historical code-change-to-test correlation
- Release risk level — from 7 development process signals
- Hidden quality issues — runtime log errors that pass tests but indicate problems
Self-Hosted
Proofarc runs on your infrastructure. Your data never leaves your network.
- Docker Compose — single command, runs everywhere
- Kubernetes — Helm chart for production deployment
- No cloud dependency — works air-gapped