Svix Server

Sign in to the AWS Marketplace and search for Svix by SecureAnyCloud. Choose Continue to Subscribe, accept the terms, then choose Continue to Configuration and Continue to Launch.

Pick your region, the m5.large instance type, your VPC and subnet, and your key pair. Select a security group that allows TCP 22 and 80, then choose Launch.

aws ec2 run-instances --region us-east-1 \
  --image-id ami-<svix-ami-id> --instance-type m5.large \
  --key-name <your-key-pair> --security-group-ids <security-group-id> \
  --subnet-id <subnet-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=svix-01}]'

Subscribing to the listing gives you the AMI id for your region. On the security group, open TCP 22 (SSH) and TCP 80 (the API) only to the networks that need them.

The stack runs as three containers (svix-server, PostgreSQL and Redis) under one svix.service, fronted by nginx. Check that the services are active, list the containers and see which ports are bound. nginx listens on :80. The svix API is published to 127.0.0.1:8071 (loopback only). PostgreSQL and Redis have no host port at all.

sudo systemctl is-active docker svix nginx
sudo docker compose -f /etc/svix/compose.yaml ps
sudo ss -tln | grep -E ':80 |:8071'

All three services report active and the three containers show running. nginx is bound on :80, and the svix API is bound only on 127.0.0.1:8071. PostgreSQL (5432) and Redis (6379) never appear on a host port because they are reachable only inside the private Docker network.

On first boot, before the port was reachable, the instance created a unique JWT signing secret, database password, Redis password and bootstrap API token. They are written to a root-only file. Read them:

sudo cat /root/svix-credentials.txt

The file (mode 0600 root:root) holds SVIX_JWT_SECRET, the bootstrap API_TOKEN you authenticate the API with, POSTGRES_PASSWORD, REDIS_PASSWORD, and SVIX_URL (the address to reach this instance on).

None of these values ship in the image. Every value is unique to this instance, so no two instances share a credential and there is no default token to change.

The health endpoint is public, but every other endpoint requires the bearer token. Confirm that an unauthenticated request is rejected with 401 and that the per-instance token authenticates a real call:

