Faut-il créer votre propre Svix ?
Envoi géré de webhooks sortants avec nouvelles tentatives, signature, journaux et portail client.
Le fonctionnement essentiel est vraiment réduit : accepter un événement, rechercher les points de terminaison abonnés, signer la charge utile, l’envoyer par POST, réessayer en cas d’échec avec des délais croissants et journaliser la tentative. Un agent produira cela en une session, et pour un seul produit envoyant quelques milliers d’événements par jour, cela fonctionnera très bien. Ce qu’une seule génération ne fournit pas, c’est la moitié fastidieuse : une file qui survit aux redémarrages, une limitation du débit et un coupe-circuit par point de terminaison pour qu’un client hors service ne bloque pas votre groupe de workers, des outils de rejeu et de relance manuelle, un portail auquel vos clients peuvent se connecter et des schémas de signature déjà compris par les bibliothèques tierces. Svix est aussi open source : la démarche maison la plus honnête consiste donc souvent à auto-héberger leur solution plutôt qu’à écrire la vôtre. Comptez un week-end pour quelque chose que vous présenteriez réellement à des utilisateurs payants, en sachant que vous en assurez désormais l’astreinte.
EN → FRAnalyse traduite automatiquement de l’anglais. Prompt original conservé en anglais.
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.Le prompt s’ouvre prérempli dans votre agent. Relisez-le avant de l’exécuter. · ce prompt est généré à partir du plan de construction · améliorez-le via une PR
Comment créer votre propre version ?
Reçoit un événement via API, le distribue aux points de terminaison enregistrés avec des charges utiles signées HMAC, réessaie les échecs avec un délai exponentiel et enregistre chaque tentative.
Ce dont vous aurez besoin
- Une base de données Postgres
- Une file de tâches reposant sur Redis ou Postgres
- Un serveur qui reste en fonctionnement, pas une fonction serverless
- Un emplacement pour stocker les journaux de tentatives, dont le volume augmentera rapidement
L’acheminement des webhooks est un système dont les modes de défaillance se cachent tous dans les cas limites : le client dont le point de terminaison renvoie 200 mais perd le corps du message, celui qui tombe en panne pendant six heures, le pic de trafic qui met cinquante mille envois en attente derrière une seule expiration de délai. Écrire le parcours sans incident prend un après-midi. Découvrir et gérer ces cas limites demande des mois de trafic en production que vous n’avez pas encore connus. Les équipes paient pour ne plus avoir à penser aux webhooks sortants et pour disposer, lorsqu’un client signale un événement manquant, d’un journal consultable et d’un bouton de rejeu plutôt que d’un grep dans les journaux de l’application.
xUn portail client où vos utilisateurs gèrent leurs propres points de terminaison et consultent les échecs
xUn format de signature éprouvé, accepté d’emblée par les bibliothèques de vérification existantes
xUn coupe-circuit et une limitation du débit par point de terminaison pour qu’un destinataire lent ne bloque pas tout le monde
xLa maturité opérationnelle : gestion des messages en échec définitif, fenêtres de rejeu, débit pendant un pic
xQuelqu’un d’autre qui reçoit l’alerte lorsque l’acheminement tombe en panne à 3am
Rien qui mérite d’être cité. C’est pour cela que le prompt existe.
Combien coûte Svix ?
- Facturation mensuelle
- 490 $US/mois490 $US/mois
- Par an
- 5 880 $US/an5 880 $US/an
- Avec une carte brésilienne, IOF de 3,5% inclus
- 2 561 R$/mois30 727 R$/an
Enregistré dans Ma liste. Un avis s’affichera ici si le prix change.
Vous finalisez l’achat sur le site de Svix. Vibe Radar ne gère aucun paiement.
Construire ou s’abonner à Svix ?
Ajustez les chiffres : heures de développement, taux horaire, coûts d’exploitation et prix de l’abonnement.
Construire est rentabilisé en 2 mois.
Heures estimées d’après l’analyse (un week-end). Ne chiffre pas ce que vous perdez (support, intégrations, sécurité).
Puis-je recréer Svix ?
En partie. Le cœur de Svix se construit en un week-end avec le prompt de cette page, mais il reste de vraies lacunes : Un portail client où vos utilisateurs gèrent leurs propres points de terminaison et consultent les échecs, Un format de signature éprouvé, accepté d’emblée par les bibliothèques de vérification existantes. Lisez la liste ci-dessus avant de vous lancer.
Combien coûte Svix ?
Svix coûte environ 490 $US/mois (Professional, vérifié le 20/10/2026), soit 5 880 $US par an.
Que perd-on en remplaçant Svix ?
Honnêtement : Un portail client où vos utilisateurs gèrent leurs propres points de terminaison et consultent les échecs; Un format de signature éprouvé, accepté d’emblée par les bibliothèques de vérification existantes; Un coupe-circuit et une limitation du débit par point de terminaison pour qu’un destinataire lent ne bloque pas tout le monde; La maturité opérationnelle : gestion des messages en échec définitif, fenêtres de rejeu, débit pendant un pic; Quelqu’un d’autre qui reçoit l’alerte lorsque l’acheminement tombe en panne à 3am. Si l’un de ces points compte pour vous, continuez à payer.
Existe-t-il une alternative open source à Svix ?
Aucune alternative open source mature à recommander, et c’est précisément pour cela que le prompt de cette page existe.