devkitshq/notifkit: The notification infra of your business

The notification infra of your business

Summary

notifkit is a self-hosted TypeScript service that delivers product notifications (email, SMS, push, webhooks, Slack, Telegram, Discord, WhatsApp) through one typed API call. It packages the surrounding machinery most teams end up writing by hand: preferences, quiet hours, retries, fallback channels, scheduling, multi-step workflows, and delivery logs. It runs on Node 22+ with PostgreSQL and Redis, and exposes both a typed Node SDK and a standard REST API.

What it is useful for

Teams that want to stop hand-rolling notification plumbing. Instead of wiring Resend, Twilio, and Firebase separately and writing preference, dedup, and retry code in every service, the application makes a single notifkit.notify() call. The server resolves the user, applies preferences and quiet hours, picks a channel, falls back on failure, retries, logs delivery, and exposes a built-in admin dashboard at /admin for live feeds, DLQ triage, queue metrics, and template editing.

It also fits AI-agent workflows. The @notifkit/mcp package exposes the same surface to MCP-compatible tools so an agent can send notifications, inspect delivery logs, manage templates, trigger workflows, and replay dead letters.

The README is explicit about scope: this is the durable notification layer for product notifications, not a marketing automation suite, and it is positioned as a self-hosted alternative to, not a replacement for, Customer.io, OneSignal, or SendGrid. You bring your own provider accounts and pay them directly.

How engineers can use it

The README's documented local quickstart:

1. Install: npm install notifkit @notifkit/provider-resend (plus npm install -D tsx @testcontainers/postgresql @testcontainers/redis for dev).
2. Start the server. In development it spins up throwaway PostgreSQL and Redis containers, so Docker is the only prerequisite:

   const server = new NotifkitServer({
     services: ["all"],
     port: 3000,
     providers: [new ResendTransport({ apiKey: process.env.RESEND_API_KEY!, from: "[email protected]" })],
   });
   await server.start();
   

3. Mint a project API key with npx notifkit-create-project "my-app". The nk_live_… value is printed once; the server stores only its SHA-256 hash.
4. Register a template, register a user, and call notifkit.notify({ user, template, channels, data }).
5. Any non-Node client can POST /v1/notify with the same project key in Authorization or x-api-key.

For production, the README requires real PostgreSQL and Redis, NODE_ENV=production, and migrations run via drizzle-kit against node_modules/notifkit/drizzle. For horizontal scale, the documented topology splits services: ["api"] from worker pools (["enricher", "engine", "delivery", "scheduler"]) over Redis Streams consumer groups. Reliability features (24-hour idempotency, sliding-window rate limits, circuit breakers, DLQ replay) are documented as tested with real testcontainers.

Documented limitations: only the listed first-party transports (Resend, FCM, Slack, Twilio, Telegram, Discord, WhatsApp, Console) ship out of the box; anything else requires implementing a Transport class with a send() method, and operational details beyond the quickstart live in the project's documentation site.