Svix - Self-Hosted Webhooks Service API

AWS Streaming & Messaging

Svix, the open source webhooks as a service server, a JWT authenticated REST API for sending, retrying and managing outbound webhooks, backed by a bundled PostgreSQL and Redis, secured on first boot.

Base
Hardened build
minimal ports, security patches applied at build time
Access
Unique credentials
generated on first boot, readable only by root
Verified
Boots working
services pass a health gate before release
Support
24/7, 365 days
by email and live chat, 24 hour response SLA

Overview

Svix is an open source webhooks as a service server. It gives your application a complete outbound webhooks backend: a REST API to create applications and endpoints, send messages, sign and deliver events to customer endpoints, and automatically retry failed deliveries with exponential backoff, all observable through the API. Svix stores durable state in PostgreSQL and uses Redis for its delivery queue and cache, so it handles high volumes of events reliably without you building and operating a webhook pipeline yourself.

It suits teams that need to send webhooks to their own customers and want to own the webhook infrastructure inside their own cloud account: adding webhook support to a SaaS product, delivering events to partner endpoints, or decoupling event producers from consumers behind a durable, retrying delivery layer. Every request to the API is authenticated with a bearer token, and nothing is exposed without it.

Why the cloudimg image

cloudimg delivers Svix fully installed with its PostgreSQL database and Redis on the same instance and the API fronted by nginx, so the webhooks server answers the moment the instance boots. The image is secure by default: because Svix is a control plane for outbound events, nothing ships with a known secret, so the JWT signing secret, the database password, the Redis password and the bootstrap API token are all generated uniquely on the first boot of each instance, before the port is reachable, and written to a root only credentials file. The bundled PostgreSQL and Redis are reachable only on the instance, the database starts empty on first boot with no prior data, and the image ships with a paired step by step deploy guide and 24/7 cloudimg support.

Common uses

  • Add outbound webhooks to your SaaS product with a REST API for applications, endpoints, event types and signed message delivery
  • Deliver events reliably to partner and customer endpoints with automatic retries, backoff and delivery observability
  • Own your webhook infrastructure inside your own cloud account, backed by a bundled PostgreSQL and Redis, with per instance secrets

Key features

  • Operational in minutes with zero configuration: this image completes every build and hardening step at image creation time. Launch an EC2 instance, SSH in, read your unique bootstrap token from a root-only file, and reach a working, authenticated webhooks REST API - no provisioning of databases, reverse proxies, or credential management required.

Description

This is a repackaged open source software product wherein additional charges apply for cloudimg support services.

## Overview

Svix is an enterprise-grade open source webhooks-as-a-service platform trusted by development teams worldwide. It gives your application a complete outbound webhooks backend: a REST API to create applications and endpoints, send messages, sign and deliver events to customer endpoints, and automatically retry failed deliveries with exponential backoff - all observable through the API. Svix stores durable state in PostgreSQL and uses Redis for its delivery queue and cache, so it handles high volumes of events reliably without you building and operating a webhook pipeline yourself.

This image runs the official upstream svix-server with a bundled PostgreSQL and Redis on the same instance, fronted by nginx, delivered fully installed so a working API is operational within minutes of launch.

## Why This Image vs a Manual Install

Compared to assembling Svix yourself, this image eliminates provisioning and wiring together the API server, PostgreSQL and Redis, configuring the reverse proxy, and - most importantly - the credential hardening. Because Svix is a control plane for outbound events, a known bootstrap secret would let anyone mint valid API tokens; this image never ships one. What typically requires several steps across container orchestration, database setup and security hardening is completed for you at image build time. You launch the instance, read your unique bootstrap token, and start creating applications and endpoints.

## Application Stack

The official upstream svix-server, PostgreSQL and Redis run as pinned-by-digest containers under a single systemd-managed docker compose stack on a private network. The API server is bound to the loopback interface only and fronted by an nginx reverse proxy on port 80. PostgreSQL and Redis are reachable only inside the private network and are never published to a host port. systemd starts the stack on boot and restarts it on failure.

## Security Hardening

This image follows a defence-in-depth approach with the following hardening measures applied:

  • No known bootstrap credential: the JWT signing secret, the database password, the Redis password and the bootstrap API token are all generated uniquely on each instance's first boot, before the API port is reachable, and written only to a root-only file
  • Network isolation: the API server binds exclusively to the loopback interface; only the nginx reverse proxy is exposed, and the bundled PostgreSQL and Redis are never published to a host port
  • Authentication enforced: every API request is authenticated with a bearer token; unauthenticated and wrong-token requests are rejected, while only an unauthenticated liveness health endpoint is public
  • Empty on first boot: the database starts empty with no prior data, so no baked state, secret or token survives image capture
  • Automatic restart: systemd monitors the stack and restarts it on failure

Buyers requiring formal compliance documentation should contact cloudimg to discuss specific requirements.

## Getting Started in Three Steps

1. Launch an EC2 instance with this AMI

2. SSH in and read your unique bootstrap API token from the root-only credentials file

3. Call the API with a bearer token to create your first application and endpoint, then start delivering signed, automatically retried webhooks

An unauthenticated health endpoint is available for load-balancer monitoring.

## AWS Integration

Deploy on any EC2 instance type. Use the unauthenticated health endpoint with an Application Load Balancer for availability monitoring. Back up your webhook state using EBS snapshots or AWS Backup. Place the instance behind your own domain and TLS termination for production traffic.

## Use Cases

  • Add outbound webhook support to a SaaS product without building and operating the delivery pipeline yourself
  • Deliver signed, automatically retried events to partner and customer endpoints from your own cloud account
  • Decouple event producers from consumers behind a durable, retrying delivery layer backed by PostgreSQL and Redis

## Next Steps

Ready to evaluate? Launch an instance and reach a working webhooks API within minutes. For a guided deployment walkthrough or architecture consultation, contact cloudimg support at any time - available 24/7 via email and chat.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Related technologies

webhooks as a serviceoutbound webhooksevent delivery apiwebhook retryself-hosted webhookswebhook signingsvix serverwebhook managementevent notificationwebhook endpoint