Evidence-first API QA, coverage and release-decision workspace.
A self-hosted QA application for turning scattered API checks, imported evidence, findings and release signals into one reviewable decision flow.
Aptoria is a QA-focused workspace built for people who need more than isolated test results and loose notes.
It helps you collect API evidence, review endpoint coverage, track findings, evaluate release readiness and prepare a decision package that can be revisited later.
It is not trying to replace Postman, Jira, CI, or a full test-management suite. Aptoria sits in the layer between them: the place where evidence is gathered, reviewed, connected and turned into a release decision.
Important
Aptoria is built around one simple idea: a release decision should be backed by visible evidence, not memory, chat messages or guesswork.
| Need | How Aptoria helps |
|---|---|
| API evidence is scattered across tools and files | Centralizes review evidence in one local workspace |
| Endpoint coverage is hard to judge | Makes endpoint inventory and coverage visible |
| Findings get lost between testing and release | Tracks issues, retests and closure state in context |
| Release readiness is subjective | Turns evidence into a structured release-readiness review |
| Reporting takes too long | Creates reviewable outputs and decision packages |
| A portable local workflow is needed | Runs as a local portable application with license-aware runtime control |
- Project-based QA workspace for API-focused review work
- Evidence repository for requests, responses, notes and attached files
- Endpoint inventory and coverage visibility
- Findings and retest workflow
- Release readiness review and structured decision support
- Import support for bringing external QA artifacts into one place
- Portable local edition with online activation and runtime lease validation
- Report and decision-package output for traceable release communication
flowchart LR
A[API tools<br/>Postman / Newman / HAR / CSV / OpenAPI] --> B[Aptoria]
C[Manual testing<br/>Notes / Screenshots / Files] --> B
D[Issue context<br/>External QA sources] --> B
B --> E[Evidence review]
B --> F[Coverage overview]
B --> G[Findings workflow]
B --> H[Release readiness]
H --> I[Decision package / report]
Aptoria is the review and decision layer where disconnected QA artifacts become something operationally useful.
flowchart TD
A[Create project] --> B[Define environments and auth profiles]
B --> C[Build endpoint inventory]
C --> D[Import or capture evidence]
D --> E[Review findings and gaps]
E --> F[Evaluate release readiness]
F --> G[Generate report / decision package]
This workflow is especially useful when a release decision depends on multiple signals, not just whether a few requests returned 200 OK.
| Module | Purpose |
|---|---|
| Projects | Separate QA work by product, environment, release or customer context. |
| Environments | Store target systems such as staging, sandbox or production-like environments. |
| Auth Profiles | Keep authentication details separate from endpoint definitions. |
| Endpoint Inventory | Register routes, methods, status, ownership and review state. |
| Evidence Repository | Store evidence files, imported artifacts, notes and supporting proof. |
| External Imports | Bring in QA data from supported import formats instead of re-entering it manually. |
| Findings | Track issues, retests, severity, resolution state and audit trail. |
| Release Readiness | Review whether the current body of evidence is enough to ship. |
| Reports | Generate structured outputs for review and communication. |
| In-app Console | Run approved support and diagnostic commands inside the application. |
Instead of checking one endpoint at a time in isolation, Aptoria helps you see the broader release picture:
- which endpoints exist;
- which ones were reviewed;
- what evidence is attached;
- what is missing;
- what findings are still open;
- whether shipping is supported by the available evidence.
Aptoria is designed to work with imported material, not just manually entered records.
Typical examples include:
- API collections or exported evidence
- HAR or browser-network captures
- CSV-based QA inputs
- endpoint lists and inventory data
- supporting screenshots or files
Aptoria does not stop at evidence storage. It connects evidence, findings and readiness into a practical decision layer.
That means you can answer questions like:
- Are we ready to ship?
- Which endpoints still need evidence?
- What critical findings are still open?
- What changed since the last review?
- What do we need to show in a release review?
| Use case | Example |
|---|---|
| API release review | Evaluate whether a release candidate has enough endpoint evidence to move forward. |
| Regression evidence collection | Keep findings, proof and retests tied to the same release context. |
| Pre-release QA checkpoint | Review whether the current testing body is enough to approve or hold a release. |
| QA portfolio / demonstration | Show a structured evidence-first QA workflow in a local application. |
| Self-hosted local review | Keep QA work in a portable, reviewable local setup rather than a hosted dashboard. |
Aptoria is meant to produce outputs that are useful beyond the application itself.
Depending on the workflow, outputs may include:
- reviewable reports;
- decision-package style exports;
- evidence-linked summaries;
- release-readiness overviews;
- structured QA artifacts for later review.
The aim is clarity: if someone asks why a release was approved or held, the answer should not rely on memory alone.
Aptoria 2.1.9 is centered around the portable local build.
The portable edition uses:
- online activation;
- trial start from the application;
- signed build integrity verification;
- installation-aware / instance-aware runtime checks;
- short runtime lease validation through the Aptoria license authority.
flowchart LR
A[Clean portable install] --> B[Environment and build checks]
B --> C[Online trial or activation package]
C --> D[Local activation state]
D --> E[Short runtime lease validation]
E --> F[Use Aptoria Portable]
This model is designed to keep the portable build practical for real users while still preserving license control and build authenticity.
Use the included starter:
start-aptoria.batThe starter is intended to:
- check the local PHP runtime;
- verify required folders and files;
- verify the signed build integrity;
- prepare the local
.envand SQLite database when needed; - install Composer dependencies when needed;
- run migrations;
- start the local application.
On a fresh install, Aptoria guides the user through the local startup and activation process. Depending on the license state, you can typically:
- start the trial online;
- upload a received activation package;
- continue into the local QA workspace after validation.
If you want to run the application from source for review or local testing, use the following baseline flow.
PHP 8.2+
Composer
SQLite extension
ZIP extension
Local browser
Internet connection for online activation / runtime validation
composer install
cp .env.example .env
php artisan key:generate
mkdir -p database
mkdir -p storage/framework/cache/data storage/framework/sessions storage/framework/views
php artisan migrate --seed
php artisan serve --host=127.0.0.1 --port=8000Open the local application at:
http://127.0.0.1:8000
| Path | Description |
|---|---|
app/ |
Application code |
bootstrap/ |
Laravel bootstrap files |
config/ |
Application configuration |
database/ |
Migrations, factories and seeders |
public/ |
Public entry point and bundled UI assets |
resources/ |
Views, translations and UI resources |
routes/ |
Web, API and console routes |
runtime/ |
Portable runtime policy and build verification files |
storage/ |
Runtime directory structure |
start-aptoria.bat |
Windows portable starter |
VERSION |
Current package version |
Note
Depending on the distribution, the VPS License Issuer may be handled as a separate deployment package. Production issuer configuration, registry data and private signing keys are intentionally excluded from public distribution.
The public package does not include production-sensitive or local runtime artifacts such as:
.env
vendor/
node_modules/
database/database.sqlite
runtime lease tokens
issued activation packages
customer data
production server configuration
private signing keys
license authority registry data
generated local reports or decision packages
This keeps the repository suitable for public review while protecting operational and customer-side runtime material.
Aptoria is best understood as:
- a QA evidence workspace,
- a coverage and findings review layer,
- a release-readiness support tool,
- and a portable local application with controlled activation.
It is not positioned as:
- a full API client replacement,
- a full issue tracker replacement,
- a CI pipeline replacement,
- or a generic SaaS analytics dashboard.
Do not publish:
- local runtime state,
- generated license files,
- customer evidence,
- private keys,
- tokens or credentials,
- generated portable runtime lease files.
The public build may contain public keys and signed manifest files required for build verification. Those are not secrets, but they are part of the official build chain and should not be edited manually.
Report security issues privately to the maintainer.
Current package: 2.1.9
This public package is suitable for:
- code review,
- local evaluation,
- functional review,
- portfolio presentation,
- controlled non-production testing.
It does not include production infrastructure, issued customer licenses, private signing material or deployment secrets.
Aptoria is source-available, not open-source.
Public visibility is intended for:
- review;
- local evaluation;
- portfolio presentation;
- controlled, non-commercial testing;
under the terms described in the project license and notice files.
Commercial redistribution, hosted-service use, white-label use, sublicensing, resale, or removal / bypassing of runtime and license controls require separate written permission.
See:
LICENSE
NOTICE.md
SECURITY.md
THIRD_PARTY_NOTICES.md
CREDITS.md
János Szujó
Product concept, workflow direction and development.