Deployment

Deploy Notiway manually by pulling the Docker image from Docker Hub and wiring it to your own infrastructure. This gives you full control over every component.

Architecture

  graph LR
    Client[Clients] -->|WSS| LB[Load Balancer]
    LB --> GW[Notiway Notify<br/>Host Plugin]
    Producer[Your Services] -->|Publish| Broker[Broker Plugin]
    Broker --> Buffer[Buffer Plugin]
    Buffer --> GW
    GW <--> Storage[Storage Plugin]

Deployment Checklist

  1. Choose Your Hosting Environment
  2. Select Compatible Plugins
  3. Prepare Infrastructure
  4. Choose Your Image
  5. Configure Environment Variables
  6. Set Up a Load Balancer
  7. Plan for Scaling
  8. Deploy and Verify

Choose Your Hosting Environment

Notiway is cloud-agnostic. You can host it on any cloud provider (AWS, Azure, GCP) or on-premise. You need a Docker runtime or Kubernetes cluster to run the gateway container.

Currently natively supported hosting environments are Portable (a set of cloud-agnostic plugins you can host anywhere) and AWS. Native support for Azure, GCP, and other environments is coming soon.

Select Compatible Plugins

Choose the right plugins for your hosting environment. You need to select a Host, Broker, Buffer, and optionally a Storage plugin that are compatible with your provider and with each other.

Recommended Plugin Combinations

Plugin TypeRecommendedDescription
HostECSAWS Elastic Container Service
BrokerSNSAmazon Simple Notification Service
BufferSQSAmazon Simple Queue Service
StorageDynamoDBAmazon DynamoDB
Plugin TypeRecommendedDescription
HostKubernetesCloud-agnostic container orchestration
BrokerRabbitMQOpen-source message broker
BufferRabbitMQReuses the same RabbitMQ instance
StoragePostgreSQLOpen-source relational database

Prepare Infrastructure

Follow the infrastructure requirements of your selected plugins. Each plugin documents what resources need to be created before Notiway starts and what permissions are required.

Not all components need to be created manually:

ComponentPrepare Before Notiway?Notes
HostYesSet up your container runtime (ECS cluster, Kubernetes cluster, Docker host, etc.)
BrokerYesCreate the SNS topic, Redis instance, RabbitMQ exchange, Kafka topic, or Service Bus topic before Notiway starts
BufferNoNotiway creates buffer resources (e.g. SQS queues) automatically at startup
StorageYesCreate the DynamoDB table, PostgreSQL database, MongoDB collection, or Redis instance
Auth ProviderYesSet up your identity provider (e.g., issue JWT signing keys)
Load BalancerYesDeploy and configure your NLB, Application Gateway, or reverse proxy
The Buffer plugin auto-creates its resources when Notiway starts. Make sure Notiway has the appropriate permissions to create and manage these resources in your selected infrastructure.

Choose Your Image

Pull the Notiway gateway image from Docker Hub:

ImageDescription
notiway/notify:portable-0.5.0Portable image. Works with all cloud-agnostic plugins
notiway/notify:aws-0.5.0Includes AWS SDK. Optimized for AWS deployments
docker pull notiway/notify:portable-0.5.0

Configure Environment Variables

All Notiway configuration is done through environment variables.

General Settings

VariableDescriptionDefault
EnvironmentEnvironment name (e.g., production, staging). Used in logging output and resource names
Logging__LogLevel__DefaultLog verbosity (Debug, Information, Warning, Error)Information

Plugin Selection

Plugin selection follows this pattern:

Infra__Plugins__{Type}__Name            # Plugin name
Infra__Plugins__{Type}__Version         # Plugin version

Where {Type} is one of: Host, Broker, Buffer, Storage, Auth, TenantValidation.

Infrastructure configuration is provider-specific and configures resources like broker addresses, database table names, and regions. See each plugin’s documentation for the full list of required variables.

Full Configuration Examples

# Environment
Environment=production

# AWS
Infra__AWS__Account=123456789012
Infra__AWS__Region=eu-central-1

# Host
Infra__Plugins__Host__Name=ECS
Infra__Plugins__Host__Version=0.7.0

# Broker
Infra__Plugins__Broker__Name=SNS
Infra__Plugins__Broker__Version=0.12.0
Infra__AWS__Broker__Address=arn:aws:sns:eu-central-1:123456789012:notiway-notifications

# Buffer
Infra__Plugins__Buffer__Name=SQS
Infra__Plugins__Buffer__Version=0.17.0
Infra__AWS__Buffers__Notifications__DeadletterQueueArn=arn:aws:sqs:eu-central-1:123456789012:notiway-dlq

