Responder

Responder investigates production alerts using Sentry, Datadog, Dash0, PostHog, Grafana, Cloudflare, Railway, Axiom, Slack, Upstash, Langfuse, Supabase, and connected MCP servers. It keeps tenant configuration in Postgres, queues work for a separate worker, and runs repository inspection in an isolated sandbox.

This repository contains the web application, API, worker, shared domain code, and database migrations. Hosted-service infrastructure and marketing pages are maintained separately.

What it does

• Watches selected Slack channels, Sentry projects, and Dash0 failed checks for alerts.
• Connects GitHub, Slack, Sentry, Datadog, Dash0, PostHog, Grafana, Axiom, AWS, Google Cloud, Cloudflare, Railway, Upstash, Langfuse, Supabase, Vercel, ClickStack, and custom MCP servers.
• Investigates incidents with a versioned operator-managed runtime profile.
• Produces structured reports, issues, Slack updates, and optional remediation pull requests.
• Separates every organization's data, credentials, resources, and jobs.

Quick start

You need Node.js 24 or newer, pnpm 11, and Docker.

git clone https://github.com/superloglabs/responder-oss.git
cd responder-oss
pnpm local:setup
pnpm local:dev

The setup command installs dependencies, generates a gitignored .env.local, starts Postgres, applies the migrations, and creates a local example runtime profile. The development command prints the local HTTPS address and, when a public tunnel is configured, claims it for the current worktree. Open the dashboard, create an account, and create the first workspace.

The UI and authentication flow work without provider credentials. Set DAYTONA_API_KEY to store workspace secrets or run investigations, and set OPENAI_API_KEY to run investigations. Restart the stack after changing .env.local. Agents using initial triage reactions also require an AI_GATEWAY_API_KEY for Jev through Vercel AI Gateway. The same key funds automation runs that use included usage rather than an organization's own model key, and writes each workspace's suggested automation templates every morning. See .env.example for all configuration.

Provider OAuth and webhooks require a public HTTPS origin. The local tunnel workflow is documented in docs/integrations.md.

Stop the stack without deleting its database:

pnpm local:down

Repository layout

apps/control-plane  React application and Hono API
apps/worker         Investigation and remediation worker
packages/core       Database, security, provider, and queue logic
drizzle             Versioned Postgres migrations
scripts             Isolated local-development tooling

Deployment

Responder is designed as two long-running Node.js services backed by one Postgres database:

1. Build and serve apps/control-plane/dist at your public origin.
2. Route /api/* and /.well-known/* on that origin to the control-plane service.
3. Run the worker with the same database and encryption configuration.
4. Apply every migration in drizzle/ before starting a new release.
5. Store all credentials in your deployment's secret environment.

The included control-plane and worker Dockerfiles are generic building blocks; networking, database hosting, TLS, backups, and release automation are left to the operator. See docs/architecture.md for service and security boundaries.

Management API and MCP

Workspace API keys, created under Settings → API keys, authenticate a REST API at /api/v1 and a remote MCP server at /api/mcp. Both manage automations, runs, tag mode, model access, and workspace secrets. When telemetry is enabled, they also read the workspace's logs, traces, and metrics and manage its dashboards. MCP clients can also connect with OAuth: they register themselves, and the person signs in and chooses a workspace at /oauth/authorize. The OpenAPI document is served at /api/v1/openapi.json; pnpm -s api:openapi prints it.

Development

To populate a running local installation, first create a local account, then run:

pnpm --filter @responder/core exec node scripts/local-seed-demo.mjs your-local-email@example.com

Select Demo workspace in the app. The seed adds three paused investigation agents, one internal scan agent, six issues (one archived), six completed investigations with evidence and remediations, three suggestions, and two completed scans. Re-running it preserves edits and avoids duplicate records. It requires a loopback database and reads .env.local when DATABASE_URL is unset. The demo Slack account and channels are fixtures without credentials; real investigation runs and external actions require real integrations. No jobs or outbound messages are created by the seed.

Run the complete validation suite before opening a pull request:

pnpm typecheck
pnpm lint
pnpm test
pnpm build

For schema changes, run pnpm db:generate, inspect the generated SQL, and test the migrations against a fresh database.

Security

Please report vulnerabilities privately. See SECURITY.md.

Contributing

Contributions are welcome. See CONTRIBUTING.md and CODE_OF_CONDUCT.md.

License

Responder is licensed under the Apache License 2.0. The Inter font is distributed under the SIL Open Font License; see THIRD_PARTY_NOTICES.md. Product and provider names and logos are governed separately; see TRADEMARKS.md.

Runtime investigation guidance

Each runtime profile stores system_prompt and a prompt_parts JSON object. The worker selects the applicable prompt sections for the connected sources and execution mode, renders context placeholders once, and records the assembled instructions in the investigation trace. Defaults live in packages/core/src/investigations/prompt-parts.ts; the database schema snapshots these defaults for profiles. An omitted key falls back to the worker default; an explicit empty string suppresses that section. Changing default sections also requires updating the database default through a migration.

For ordinary investigations and issue follow-ups, the default guidance requires attempting a code remediation. External action is reserved for remediation that is impossible in code and requires human intervention. PR policy controls later publication of the saved diff, not whether the investigation can prepare it. Observation-only scans and ad-hoc Slack threads retain their separate execution restrictions; configurable wording does not change tool permissions.

In organizations with simplified navigation, Slack threads work as a general assistant. They use the assistant* prompt sections in place of the runtime system prompt and the investigation sections. They can open pull requests in the repositories selected for tag mode. They can also read and change the workspace's automations and tag mode settings, saving those changes as the member who last saved tag mode, or else the oldest owner. Automation runs in these organizations get the same workspace tools through their sandbox tool server. They save changes as the member who saved the run's automation version, or else the oldest owner, and are told not to change the workspace because a trigger payload asks.

Linear mentions and delegated issues run as tag mode turns in a Linear agent session. They use the linear* prompt sections in place of the Slack wording, and the same assistant or investigation sections as Slack threads.