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.
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.
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.
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:
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
## 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.