Responder

Responder investigates production alerts using Sentry, Datadog, Axiom, Slack, Upstash, Langfuse, 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 and Sentry projects for new alerts.
• Connects GitHub, Slack, Sentry, Datadog, Axiom, AWS, Upstash, Langfuse, 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. 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/* 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.

Development

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.