# Storage
Infra__Plugins__Storage__Name=DynamoDb
Infra__Plugins__Storage__Version=0.9.0
Infra__AWS__Databases__PersistedNotifications__TableName=notiway-notifications
Infra__AWS__Databases__NoficicationUsers__TableName=notiway-notification-users

# Auth
Infra__Plugins__Auth__Name=NoAuth
Infra__Plugins__Auth__Version=0.10.0

# Tenant Validation
Infra__Plugins__TenantValidation__Name=NoValidation
Infra__Plugins__TenantValidation__Version=0.9.0
# Environment
Environment=production

# Host
Infra__Plugins__Host__Name=Kubernetes
Infra__Plugins__Host__Version=0.7.0

# Broker
Infra__Plugins__Broker__Name=RabbitMQ
Infra__Plugins__Broker__Version=0.12.0

# Buffer
Infra__Plugins__Buffer__Name=RabbitMQ
Infra__Plugins__Buffer__Version=0.17.0

# Storage
Infra__Plugins__Storage__Name=PostgreSQL
Infra__Plugins__Storage__Version=0.9.0

# Auth
Infra__Plugins__Auth__Name=NoAuth
Infra__Plugins__Auth__Version=0.10.0

# Tenant Validation
Infra__Plugins__TenantValidation__Name=NoValidation
Infra__Plugins__TenantValidation__Version=0.9.0
Portable plugin configuration keys will vary depending on your chosen plugins. Refer to each plugin’s documentation for the required infrastructure variables.

Set Up a Load Balancer

Clients connect to the gateway from outside your network. Place the gateway behind a load balancer that is accessible from the internet (or your client network) and supports WebSocket connections.

RequirementDetails
WebSocket supportThe load balancer must forward Connection: Upgrade and Upgrade: websocket headers
TLS terminationTerminate TLS at the load balancer. Notiway listens on HTTP internally
RoutingRoute traffic to the gateway’s /notifications endpoint
Health checkPoint health checks at the Notiway health endpoint
Sticky sessionsNot required if clients set skipNegotiation: true and transport: 1 (WebSockets) to bypass the negotiate handshake. Otherwise, sticky sessions must be enabled
Idle timeoutSet to at least 60 seconds to avoid premature WebSocket disconnects

AWS Network Load Balancer supports WebSocket connections natively. Configure:

  • TLS listener on port 443 with your ACM certificate
  • Target group pointing to Notiway containers on port 8080
  • Health check configured for Notiway’s health endpoint

Azure Application Gateway supports WebSocket by default. Configure:

  • Frontend listener on port 443 with your TLS certificate
  • Backend pool pointing to Notiway containers
  • Health probe configured for Notiway’s health endpoint
  • Request timeout set to 120 seconds or higher
nginx.conf
upstream notiway {
    server notiway-1:8080;
    server notiway-2:8080;
}

server {
    listen 443 ssl;
    server_name notiway.example.com;

    ssl_certificate     /etc/ssl/certs/notiway.crt;
    ssl_certificate_key /etc/ssl/private/notiway.key;

    location /notifications {
        proxy_pass http://notiway;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 120s;
    }
}

Plan for Scaling

Notiway is stateless. The broker and buffer plugins handle cross-instance communication, so you can scale horizontally.

ConsiderationRecommendation
Scaling metricUse connection count or CPU utilization. WebSocket connections are long-lived, so connection count is often a better metric than request rate
Minimum instancesRun at least 2 instances for high availability
Scale-down behaviorWhen an instance is removed, its WebSocket connections are dropped. Make sure clients handle reconnection gracefully
Scale-down cooldownUse a longer cooldown period to avoid frequent scale-down events that cause unnecessary connection churn

Deploy and Verify

Once the gateway is running, verify the deployment:

  1. Check health by hitting the health endpoint through your load balancer
  2. Test a WebSocket connection using the client examples
  3. Send a test notification following the Sending Notifications guide

Troubleshooting

Container fails to start

  • Check container logs: docker logs notiway
  • Verify all required environment variables are set (plugin Name and Version are always required)
  • Ensure the configured infrastructure (broker, storage) is reachable from the container network

WebSocket connections fail

  • Verify your load balancer forwards Upgrade headers
  • Check that TLS certificates are valid
  • Ensure the idle timeout is long enough (at least 60 seconds)

Notifications not delivered

  • Confirm your service publishes to the correct broker endpoint
  • Check that buffer resources were created (e.g., SQS queues in the AWS console)
  • Review Notiway logs for deserialization or permission errors

Next Steps