SVIX_TOKEN=$(sudo grep '^API_TOKEN=' /root/svix-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'health (no auth): %{http_code}\n' http://localhost/api/v1/health/
curl -s -o /dev/null -w 'list apps (no token): %{http_code}\n' http://localhost/api/v1/app/
curl -s -o /dev/null -w 'list apps (with token): %{http_code}\n' -H "Authorization: Bearer $SVIX_TOKEN" http://localhost/api/v1/app/

The health check returns 200 with no authentication. The unauthenticated application list is rejected with 401, and the same call with the per-instance token returns 200.

This is the whole security model. The health probe is open for load balancers, and the bearer token gates everything else.

The core workflow has four parts. Create an application (one per customer or tenant), register the event types you send, add endpoints (the URLs Svix delivers to), then send messages. Svix signs each message, queues it and delivers it to every matching endpoint. On failure, it retries with exponential backoff. Run the whole flow from the instance:

SVIX_TOKEN=$(sudo grep '^API_TOKEN=' /root/svix-credentials.txt | cut -d= -f2-)
APP_ID=$(curl -s -X POST http://localhost/api/v1/app/ \
  -H "Authorization: Bearer $SVIX_TOKEN" -H 'Content-Type: application/json' \
  -d '{"name":"orders-service"}' | python3 -c 'import sys,json;print(json.load(sys.stdin)["id"])')
echo "application: $APP_ID" curl -s -X POST http://localhost/api/v1/event-type/ \
  -H "Authorization: Bearer $SVIX_TOKEN" -H 'Content-Type: application/json' \
  -d '{"name":"order.created","description":"An order was created"}' >/dev/null curl -s -X POST http://localhost/api/v1/app/$APP_ID/endpoint/ \
  -H "Authorization: Bearer $SVIX_TOKEN" -H 'Content-Type: application/json' \
  -d '{"url":"https://example.com/webhook","description":"partner endpoint"}' >/dev/null curl -s -X POST http://localhost/api/v1/app/$APP_ID/msg/ \
  -H "Authorization: Bearer $SVIX_TOKEN" -H 'Content-Type: application/json' \
  -d '{"eventType":"order.created","payload":{"orderId":"ord_123","amount":4200}}' echo

Each call returns the created object as JSON. The final POST .../msg/ returns a message with an id beginning msg_ and your payload echoed back. Svix has accepted the event, signed it and queued it for delivery to the https://example.com/webhook endpoint, with automatic retries.

To see a delivery arrive, point the endpoint URL at a real receiver of yours. A request bin works for a quick test.

You can call the API from anywhere that can reach the instance on port 80. Retrieve the bootstrap token once over SSH. Then call the API with your instance public IP:

curl -H "Authorization: Bearer <API_TOKEN>" http://<vm-ip>/api/v1/app/

For production, use the official Svix client libraries (available for Python, JavaScript/TypeScript, Go, Rust, Java, C#, Ruby, PHP and more). Point the library's server_url at http://<instance-ip>/ (or your own domain, see Step 9) and pass the bootstrap token. Then create applications, endpoints and messages from your application code, exactly as the curl calls above do.

The bootstrap token is scoped to one organization. To issue additional tokens, for example one per environment or per tenant boundary, generate them with the same per-instance JWT secret:

sudo docker run --rm --env-file /etc/svix/svix.env -e SVIX_QUEUE_TYPE=redis -e SVIX_CACHE_TYPE=redis \
  svix/svix-server svix-server jwt generate

This prints a new Token (Bearer): ... value signed with this instance's JWT secret. Store it securely. Anyone holding a token can call the API, so treat tokens like passwords. If a token is ever exposed, rotate the JWT secret in /etc/svix/svix.env, then run sudo systemctl restart svix.

The image serves the API over plain HTTP on port 80, which is convenient behind a load balancer or private network. In production, terminate TLS in front of Svix so tokens and payloads travel encrypted. You have these options:

• Front the instance with an Application Load Balancer and an AWS Certificate Manager certificate, or a CloudFront distribution, and forward to nginx on port 80.
• Install your own certificate. Add a TLS server block to /etc/nginx/sites-available/svix that references your certificate and key, open 443/tcp on the security group, then run sudo systemctl reload nginx.
• Point a DNS name you control at the instance public IP. Use that name (with https://) as the server_url in your Svix client libraries.

Component Version / Detail

Webhooks server svix-server v1.98.0 (Rust binary, pinned by image digest)

API front nginx on :80 reverse proxying to 127.0.0.1:8071

Database bundled PostgreSQL 16 (private Docker network, no host port)

Queue and cache bundled Redis 7 (private Docker network, no host port, password protected)

Orchestration Docker Compose under svix.service

JWT secret per instance, created on first boot in /etc/svix/svix.env

Bootstrap token per instance, created on first boot in /root/svix-credentials.txt

Operating system Ubuntu 24.04 LTS (patched at build)

License MIT (Svix)

sudo systemctl status svix --no-pager | head -12 sudo docker compose -f /etc/svix/compose.yaml logs --tail 40 svix-server

Restart the whole stack with sudo systemctl restart svix. Follow the API logs live with sudo docker compose -f /etc/svix/compose.yaml logs -f svix-server. View the configuration in /etc/svix/svix.env and /etc/svix/compose.yaml. After you change the environment file, restart the service to apply it.

• Restrict the security group. Allow TCP 80 (and 22 for administration) only from the networks that call the API.
• Terminate TLS in front of Svix (Step 9) so bearer tokens and payloads are encrypted in transit.
• Treat tokens like passwords. They are stored in /root/svix-credentials.txt (root only). Rotate the JWT secret if a token is ever exposed.
• Keep the bundled database and queue private. PostgreSQL and Redis sit on a private Docker network with no host port. Keep them that way.
• Keep the OS patched. Unattended security upgrades remain enabled on the running instance.

Svix is distributed under the MIT License. This SecureAnyCloud image bundles the unmodified official open source svix-server release; SecureAnyCloud provides the packaging, the bundled PostgreSQL and Redis, the per instance secret generation and bootstrap token, the paired deploy guide, and 24/7 support with a guaranteed 24 hour response SLA. Svix is an independent open source project and this image is not affiliated with or endorsed by Svix.

Deploy on AWS

Find Svix on the AWS Marketplace, published by SecureAnyCloud. Subscribe and launch from the Marketplace console or the AWS CLI as shown above.

Need Help?

Email sales@secureanycloud.com for deployment help, configuration questions, or licensing enquiries.

Deploy on AWS

Launch Svix - Self-Hosted Webhooks Service API with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com