Laudspeaker

Laudspeaker is an open-source customer engagement and product onboarding platform, positioned as a self-hostable alternative to Braze, Customer.io, OneSignal, Appcues, and Pendo. It is built as an npm-workspace monorepo with a NestJS/TypeScript API (packages/server) and a React client (packages/client), and its core job is letting product and growth teams design multi-step, branching customer journeys on a visual canvas and then fire the right message on the right channel at the right point in that journey.

At the center of the system is a journey engine modeled as a durable state machine: dedicated step processors handle message sends, time delays, time windows, conditional jumps, A/B experiments, and multi-way splits, while a JourneyLocation record tracks exactly where each customer currently sits inside a running journey. Execution is queue-driven, combining BullMQ with a custom RabbitMQ connection and queue-manager layer, and Redis-backed distributed locks coordinate multiple worker processes so the same customer doesn’t get double-messaged. Customer and event data lives in PostgreSQL for transactional state and ClickHouse for high-volume event analytics, with Redis handling caching and locking.

On the messaging side, Laudspeaker ships direct integrations for email (SendGrid, Mailgun, Resend), SMS (Twilio), push notifications (Firebase), Slack, and generic webhooks, plus a segment builder for targeting customers by attributes and tracked events, Liquid-based message personalization, and native support for ingesting PostHog-formatted events as journey triggers. The client is a Create React App build using Redux Toolkit for state and React Flow for the visual journey and segmentation canvases.

The codebase is AGPL-3.0 licensed, with an ee/ (Enterprise Edition) directory reserved for a separate Laudspeaker Enterprise License — that directory is currently empty, so no code today is gated behind a license key. The company also offers a hosted Laudspeaker Cloud and sells a paid, sales-assisted enterprise self-hosted plan. Recent commit activity has slowed relative to the project’s earlier releases, so evaluate current maintenance cadence before betting production messaging infrastructure on it.

What You Get

• A visual drag-and-drop journey builder (React Flow) for designing branching, multi-step customer messaging flows without writing orchestration code.
• Omnichannel message delivery out of the box: email via SendGrid/Mailgun/Resend, SMS via Twilio, push via Firebase, Slack messages, and webhooks, all triggered from the same journey engine.
• A dynamic segment and attribute builder for targeting customers by profile properties and tracked event history.
• Built-in A/B experiment and multi-split step types for testing messaging variants directly inside a journey.
• A durable, crash-safe execution model — BullMQ plus a custom RabbitMQ queue layer and Redis-backed locks track exactly where each customer is in a journey and prevent duplicate sends.
• A full self-hosted deployment path via Docker Compose (Postgres, ClickHouse, Redis, RabbitMQ, and the app itself), or a managed Laudspeaker Cloud option.

Common Use Cases

• Building product onboarding journeys that mix in-app checklists, emails, and push nudges to drive new users to activation.
• Running lifecycle and retention campaigns that re-engage customers who haven’t triggered a key event in a defined window.
• Sending event-triggered transactional-style messages (order updates, usage alerts) through a queue-based pipeline instead of custom job infrastructure.
• Self-hosting customer messaging infrastructure to keep customer PII and event data inside a company’s own environment for compliance or data-residency reasons.
• Reusing existing PostHog product-analytics instrumentation directly as journey triggers instead of building a second event pipeline.

Under The Hood

Architecture Laudspeaker is a layered, queue-driven system split into two npm workspaces — a NestJS TypeScript API (packages/server) and a Create React App client (packages/client) — bootstrapped from a single app.module.ts that wires together numerous feature modules (Journeys, Steps, Customers, Segments, Templates, Channels, Webhooks, Organizations, Workspaces) around TypeORM entities. The single Node entry point forks itself via the cluster module and branches on a process-type environment variable into either a web process (Express/Nest HTTP server) or a headless application-context worker, so the same codebase serves both the API and background job runners. The core abstraction is the journey: a journeys service plus dedicated per-step processors (start, message, time delay, time window, wait until, jump, experiment, multisplit, exit) implement a durable state machine, sitting on a custom queue module (processor base classes, a producer, a queue manager, a work orchestrator, and a hand-rolled RabbitMQ connection manager) layered on top of BullMQ, while journey-location records track exactly where each customer sits inside a journey and Redis-backed distributed locking prevents duplicate sends across workers. Changing the step-processor contract or the journey-location tracking model would ripple through nearly every messaging channel and the journey-builder UI, since both depend on the same step and enrollment abstractions.

