# LogBrew docs Choose the app or framework, create a project in Add Project, and verify the first signal before moving into CLI and dashboard references. # Choose platform Start with the app or framework that matches your project. Use the same choice in Add Project. ## Node.js service Use the Node.js package when a backend service needs logs, request spans, actions, releases, and metrics. ```bash npm install @logbrew/sdk @logbrew/node ``` Next: Use the Node first-signal path ## Express service Use the Express package when a Node service handles requests through Express middleware. ```bash npm install @logbrew/sdk @logbrew/express express ``` Next: Open Add Project ## Fastify service Use the Fastify package when a Node service handles routes through Fastify plugins. ```bash npm install @logbrew/sdk @logbrew/fastify fastify ``` Next: Open Add Project ## JavaScript app Use the JavaScript browser package for frontend pages that emit product actions, logs, and lightweight client signals. ```bash npm install @logbrew/sdk @logbrew/browser ``` Next: Open Add Project ## Next.js app Use the Next.js package when routes, server rendering, and client actions need one setup path. ```bash npm install @logbrew/sdk @logbrew/next next react react-dom ``` Next: Open Add Project ## React app Use the React package for component-driven web apps that send user actions and UI state. ```bash npm install @logbrew/sdk @logbrew/react react ``` Next: Open Add Project ## Angular app Use the Angular package when framework routing and app errors should share one setup path. ```bash npm install @logbrew/sdk @logbrew/angular @angular/core ``` Next: Open Add Project ## Vue app Use the Vue package for Vue apps that need clear product actions and browser-side signals. ```bash npm install @logbrew/sdk @logbrew/vue vue ``` Next: Open Add Project ## Svelte app Use the Svelte package for Svelte apps that need a direct SDK install path. ```bash npm install @logbrew/sdk @logbrew/svelte svelte ``` Next: Open Add Project ## NestJS service Use the NestJS package when a Node service is organized around Nest modules and request handling. ```bash npm install @logbrew/sdk @logbrew/nestjs @nestjs/common @nestjs/core @nestjs/platform-express reflect-metadata rxjs ``` Next: Open Add Project ## Python service Start with the core package for Python workers and services. ```bash python3 -m pip install logbrew-sdk ``` Next: Open Add Project ## Django app Use the Django package for request and app signals from a Django project. ```bash python3 -m pip install logbrew-sdk logbrew-django ``` Next: Open Add Project ## FastAPI service Use the FastAPI package for Python APIs with explicit request spans and actions. ```bash python3 -m pip install logbrew-sdk logbrew-fastapi ``` Next: Open Add Project ## .NET service Install the .NET package when a service owns server-side signals. ```bash dotnet add package LogBrew ``` Next: Open Add Project ## ASP.NET Core app Use the ASP.NET Core package when .NET request handling and web app signals need one setup path. ```bash dotnet add package LogBrew.AspNetCore ``` Next: Open Add Project ## Java service Use the JVM package for Java services that need app-owned logs, request spans, and product actions. ```bash implementation("co.logbrew:logbrew-sdk:0.1.0") ``` Next: Open Add Project ## Go service Add the Go package when a service owns explicit logs, spans, metrics, and trace context. ```bash go get github.com/LogBrewCo/sdk/go/logbrew@v0.1.3 ``` Next: Open Add Project ## PHP app Use Composer for PHP services and app-owned request signals. ```bash composer require logbrew/sdk ``` Next: Open Add Project ## Ruby service Use the Ruby gem for Ruby services that need explicit app and request signals. ```bash gem install logbrew-sdk ``` Next: Open Add Project ## Rust service Add the Rust crate for services that build their own logs, spans, actions, and metrics. ```bash cargo add logbrew ``` Next: Open Add Project ## iOS app Use the Apple platform package for iOS apps that send explicit product signals. ```bash .package(url: "https://github.com/LogBrewCo/sdk.git", from: "0.1.1") ``` Next: Open Add Project ## Android app Use the Android package for apps that send app-owned signals from the Android runtime. ```bash implementation("co.logbrew:logbrew-kotlin:0.1.0") ``` Next: Open Add Project ## React Native app Use the React Native package for mobile apps that share JavaScript product actions. ```bash npm install @logbrew/sdk @logbrew/react-native react react-native ``` Next: Open Add Project ## Unity app Use the Unity package for games or simulations that send product actions and runtime signals. ```bash "co.logbrew.unity": "file:../Packages/co.logbrew.unity" ``` Next: Open Add Project ## C app Use the C sources for native services or embedded apps that need direct signal control. ```bash cc -std=c99 -Wall -Wextra -Wpedantic -Iinclude src/logbrew.c src/logbrew_metric.c src/logbrew_recording_transport.c src/logbrew_timeline.c src/logbrew_trace.c your_app.c -o your_app ``` Next: Open Add Project ## C++ app Run the released CLI plan in a CMake 3.16+ C++17 project. Link LogBrew::LogBrew. Enable LogBrew::HttpTransport and libcurl only when hosted delivery is required. ```bash logbrew setup --json ``` Next: Open Add Project ## Setup path at a glance Use this order to move from docs to a verified product action without leaving the setup flow. - Install. Add package: Start with the SDK package for your runtime. - Create. Create project: Open Add Project for the one-time project credential. - Send. Send one product action: Run one non-secret product action before wiring the app. - Verify. Check logs: Confirm the signal in logs or with the CLI. # First successful SDK run Keep the first session tight: install the package, create the project, send one non-secret product action, then confirm it in LogBrew. ## First-signal setup needs Direct SDK ingestion keeps the setup path short. - Collector: No local agent. Install the SDK package and send directly to the LogBrew API. - Credential: One project credential. Copy it from Add Project only when creating or setting up that project. - Proof: Verify in logs. Send one info signal, then confirm it before wider instrumentation. ## AI assistant context Give an agent the public LogBrew map before it edits your app or setup command. ```bash curl -L https://logbrew.co/llms.txt ``` ### installation prompt ```bash Read https://logbrew.co/llms.txt, then choose the matching SDK card at https://logbrew.co/en/docs#docs-sdk-choice-title. Use npm install @logbrew/sdk @logbrew/node only for a server-side Node.js service; for Next.js, React, iOS, Android, or React Native, use the selected card and Add Project prompt. Ask the signed-in user to open Add Project and place credentials only in the matching app environment. For server-side Node.js, the env var is LOGBREW_SERVER_API_KEY. Run node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs only for Node services, then verify with logbrew logs info --json. Do not ask for credentials in chat or commits. ``` Next: Open agent guide ## Install SDK Use the Node packages for a backend service that needs logs, spans, actions, releases, and metrics. ```bash npm install @logbrew/sdk @logbrew/node ``` ## Create project Open Add Project, choose a platform, and copy the one-time ingest credential from the setup panel. Next: Open Add Project ## Send one product action Run the packaged example before wiring production code so the first shape is known and token-free. ```bash node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs ``` ## Verify in LogBrew Read the first info signal in logs before adding more instrumentation. ```bash logbrew logs info --json ``` # Send the first Node SDK signal to LogBrew Use this Node path when you want live project data, not another setup article. The dashboard creates the project and shows the one-time credential; the public docs keep the package and verification steps safe. ## Add the JavaScript SDK packages Start with the core SDK and Node helper when a backend service needs logs, request spans, actions, releases, and metrics. ```bash npm install @logbrew/sdk @logbrew/node ``` ## Create the project from Add Project Sign in, open Add Project, choose a platform, and copy the one-time ingest credential from that setup panel. The website does not repeat it after you leave. ## Run the first SDK signal example Use the installed package example to inspect the release, environment, request span, product action, network milestone, and metric shape before wiring your app. ```bash node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs ``` ## Read the first signal in LogBrew After the SDK sends an info signal with the project credential, use the CLI or dashboard logs view to confirm it arrived before adding more instrumentation. ```bash logbrew logs info --json ``` # Choose your path ## Check whether LogBrew is ready Run status first to confirm reachability, login state, and the next safe read. ```bash logbrew status --json ``` ## Start from the latest failures Read recent error logs, then move into issues or traces when a release or project needs context. ```bash logbrew logs error --json ``` ## Share a stable issue view List open issues when a teammate needs the same failure groups. ```bash logbrew issues open --json ``` # Command map ## Status Check local auth, API reachability, and recovery steps before any private read. ```bash logbrew status --json ``` ## Logs Start with recent errors when a release, project, or trace needs context. ```bash logbrew logs error --json ``` ## Issues List open failure groups before deciding whether to resolve, close, ignore, or reopen. ```bash logbrew issues open --json ``` ## Trace detail Read a known trace id when logs or issues point to one failing request. ```bash logbrew trace --json ``` ## Actions Filter user events by name when the important context is a product action. ```bash logbrew actions --name checkout_failed --json ``` ## Releases Compare rollout context with log, issue, trace span, and action counts. ```bash logbrew releases --json ``` ## Check local auth and API reachability The first read should tell you whether the CLI can reach the LogBrew API without exposing token material. - Use JSON mode when a script or automation needs stable fields. - Use human output when a developer needs the next command. - Keep auth recovery pointed back to login and status. ## Read production signals by resource Logs, issues, actions, traces, releases, and projects should stay separated enough to scan quickly and connected enough to recover context. - Logs keep severity, release, environment, project, trace, and search filters. - Issues keep status, trace context, and mutation vocabulary. - Traces keep span names, release context, environment context, and project scope. ## Send useful context without exposing project data Use public docs, Markdown, and copyable commands when someone needs setup help or a safe handoff. - Share a docs link when the next step is setup or command discovery. - Share Markdown when plain text is easier than a screenshot. - Keep dashboard project data behind login and backend auth. ## Match the dashboard to backend routes The web workspace should follow documented LogBrew API contracts instead of inventing dashboard-only storage or alternate contracts. - Logs read from /api/logs with severity, release, environment, project, trace, and search filters. - Issues read and mutate through /api/telemetry/issues and /api/telemetry/issues/{issue_id}. - Actions, releases, and trace detail read through /api/telemetry/actions, /api/telemetry/releases, and /api/telemetry/traces/{trace_id}. - Projects and auth state come from /api/projects, /api/auth, and CLI status commands. ## Public agent links - Full docs site: https://docs.logbrew.co - Docs: https://logbrew.co/en/docs - Docs Markdown: https://logbrew.co/en/docs.md - Agent guide: https://logbrew.co/en/agents - Home Markdown: https://logbrew.co/en/page.md - llms.txt: https://logbrew.co/llms.txt - Sitemap: https://logbrew.co/sitemap.xml