Local-Only Mode
Run DebugBundle where your SDK writes files, with no DebugBundle Cloud dependency.
Local-only mode processes events, generates incidents, and builds debug bundles on the machine or storage volume where the SDK writes files and the CLI runs. No data is sent to DebugBundle Cloud, no account is required, and no hosted service is needed.
When to Use Local-Only
- Solo development — you're the only developer on the project
- Air-gapped environments — network access is restricted
- Self-managed servers — operators can install the CLI and keep
.debugbundle/on persistent storage - Evaluation — trying DebugBundle before connecting to cloud
- Privacy-sensitive projects — data must not leave the machine
- Offline work — no internet available
Setup
Initialize your project in local-only mode (the default):
debugbundle setupThis creates .debugbundle/local/connection.json with:
{
"mode": "local-only",
"cloud_project_id": null,
"cloud_base_url": null,
"environments": {
"local": { "delivery": "local-only" },
"development": { "delivery": "local-only" },
"staging": { "delivery": "local-only" },
"production": { "delivery": "local-only" }
}
}Workflow
1. Capture Events
Run your application with an SDK configured. Events are written as event batch files to
.debugbundle/local/events/:
# Or ingest log files directly
debugbundle ingest ./logs/app.log --format debugbundle-ndjson2. Process Events
Process captured events into incidents and bundles:
debugbundle processThis runs the full pipeline locally: normalize, fingerprint, group into incidents, and generate debug bundles.
Self-Managed Server Workflow
Local-only can run on a production or staging server you control, but the workflow is server-local:
- Install the SDK in local-only/file-transport mode on the server.
- Install the CLI on the same server, or mount/sync
.debugbundle/to a machine where the CLI can run. - Keep
.debugbundle/local/events/,.debugbundle/local/state.json, and.debugbundle/bundles/local/on persistent storage if the runtime is containerized. - Run
debugbundle processthere to generate bundles. - Let your agent inspect incidents through the local CLI, MCP local tools, or the generated bundle files.
This gives you DebugBundle's core workflow without DebugBundle Cloud. Hosted cloud is still the recommended path when you need centralized production visibility, alerts, webhooks, remote probes, team access, or durable retention for ephemeral infrastructure.
3. View Incidents
debugbundle incidents --source local4. Inspect Bundles
debugbundle inspect inc_local_01H...5. Watch for New Events
Monitor a log file and process events as they arrive:
debugbundle watch ./logs/app.log --format debugbundle-ndjsonLocal Storage Layout
| Path | Purpose |
|---|---|
.debugbundle/local/events/ | Raw event batch files captured locally |
.debugbundle/local/events/<timestamp>_batch_<n>.ndjson | Individual local event batches written by the SDK or CLI |
.debugbundle/local/state.json | Grouped local incident state and processing metadata |
.debugbundle/bundles/local/ | Generated local debug bundles |
.debugbundle/bundles/local/reproductions/ | Generated local reproduction artifacts |
Limitations
| Capability | Local-Only | Connected |
|---|---|---|
| Event capture | Yes | Yes |
| Incident grouping | Yes | Yes |
| Bundle generation | Yes | Yes |
| Reproduction artifacts | Yes | Yes |
| Team visibility | No | Yes |
| Dashboard | No | Yes |
| Webhooks | No | Yes |
| Alerts | No | Yes |
| Probes | No | Yes |
| Weekly reports | No | Yes |
Upgrading to Connected Mode
When you're ready for team features, run:
debugbundle connectSee Connect to Cloud for the full flow.
Your local investigation artifacts remain available under .debugbundle/local/.
Next Steps
- Project Setup — Setup overview
- Connect to Cloud — Enable cloud features
- CLI Local Workflow — Full local CLI workflow