Cloud & Webapp
Cloud is the shared webapp plane for the assets Glubean produces locally: synced projections, uploaded run evidence, browser-side investigation, docs, reports, performance views, and the webapp Agent.
Read this section when source-authored behavior has crossed from the repo into the shared product surface. Cloud has two main inputs:
| Input | Command | What it updates |
|---|---|---|
| Projection sync | glubean sync | Specifications, OpenAPI-shaped projections, workflow context, and agent/spec context. |
| Run upload | glubean run --upload / glubean load ... --upload | Target run history, failures, traces, artifacts, metrics, alerts, and load evidence. |
Start here:
- Targets & Runs
- Specifications
- Explore
- Library & Resources
- APIs & Portals
- Performance
- Benchmarks
- Agent
- Dashboard
Webapp Map
The current app groups the webapp plane into a few practical work areas. Some surfaces are top-level modules; others live inside a selected Target.
| Area | Surfaces | What it means |
|---|---|---|
| Target evidence | Target switcher, Overview, Runs, Tests, Endpoints, Performance, Metrics, Alerts, Settings | Uploaded evidence about one system under test. |
| API & Docs | Specifications, APIs, Portals | Contract projections, writer overlays, and published docs. This is the primary path for turning executable behavior into human-readable API knowledge. |
| Explore & Test | Explore, Library | Browser-side investigation, flows, code tests, and reusable shared modules. |
| Resources | Environments, Data, Files | Inputs that browser-side requests, flows, and code tests consume. |
| Observe | Reports, Target Alerts, Performance, Benchmarks | Health digests, operational signals, target-local load evidence, and cross-source load comparison. |
| Home dashboard | Get started, recent runs, active alerts, module shortcuts | Org-level orientation and the fastest route into current evidence. |
The important boundary is authorship. Durable behavior should live in source as contracts, workflows, tests, browser checks, or load plans. Cloud makes those assets readable and adds webapp-native surfaces for investigation, writing, and team review.
What Cloud receives
Cloud does not execute your repo code. Local machines and CI runners execute tests, contracts, browser checks, and load plans. Cloud receives redacted, structured evidence through uploads and sync.
What Cloud makes readable
- target health and run history
- run detail and failure objects
- contract projections and synced Specifications
- Explore requests and flows
- reusable Library modules
- Environments, Data assets, and Files for webapp-side execution
- API docs and Portals
- reports, in-app notifications, alerts, and performance views
- benchmarks for cross-source load comparison
- current-view context for the webapp Agent
Performance vs Benchmarks
Both surfaces read uploaded kind=load evidence. They answer different
questions:
| Surface | Scope | Use it when |
|---|---|---|
| Performance | One Target over time, or two runs inside that Target. | You want trend, capacity, SLA gates, baselines, or run A vs run B for one implementation/deployment. |
| Benchmarks | Several source Targets under one shared loadRunner plan id. | You want to compare implementations or deployments side by side, such as Bun vs Express. |
If the question is “did this target regress?”, use Performance. If the question is “which source wins under the same workload?”, use Benchmarks.
Operational details such as tokens, dashboards, analytics, redaction, notifications, quotas, and agent access live after the main product flow.