Multi-Tenant-Projekte
Projekte pro Nutzer mit Postgres Row-Level Security. Erstelle API-Tokens pro Projekt, jeweils auf einen einzigen Tenant beschränkt — Leaks bleiben innerhalb des Projekts.
Self-hosted · MIT-Lizenz
Reich das Payload weiter. Den Rest übernehmen wir.
Eine schlanke Alternative zu gehosteten QStash-ähnlichen Ingress-Diensten. Multi-Tenant-Queue, HTTP-Auslieferung mit Retries, Cron-Schedules und streng geordnete Message Groups — alles auf deinem eigenen Postgres.
Gebaut für Produktions-Queues
Sechs Primitive. Ein Postgres. Null gehostete Abhängigkeiten.
API-Tokens pro Projekt
Bearer pk_xxx:sk_yyy, bcrypt-gehashed at rest. Beim Erstellen einmal angezeigt, jederzeit aus dem Dashboard widerrufbar.
Einzelne Nachrichten
POST eines HTTP-Jobs: origin, path, method, headers, body, Retries, optional runAt oder delaySeconds, optional idempotencyKey.
Message Groups
Ein origin + viele paths, streng in Reihenfolge ausgeführt. Postgres erzwingt die Reihenfolge der Geschwister zum Claim-Zeitpunkt — übersteht Neustarts und mehrere Worker.
Cron-Schedules
Cron-Ausdruck + Timezone pro Zeile. Ein zentraler Dispatch-Tick reiht fällige Schedules ein; schedule_runs dedupliziert überlappende Worker.
Retries und Backoff
Fehlgeschlagene Versuche wandern nach pending_retry mit Backoff. Nach max_retries: dead. Jeder Versuch wird in delivery_attempts geloggt.
Drei Zeilen HTTP
Funktioniert mit curl, dem SDK oder jedem anderen HTTP-Client.
curl -X POST https://api.passthatpayload.com/api/v1/messages \
-H "Authorization: Bearer pk_xxx:sk_yyy" \
-H "Content-Type: application/json" \
-d '{
"origin": "https://api.example.com",
"path": "/hooks/order-created",
"body": { "orderId": 42 },
"maxRetries": 5
}'Use Cases
Was du sonst selbst bauen müsstest.
Webhook-Fan-out
Nimm ein eingehendes Event und versende es an viele Downstream-URLs, jede mit eigener Retry-Policy. Verliere keine einzige Auslieferung an eine wacklige Drittanbieter-API.
Cron-gesteuerte Workflows
Plane Cron-Ausdrücke pro Zeile. Ein einziger zentraler Dispatch-Tick feuert die fälligen ab — kein OS-Cron pro Schedule, kein Vercel-Cron pro Job.
Streng geordnete HTTP-Pipelines
Soll Schritt 2 auf Schritt 1 warten? Message Groups garantieren die Reihenfolge auf Datenbank-Ebene — auch über mehrere Dispatcher hinweg.
Self-hosted oder die gehostete Edition
Dieselbe Engine, zwei Betriebsarten.
| Feature | Gehostet | Self-host |
|---|---|---|
| Infrastruktur | Läuft auf api.passthatpayload.com — null Ops auf deiner Seite. | Ein Container + Postgres auf deinem eigenen Server. Hetzner-Runbook in der README. |
| Datenhoheit | Gespeichert in unserem gemeinsamen Postgres, pro Projekt via RLS isoliert. | Deine Datenbank, deine Backups, deine Retention. |
| Kontingente | Großzügiger Free-Tier während der Beta. | Keine Kontingente — nur begrenzt durch dein Postgres und deine Bandbreite. |
| Support | Community + Best Effort. | Community + GitHub-Issues. |
Preise
Kostenlos während der Beta. Self-host bleibt für immer kostenlos.
Free
0 €/Monat
Für alle, die die gehostete Edition während der Beta nutzen.
- Unbegrenzte Projekte
- Alle API-Endpunkte
- Community-Support
Self-host
0 €für immer
Betreibe Pass That Payload auf deinem eigenen Server.
- Vollständiger Quellcode (MIT)
- Hetzner-Runbook inklusive
- Keine Nutzungsgrenzen
Pro
—kommt bald
Höhere Kontingente, SLA, Priority Support.
- Höhere Kontingente
- SLA + Priority Support
- Audit-Log-Export
Häufig gestellte Fragen
Wie unterscheidet sich das von QStash?
QStash ist klasse, aber nur gehostet. Pass That Payload bietet dieselben Primitive — HTTP-Enqueue, Retries, Schedules — aber self-hostable auf einem einzigen Postgres + Node-Container, mit Multi-Tenant-Projekten und RLS eingebaut.
Funktioniert es mit localhost / privaten URLs?
Ja, wenn der Dispatcher in Node läuft (Worker oder nodejs Route Runtime). Der Dispatcher holt die Ziel-URL selbst, also funktioniert alles, was aus seinem Netzwerk erreichbar ist.
Was passiert, wenn die Retries ausgeschöpft sind?
Die Nachricht geht nach max_retries Fehlschlägen in den Status "dead". Innerhalb einer Message Group läuft das nächste Geschwister trotzdem weiter — ein einzelner Fehler bricht nicht die ganze Kette ab.
Wie wird die Reihenfolge über mehrere Worker garantiert?
Die Reihenfolge wird in Postgres zum Claim-Zeitpunkt erzwungen: Die nächste Zeile einer Gruppe wird erst gepickt, wenn die vorigen Geschwister pending, pending_retry oder processing verlassen haben. Alle Dispatcher halten sich an dieselbe Regel.
Welche Regionen sind verfügbar?
Die gehostete Edition läuft in Hetzner Falkenstein (Deutschland, EU). Self-host überall dort, wo du Node + Postgres 16 ausführen kannst.
Ist es Open Source?
Ja — MIT-Lizenz auf GitHub. Im Console-Repository findest du den Quellcode, das SDK-Paket und das Operator-Runbook.