Execution models

Desktop vs Web

Both apps use the same engine, so the same baseline and candidate give the same findings. What differs is where your data lives, how traffic is captured, and who can use each one.

Filter perspectiveDim the column that isn’t your target runtime

DesktopElectron app

For one developer, on their own machine.

Works fully offline — no telemetry, no update checks, no cloud features
No account; everything lives in the app’s user-data folder
Reads your source folder in place — code is parsed, never copied
Captures by attaching to Chrome DevTools Protocol

WebSelf-hosted, multi-user

For a team, on a Nuxt/Nitro server someone runs.

Each person signs in with Google
Each project has one owner — shared team projects aren’t built
Upload a HAR file, or capture with a separate browser-capture worker
A Plans & billing page when the operator connects a billing service

01What stays constant

Storage engine

SQLite (node:sqlite)

the same engine on both apps

Desktop load test

200 VUs · 500 rps

30 min, one run per project

Web load test

Off by default

NUXT_LOAD_TEST_ENABLED

Encryption at rest

AES-256-GCM

OS keychain (desktop) · HKDF key (web)

02Feature by feature

Feature	Desktop (Electron + SQLite)	Web (self-hosted, Nuxt + SQLite)
Install	Download an installer (.dmg / .deb / .exe), or `npm run dev` from source.	Build `.output` and run it with Node, or `npm run dev:web`.
Account	Google, through the account service — the same account as on the web.	Google, through the account service; the account is created on first sign-in.
Where data lives	The app’s user-data folder: `contract-guard.db` plus artifact files.	The server’s `NUXT_DATA_DIR`: `fcg.db` plus extracted source files.
Project ownership	Single user, local to the machine.	Multi-user accounts; each project has one owner — teams and shared projects aren’t built.
Encryption key	Wrapped by the OS keychain (macOS Keychain, Windows DPAPI, libsecret/kwallet).	Derived (HKDF) from `NUXT_SECRET_KEY`, or a generated `secret.key` file.
Capturing traffic	Attaches to Chrome DevTools Protocol on an isolated Chromium session.	HAR upload, or a separate browser-capture worker that replays journeys under a destination allow-list.
Source code	Read from your project folder in place; never copied.	Uploaded as a `.zip`; decrypted into a private temp folder only while an analysis runs, then removed.
Sending requests (Explorer, instances)	From the main process, to the project’s environment hosts plus hosts you add in Settings.	Off unless the operator sets `NUXT_EXECUTION_ENABLED` and `NUXT_EXECUTION_ALLOWED_HOSTS`.
API Test Lab load tests	200 virtual users, 500 requests/s, 30 minutes — one run per project.	Off by default (`NUXT_LOAD_TEST_ENABLED`); limits are set by the operator.
Production guard	Blocked unless the environment is named “prod” or “production”, and you unlock it for the run.	Blocked unless the environment kind is `production`, and you unlock it for the run.
Phone use	Desktop window only.	Responsive phone layout with a bottom navigation bar.
“Open in editor”	Opens the matched line in VS Code or the system editor.	Shows the file path and line; no editor to open.
Plans & billing	Not applicable.	Shown when the operator sets `NUXT_PUBLIC_BILLING_API_URL` (served by `apps/api`).
CI	The `fcg` CLI — same engine, run locally or in a pipeline.(Same in both)
Languages	English and Arabic (right-to-left).(Same in both)
Findings & workbench	Shape diff, source mapping, confidence model, API Explorer, API Documentation and Journey Instances — identical behaviour.(Same in both)

03Where each one is different

Direct CDPOn desktop: a direct, local session

Capture connects straight to a loopback Chrome DevTools Protocol session in an isolated Chromium profile — no certificates to install, no proxy in the loop.

Capture workerOn the web: a separate process, with an allow-list

The web server never launches a browser itself. A separate worker process replays recorded journey paths against hosts the operator explicitly allows; every redirect and resolved address is checked.

Shared engineIn both: the same analysis

Shape inference, source mapping and the confidence model are the same TypeScript packages on every surface, so identical baseline and candidate captures produce identical findings.

04Run the same analysis in CI

Both apps use the engine the fcg CLI runs, so a pipeline gets the same findings as the app. fcg init writes a default fcg.config.json; the desktop app can export a project’s config so redaction and ignore rules match.

CI pipelineBoth

$ fcg compare \
  --baseline captures/baseline.har \
  --candidate captures/candidate.har \
  --src ./src \
  --format md,json,html --out contract-guard \
  --fail-on high --min-confidence medium

Exit code 0: nothing at or above the thresholds. 1: findings at or above them. 2: usage or input error.

05Choosing one

Reach for the desktop app if…

You work alone on one machine and want zero setup
You want captures and analysis to stay fully offline
You want the exact pipeline the CLI and CI use, interactively, with “open in editor”

Reach for the web app if…

You want to reach projects from a browser, including a phone
You’re self-hosting and want each teammate to have their own account
You can run a Node server and point it at a persistent data directory

Was this page helpful?