Tech Stack The backend runs on NestJS conventions over Node/TypeScript, with PostgreSQL as the system of record via TypeORM migrations, ClickHouse for high-volume event and analytics storage, Redis for caching and distributed locking, and RabbitMQ alongside BullMQ for journey and step job queues. Messaging providers are integrated directly: SendGrid, Mailgun, and Resend for email; Twilio for SMS; Firebase Admin for push; Slack’s Web API and OAuth for Slack messages. The React client is a Create React App/webpack build using Redux Toolkit for state management, React Flow for the visual journey and segment-filter canvases, and a mix of MUI, Ant Design, and Material Tailwind for UI, styled partly with Emotion and partly Tailwind CSS. The project ships per-service Dockerfiles and Docker Compose files for local and self-hosted deployment, and integrates Sentry for error tracking alongside PostHog as both an event source and a product-analytics sink.

Code Quality Server-side testing uses Jest with NestJS’s testing-module utilities and hand-built mocks for repositories, cache, and logging, giving the backend an extensive set of spec files across its core services, plus a separate Cypress end-to-end suite and load-test scripts for the API. The client package has no dedicated unit tests of its own. Error handling in core services favors explicit, typed HTTP exceptions with specific status codes rather than silent failures, though catch-block behavior is inconsistent about re-throwing versus just logging. Both workspaces are configured with ESLint and Prettier, and CI workflows run build and test jobs on push and pull request — though the automated test job currently exercises only a limited subset of the full spec suite, with an explicit TODO noting the remaining tests still need their dependencies mocked before they can run reliably in CI, which limits confidence that the full suite is continuously verified.

What Makes It Unique What differentiates Laudspeaker from a generic templated-email tool is that it treats every message as one step inside a stateful, resumable journey graph rather than a one-off campaign: journey-location tracking, dedicated step processors per node type (including native experiment and multisplit steps for branching and A/B logic), and a custom queue layer over BullMQ and RabbitMQ let a single journey definition span long time windows per customer while staying crash-safe and lock-protected. Native support for ingesting PostHog-formatted events is a deliberate choice that lets teams already instrumenting products with PostHog reuse that pipeline directly as journey triggers instead of standing up a second event pipeline. These are genuine engineering choices, but the overall pattern — visual workflow builder plus multi-channel send plus segmentation — mirrors established players like Customer.io, Braze, and OneSignal rather than introducing a fundamentally new category of product.

Self-Hosting

Licensing Model The codebase is licensed AGPL-3.0, with one carve-out: the packages/server/src/ee/ (Enterprise Edition) directory is reserved under a separate “Laudspeaker Enterprise License” rather than AGPL. That directory currently contains only a LICENSE placeholder file and no actual code, so nothing in the shipped repository is presently gated by the enterprise license.

Self-Hosting Restrictions No license-key checks, feature flags, or “isEnterprise”/“isPro” gating logic were found anywhere in the server or client source. Self-hosters running the open-source repository today get the same functionality as anyone else running the same code.

Enterprise Features The README references a paid, sales-assisted “self-deployed (enterprise)” plan available by booking a call with the team, but does not publicly document which specific features that plan includes — none of that is visible in the codebase, so this cannot be enumerated from source alone.

Cloud vs Self-Hosted Laudspeaker offers a managed Laudspeaker Cloud (app.laudspeaker.com) for teams that don’t want to operate the stack themselves. Self-hosting requires running PostgreSQL, ClickHouse, Redis, and RabbitMQ alongside the app via the provided Docker Compose files; no functional gap between cloud and self-hosted is documented in the repository.

License Key Required No. The current open-source codebase contains no license-key enforcement, and the reserved ee/ directory is empty.