Lohnt sich dein eigenes Svix?
Verwalteter Versand ausgehender Webhooks mit Wiederholungsversuchen, Signierung, Protokollen und einem Kundenportal.
Der Kernablauf ist hier tatsächlich klein: ein Ereignis annehmen, abonnierte Endpunkte nachschlagen, die Nutzdaten signieren, per POST senden, bei Fehlern mit wachsenden Wartezeiten erneut versuchen und den Versuch protokollieren. Ein Agent erstellt das in einer Sitzung, und für ein einzelnes Produkt mit ein paar Tausend Ereignissen pro Tag funktioniert es gut. Was bei einem einzigen Anlauf nicht einfach mitgeliefert wird, ist die unspektakuläre Hälfte: eine Warteschlange, die Neustarts übersteht, Ratenbegrenzung und Circuit Breaking pro Endpunkt, damit ein ausgefallener Kunde nicht deinen Worker-Pool lahmlegt, Werkzeuge zur erneuten Zustellung und für manuelle Wiederholungsversuche, ein Portal, in das sich deine Kunden einloggen können, und Signaturverfahren, die Drittanbieter-Bibliotheken bereits verstehen. Svix ist außerdem Open Source, weshalb es beim DIY oft ehrlicher ist, deren Lösung selbst zu hosten, als eine eigene zu schreiben. Rechne mit einem Wochenende für etwas, das du zahlenden Nutzern tatsächlich anbieten würdest, und sei dir bewusst, dass du dafür jetzt Bereitschaftsdienst hast.
EN → DERecherche automatisch aus dem Englischen übersetzt. Original-Prompt auf Englisch beibehalten.
Build a self-hosted outbound webhook delivery service. Single Node.js project, TypeScript, Fastify for HTTP, Postgres via Drizzle ORM, BullMQ on Redis for the delivery queue. Docker Compose for Postgres and Redis. No cloud accounts, no telemetry, no auth provider: a single static API key in .env guards the admin and ingest routes.
Data model:
- applications: id, name, created_at (one per tenant/customer of mine)
- endpoints: id, application_id, url, description, secret, enabled, event_types (text array, empty means all), created_at
- messages: id, application_id, event_type, payload jsonb, created_at
- attempts: id, message_id, endpoint_id, attempt_number, status_code, response_body_excerpt, error, duration_ms, created_at
HTTP API (all JSON, all behind the API key header):
- POST /api/applications, GET /api/applications
- POST /api/applications/:id/endpoints, GET, PATCH, DELETE
- POST /api/applications/:id/messages: body has event_type and payload. Persist the message, resolve matching enabled endpoints, enqueue one delivery job per endpoint, return the message id with 202.
- GET /api/messages/:id/attempts
- POST /api/attempts/:id/replay: re-enqueue that single delivery immediately.
Delivery worker:
- POST the raw JSON payload with headers: webhook-id, webhook-timestamp (unix seconds), webhook-signature as "v1," plus base64 HMAC-SHA256 over "{id}.{timestamp}.{body}" using the endpoint secret.
- 5 second connect timeout, 10 second total timeout.
- Success is any 2xx. Retry on everything else with backoff: 5s, 30s, 5m, 30m, 2h, 5h, then give up and mark the endpoint as failing.
- Record an attempt row for every try, truncating response bodies to 2KB.
- Rate limit per endpoint to 20 concurrent deliveries max using a BullMQ group or per-endpoint limiter.
Also build a minimal server-rendered admin UI at / using Fastify plus plain HTML templates and no frontend framework: list applications, list endpoints, list recent messages, drill into a message to see attempts and hit replay. Ugly is fine, tables and buttons only.
Out of scope: a customer-facing self-serve portal, per-customer login, multi-region, event type schema validation, inbound webhook receiving, transformations.
Include a README with docker compose up, migration command, and one curl example that creates an application, an endpoint pointing at a local sink, and sends a message. Add a small script that runs a throwaway HTTP sink on port 4000 that verifies the signature and prints the payload, so delivery can be tested end to end. Write integration tests for signature generation and for the retry backoff schedule.Der Prompt öffnet sich vorausgefüllt in deinem Agenten. Prüfe ihn vor dem Ausführen. · dieser Prompt wurde aus dem Bauplan erzeugt · per PR verbessern
Wie sähe deine eigene Version aus?
Nimmt ein Ereignis über eine API entgegen, verteilt es mit HMAC-signierten Nutzdaten an registrierte Endpunkte, wiederholt fehlgeschlagene Versuche mit exponentiell wachsenden Wartezeiten und protokolliert jeden Versuch.
Was du brauchst
- Eine Postgres-Datenbank
- Redis oder eine auf Postgres basierende Job-Warteschlange
- Ein dauerhaft laufender Server, keine Serverless-Funktion
- Ein Speicherort für Zustellprotokolle, die schnell anwachsen
Bei der Webhook-Zustellung stecken alle Fehlerfälle in den Ausnahmen: der Kunde, dessen Endpunkt 200 zurückgibt, aber den Inhalt verwirft, der Kunde, dessen Endpunkt sechs Stunden lang ausfällt, oder die Lastspitze, bei der fünfzigtausend Zustellungen hinter einem einzigen Timeout in der Warteschlange landen. Den reibungslosen Ablauf zu schreiben dauert einen Nachmittag. Diese Ausnahmefälle zu entdecken und abzufangen erfordert Monate an Produktionsverkehr, den du noch nicht erlebt hast. Teams zahlen, damit ausgehende Webhooks sie nicht mehr beschäftigen müssen und damit bei einer Kundenbeschwerde über ein fehlendes Ereignis ein durchsuchbares Protokoll und eine Schaltfläche zur erneuten Zustellung bereitstehen, statt dass sie Anwendungsprotokolle mit grep durchsuchen müssen.
xEin Kundenportal, in dem deine Nutzer ihre eigenen Endpunkte verwalten und Fehler einsehen
xEin praxiserprobtes Signaturformat, das bestehende Verifizierungsbibliotheken direkt akzeptieren
xCircuit Breaking und Ratenbegrenzung pro Endpunkt, damit ein langsamer Empfänger nicht alle anderen aufhält
xBetriebliche Reife: Umgang mit dauerhaft fehlgeschlagenen Nachrichten, Zeitfenster für erneute Zustellung, Durchsatz bei Lastspitzen
xDass jemand anderes alarmiert wird, wenn die Zustellung um 3am ausfällt
Nichts, worauf sich verweisen ließe. Deshalb gibt es den Prompt.
Was kostet Svix?
- Monatliche Zahlung
- 490 $/Mon.490 $/Mon.
- Pro Jahr
- 5.880 $/Jahr5.880 $/Jahr
- Mit brasilianischer Karte, inkl. 3,5% IOF
- 2.561 R$/Mon.30.727 R$/Jahr
In Meine Liste gespeichert. Bei einer Preisänderung erscheint hier ein Hinweis.
Du schließt den Kauf auf der Website von Svix ab. Vibe Radar wickelt keine Zahlungen ab.
Svix selbst bauen oder abonnieren?
Passe die Zahlen an: Stunden zum Bauen, dein Stundensatz, Betriebskosten und der Abopreis.
Selbst bauen lohnt sich nach 2 Monaten.
Startwerte aus der Analyse geschätzt (ein Wochenende). Nicht eingerechnet ist, was dir fehlt (Support, Integrationen, Sicherheit).
Kann ich Svix nachbauen?
Teilweise. Den Kern von Svix baust du mit dem Prompt auf dieser Seite an einem Wochenende, aber es gibt echte Lücken: Ein Kundenportal, in dem deine Nutzer ihre eigenen Endpunkte verwalten und Fehler einsehen, Ein praxiserprobtes Signaturformat, das bestehende Verifizierungsbibliotheken direkt akzeptieren. Lies die Liste oben, bevor du loslegst.
Was kostet Svix?
Svix kostet etwa 490 $/Mon. (Professional, geprüft am 20.10.2026), also 5.880 $ pro Jahr.
Was fehlt mir, wenn ich Svix ersetze?
Ehrlich gesagt: Ein Kundenportal, in dem deine Nutzer ihre eigenen Endpunkte verwalten und Fehler einsehen; Ein praxiserprobtes Signaturformat, das bestehende Verifizierungsbibliotheken direkt akzeptieren; Circuit Breaking und Ratenbegrenzung pro Endpunkt, damit ein langsamer Empfänger nicht alle anderen aufhält; Betriebliche Reife: Umgang mit dauerhaft fehlgeschlagenen Nachrichten, Zeitfenster für erneute Zustellung, Durchsatz bei Lastspitzen; Dass jemand anderes alarmiert wird, wenn die Zustellung um 3am ausfällt. Wenn dir davon etwas wichtig ist, zahl weiter.
Gibt es eine Open-Source-Alternative zu Svix?
Es gibt keine ausgereifte Open-Source-Alternative, auf die sich verweisen ließe, und genau deshalb gibt es den Prompt auf dieser Seite.