Skip to main content

​
Carrier

A lightweight messaging adapter for webhooks designed as a sidecar container for the SQS event worker pattern.

​
Why Carrier?

Carrier is a purpose-built messaging daemon for the SQS event worker pattern. With an 8MB Docker image and less than 5MB of RAM at idle, it’s designed to run efficiently as a sidecar container in Kubernetes pods.

Lightweight

Under 8MB Docker image size with less than 5MB RAM usage at idle

SQS to Webhook

Seamlessly adapts SQS messages to HTTP webhooks

Health Monitoring

Built-in health check monitoring for webhook endpoints

Dynamic Timeouts

Support for distributed backoff with dynamic visibility timeouts

Kubernetes Native

Designed for the sidecar deployment pattern

Configurable

Flexible batching and concurrency configuration

​
Quick Example

Deploy Carrier as a sidecar in your Kubernetes pod:
Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: carrier-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: carrier-demo
  template:
    metadata:
      labels:
        app: carrier-demo
    spec:
      containers:
        - name: carrier
          image: amplifysecurity/carrier
          env:
            - name: CARRIER_WEBHOOK_ENDPOINT
              value: http://localhost:9000/webhook
            - name: CARRIER_SQS_ENDPOINT
              value: https://sqs.us-west-2.amazonaws.com
            - name: CARRIER_SQS_QUEUE_NAME
              value: carrier-demo
        - name: worker
          image: your-worker:latest

​
Getting Started

Introduction

Learn about Carrier’s architecture and features

Quickstart

Get Carrier running in minutes

Docker Compose

Deploy locally with Docker Compose

Kubernetes

Deploy to Kubernetes as a sidecar

​
Key Features

Carrier is written in Go and compiles to a minimal Docker image under 8MB. At idle, it consumes less than 5MB of RAM, making it perfect for running as a sidecar container alongside your event workers.
Carrier implements the SQS event worker pattern by continuously polling an SQS queue and forwarding messages as HTTP POST requests to your webhook endpoint. This pattern decouples message consumption from processing.
Configure health check endpoints to ensure Carrier only processes messages when your webhook service is online. This prevents unnecessary dead letter queue traffic during service restarts.
Implement distributed backoff strategies by returning HTTP 429 with a Retry-After header. Carrier automatically adjusts SQS visibility timeouts to prevent premature message redelivery.
Control the number of concurrent SQS receivers, batch sizes, and worker threads to optimize throughput for your specific workload.

​
Architecture

Carrier separates concerns between receivers (which read messages) and transmitters (which send messages). Currently, it supports SQS as a receiver and HTTP webhooks as a transmitter. 
┌─────────────────┐
│   SQS Queue     │
└────────┬────────┘
         │
         │ Long Polling
         │
┌────────▼────────┐
│  SQS Receiver   │
│   (Carrier)     │
└────────┬────────┘
         │
         │ HTTP POST
         │
┌────────▼────────┐
│    Webhook      │
│  (Your Worker)  │
└─────────────────┘

Architecture Overview

Understand Carrier’s design

Receivers

How message receiving works

Transmitters

How message transmission works

Build docs developers (and LLMs) love

Get started for freeTalk to us