Forem: Bartek Gałęzowski

Secure RDS Access Without Bastion Hosts: Using ECS Containers and SSM

Bartek Gałęzowski — Wed, 25 Feb 2026 08:00:00 +0000

The Problem

Accessing RDS databases in production environments presents a common security challenge. Direct internet access to databases is a significant security risk, so most organizations place their RDS instances in private subnets without public endpoints. But how do you access these databases for debugging, data analysis, or administrative tasks?

Traditional approaches include:

Bastion hosts: Requires maintaining and securing additional EC2 instances
VPN connections: Complex setup and ongoing maintenance overhead
SSH tunneling: Still requires a jump server with SSH access

There's a more elegant solution: leveraging your existing ECS containers as secure tunnels to your RDS databases using AWS Systems Manager (SSM) Session Manager.

The Solution

This script creates a secure tunnel from your local machine to an RDS database through a running ECS container, using SSM Session Manager for the connection. No SSH keys, no bastion hosts, no exposed ports—just IAM-based authentication and encrypted connections.

Prerequisites

Before using this script, ensure you have:

AWS CLI installed and configured with appropriate credentials
Session Manager Plugin for AWS CLI
ECS Task Role with permissions to use SSM:

 {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "ssmmessages:CreateControlChannel",
           "ssmmessages:CreateDataChannel",
           "ssmmessages:OpenControlChannel",
           "ssmmessages:OpenDataChannel"
         ],
         "Resource": "*"
       }
     ]

ECS Exec enabled on your service (can be enabled with aws ecs update-service --cluster <cluster> --service <service> --enable-execute-command --force-new-deployment)

How It Works

The script performs the following operations:

1. Task Discovery

TASK_ID=$(aws ecs list-tasks \
  --cluster "$CLUSTER" \
  --service-name "$SERVICE_NAME" \
  --desired-status RUNNING \
  --query 'taskArns[0]')

Finds the first running task in the specified ECS service.

2. Container Runtime ID Retrieval

CONTAINER_RUNTIME_ID=$(aws ecs describe-tasks \
  --cluster "$CLUSTER" \
  --tasks "$TASK_ID" \
  --query 'tasks[0].containers[?name==`'"$SERVICE_NAME"'`].runtimeId | [0]')

3. Port Forwarding Session

aws ssm start-session \
  --target "ecs:${CLUSTER}_${TASK_ID}_${CONTAINER_RUNTIME_ID}" \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["$DB_HOST"],"portNumber":["5432"], "localPortNumber":["$LOCAL_PORT"]}'

Establishes a secure tunnel through the ECS container to the database.

Usage

#!/usr/bin/env bash

set -eu

usage() {
  echo "Usage: $0 <CLUSTER> <SERVICE_NAME> <DB_HOST> <LOCAL_PORT> <REGION>"
  echo "  cluster: ECS cluster name"
  echo "  service: ECS service name"
  echo "  db_host: Database host"
  echo "  local_port: Local port to forward"
  echo "  region:  AWS region (e.g., us-east-2)"
  exit 1
}

if [ $# -ne 5 ]; then
  echo "Error: Expected 5 arguments, got $#" >&2
  usage
fi

CLUSTER="$1"
SERVICE_NAME="$2"
DB_HOST="$3"
LOCAL_PORT="$4"
REGION="$5"

get_first_task_id() {
  local FIRST_TASK_ID
  FIRST_TASK_ID=$(aws ecs list-tasks \
    --cluster "$CLUSTER" \
    --service-name "$SERVICE_NAME" \
    --desired-status RUNNING \
    --output text \
    --query 'taskArns[0]' \
    --region "$REGION" | sed 's/.*\///')

  if [ "$FIRST_TASK_ID" = "None" ] || [ -z "$FIRST_TASK_ID" ]; then
    echo "Error: No running tasks found for service '$SERVICE_NAME' in cluster '$CLUSTER'" >&2
    return 1
  fi

  echo "$FIRST_TASK_ID"
}

TASK_ID=$(get_first_task_id)

CONTAINER_RUNTIME_ID=$(aws ecs describe-tasks \
  --output text \
  --cluster "$CLUSTER" \
  --tasks "$TASK_ID" \
  --region "$REGION" \
  --query 'tasks[0].containers[?name==`'"$SERVICE_NAME"'`].runtimeId | [0]')

TARGET="ecs:${CLUSTER}_${TASK_ID}_${CONTAINER_RUNTIME_ID}"

aws ssm start-session \
  --target "$TARGET" \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters "{\"host\":[\"$DB_HOST\"],\"portNumber\":[\"5432\"], \"localPortNumber\":[\"$LOCAL_PORT\"]}" \
  --region "$REGION"

Save the script as ecs-db-tunnel.sh and make it executable:

chmod +x ecs-db-tunnel.sh

Run the script with the required parameters:

./ecs-db-tunnel.sh <CLUSTER> <SERVICE_NAME> <DB_HOST> <LOCAL_PORT> <REGION>

Example:

./ecs-db-tunnel.sh \
  production-cluster \
  api-service \
  mydb.c9akciq32.us-east-2.rds.amazonaws.com \
  5432 \
  us-east-2

Once connected, you can access the database from your local machine:

psql -h localhost -p 5432 -U dbuser -d mydb

or using other tools such as DBeaver.

Key Benefits

1. No Infrastructure Overhead

No need to maintain bastion hosts or VPN servers. You leverage existing ECS containers.

2. Enhanced Security

No SSH keys to manage or rotate
No exposed ports or public endpoints
IAM-based authentication and authorization
All traffic encrypted through SSM
Audit trail through CloudTrail

3. Zero Configuration

If your ECS service is already running with ECS Exec enabled, you're ready to go.

4. Cost Effective

No additional EC2 instances to run. Session Manager has no additional cost.

5. Temporary Access

Connection exists only while the script is running—perfect for adhoc administrative tasks.

Security Considerations

Network Security

This approach works because:

The ECS container is in the same VPC as the RDS instance
The container's security group allows outbound connections to the RDS security group
The RDS security group permits inbound connections from the ECS container's security group

Access Control

Control who can establish tunnels using IAM policies:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ecs:ListTasks", "ecs:DescribeTasks", "ssm:StartSession"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-2"
        }
      }
    }
  ]
}

Troubleshooting

No running tasks found

Ensure the ECS service has at least one running task:

aws ecs list-tasks --cluster <cluster> --service-name <service> --desired-status RUNNING

Session Manager plugin not found

Install the Session Manager plugin following AWS documentation.

Connection refused

Verify:

RDS security group allows inbound from ECS container security group
Database endpoint is correct
ECS task has network connectivity to RDS

ECS Exec not enabled

Enable it on your service:

aws ecs update-service \
  --cluster <cluster> \
  --service <service> \
  --enable-execute-command \
  --force-new-deployment

Conclusion

Using ECS containers as secure tunnels to RDS databases is an elegant solution that leverages existing infrastructure while maintaining strong security posture. This approach eliminates the need for bastion hosts, reduces attack surface, and provides auditable, temporary access to private databases.

The script demonstrates that sometimes the best security solutions are those that work with your existing architecture rather than adding more complexity on top of it.

How to Disable HTTP Request Logs in Medusa v1 and v2?

Bartek Gałęzowski — Tue, 11 Nov 2025 23:00:00 +0000

Excessive HTTP request logs in Medusa.js can slow down your e-commerce backend and clutter production logs. While detailed request logging is valuable in development, it becomes a performance bottleneck in live environments with high traffic. In this guide, you’ll learn how to disable or manage request logs in Medusa.js v1 and v2, improve server efficiency, and keep only the essential logs that truly matter in production.

Why Control HTTP Request Logs?

HTTP request logs in Medusa.js can become overwhelming, especially for e-commerce stores with significant traffic. Every API call, webhook, and admin request generates log entries. While useful for debugging, these logs can:

Degrade performance - Writing thousands of log entries consumes CPU and I/O resources
Reduce log readability - Important error messages get buried in routine request logs
Increase storage costs - Log aggregation services charge based on volume
Complicate monitoring - Alert systems struggle to identify real issues among noise

For production stores handling hundreds or thousands of requests per minute, controlling request logs is not just a convenience—it's a necessity.

Disabling Request Logs in Medusa.js v1

Medusa v1 doesn't provide a built-in configuration option to disable HTTP request logs. While Medusa has moved to v2 and only provides security updates for v1, many production stores still run on v1. The lack of log control can be a significant operational challenge.

The only reliable solution is to patch the Medusa source code using patch-package. This approach modifies how Medusa's HTTP logger behaves, allowing you to conditionally disable request logs based on the LOG_LEVEL environment variable.

Prerequisites

A Medusa v1 project
Node.js and npm/yarn installed
Access to modify your project's dependencies

Step 1: Install patch-package

First, install patch-package as a development dependency:

npm install --save-dev patch-package

Or with yarn:

yarn add -D patch-package

Step 2: Add postinstall Script

Update your package.json to run patch-package after installing dependencies:

{
  "scripts": {
    "postinstall": "patch-package"
  }
}

This ensures your patches are applied automatically whenever you run npm install or yarn install.

Step 3: Locate the HTTP Logger File

Navigate to your node_modules directory and find the Medusa core HTTP logger:

node_modules/@medusajs/medusa/dist/loaders/logger.js

This file initializes the Morgan HTTP request logger that generates all the request logs.

Step 4: Modify the Logger Configuration

Open node_modules/@medusajs/medusa/dist/loaders/express.js and locate the Morgan middleware configuration. It typically looks like this:

skip: function () { return process.env.NODE_ENV === "test"; },

Replace it with a conditional configuration:

skip: function () { 
    return process.env.LOG_LEVEL !== "debug" || process.env.NODE_ENV === "test"; 
},

This modification ensures that HTTP request logs appear when LOG_LEVEL=debug is explicitly set.

Step 5: Create the Patch

After modifying the file, create a patch:

npx patch-package @medusajs/medusa

This command generates a patch file in patches/@medusajs+medusa+[version].patch that contains your modifications.

Step 6: Configure Your Environment

In your production environment, ensure LOG_LEVEL is not set to debug

Verification

Restart your Medusa server. In production mode, you should no longer see HTTP request logs like:

[http]: GET /store/products 200 45ms
[http]: POST /store/cart 201 120ms

These logs will only appear when running with LOG_LEVEL=debug.

Note that LOG_LEVEL cannot be set using .env file, because this environment variable must be set before starting the server, as a system environment.

Disabling Request Logs in Medusa.js v2

Good news! Medusa v2 includes built-in support for controlling HTTP request logs without requiring patches. The logging system has been completely redesigned with proper configuration options.

Using the Logging Configuration

Medusa v2 provides a comprehensive logging configuration system documented in the official Medusa v2 logging guide.
The available log levels, from lowest to highest levels, are:

silly
debug
verbose
http (default, meaning only HTTP requests are logged)
info
warn
error

If you want to disable HTTP request logs specify your own LOG_LEVEL env variable without http.

Best Practices

Regardless of which Medusa version you're using, follow these logging best practices:

1. Use Environment-Specific Configurations

Always differentiate between development, staging, and production logging:

Development: Enable all logs including HTTP requests
Staging: Enable moderate logging to catch issues
Production: Disable HTTP logs, keep error and warning logs

2. Monitor Performance Impact

Before and after implementing log controls, monitor:

CPU usage during peak traffic
I/O wait times
Log storage consumption
Application response times

3. Keep Critical Logs

Even when disabling HTTP logs, maintain:

Error logs (always enabled)
Warning logs (business logic issues)
Security-related logs (authentication failures, suspicious activity)
Transaction logs (payment processing, order creation)

4. Implement Log Rotation

Troubleshooting

Patch Not Applied (v1)

If your patch isn't working:

Verify postinstall script is in package.json
Delete node_modules and reinstall: rm -rf node_modules && npm install
Check patch file exists: ls patches/
Manually apply: npx patch-package @medusajs/medusa

Logs Still Appearing (v2)

If logs persist in Medusa v2:

Check environment variables are loaded: echo $LOG_LEVEL
Check for custom middleware that might add logging

Conclusion

Controlling request logs is crucial for high-traffic Medusa.js e-commerce stores. While Medusa v1 requires a workaround using patch-package, Medusa v2 provides built-in configuration options that make log management straightforward.

For v1 projects, the patch approach is currently the only reliable solution, despite v1 being in maintenance mode with security-only updates. Many production stores still depend on v1, making this patch an essential operational improvement.

For new projects or those planning to migrate, Medusa v2 offers a more robust and maintainable logging system that eliminates the need for patches.

By implementing proper log control, you'll improve application performance, reduce operational costs, and make your logs more actionable for debugging real issues. Whether you're on v1 or v2, taking control of your logging strategy is an investment that pays dividends in operational efficiency.

E-commerce Load & Stress Testing with k6 on AWS Fargate

Bartek Gałęzowski — Wed, 10 Sep 2025 08:15:42 +0000

Why E-commerce Load Testing is Critical?

E-commerce platforms face unique performance challenges that can make or break business success. This is exactly why e-commerce load testing is critical, it ensures your store can deliver a fast, reliable experience no matter how many users are browsing or buying at once. Unlike traditional websites, online stores must seamlessly handle complex user journeys including:

Product searches and filtering
Real-time inventory checks
Shopping cart management
Payment processing
Order fulfillment workflows

The stakes are incredibly high: a single second of delay results in a 7% reduction in conversions, and during peak traffic events like Black Friday or flash sales, even minor performance issues.

The Scale Challenge in E-Commerce Load Testing

In e-commerce, the question isn’t simply whether your platform works - it’s whether it can perform flawlessly when hundreds or thousands of shoppers are online at the same time. E-commerce load testing ensures your site remains fast, stable, and responsive under real-world pressure. Your testing strategy should match your business stage:

Startups: Validate platform stability before your first major marketing campaigns
Growing businesses: Guarantee smooth scaling during seasonal peaks and viral traffic spikes
Enterprise teams: Simulate millions of concurrent users across multiple AWS regions for global coverage

Why E2E Tests Aren’t Enough?

Traditional end-to-end (E2E) testing works well for verifying individual features, but it falls short when it comes to scalability testing. While E2E automation can confirm that checkout or search flows work for single users, it doesn’t reveal how your site performs under thousands of simultaneous transactions.

Imagine you’ve built the smoothest checkout process possible — perfectly tested with automation scripts. You might even run 2–4 of these flows in parallel, but beyond that, your local machine simply can’t keep up. Most development laptops max out at generating traffic for 50–100 virtual users (VUs). Realistic e-commerce load testing often requires thousands.
The main resource limitations are:

CPU bottlenecks on local machines
Memory constraints during peak simulations
Network bandwidth limits when testing at scale

Without distributed infrastructure, it’s impossible to replicate real-world shopping surges.

This is where distributed load testing with k6 and AWS ECS Fargate becomes mission-critical. By matching test design to your unique traffic patterns and infrastructure, you can identify weaknesses before they cost you sales.

But what is k6?

Grafana k6 is an open-source load testing tool for developers, designed to test the performance and reliability of APIs, microservices, and websites. It uses JavaScript for scripting, is lightweight, and focuses on automation, CI/CD integration, and developer-friendly workflows. They also offers k6 Cloud a managed SaaS solution that removes infrastructure headaches while delivering enterprise-scale load testing. You can run the same k6 scripts locally and in the cloud, making it convenient for teams already using k6.
However, the trade-offs include:

High costs for large-scale or frequent tests
Usage limits depending on your subscription
Reduced customization compared to self-managed infrastructure

For many e-commerce teams, these limitations make a self-hosted or hybrid model more cost-effective in the long term.

k6 and AWS ECS Fargate for Distributed E-commerce Load Testing

A more flexible approach is to combine k6 with AWS ECS (Elastic Container Service) and Fargate to create a distributed, scalable, and cost-efficient load testing setup. Each container acts as an independent load generator, so you can spin up dozens — or even hundreds — of instances across AWS regions.

Why ECS Fargate Works for Load Testing at Scale

Serverless architecture — no EC2 or cluster management
Massive scalability — run hundreds of containers simultaneously
Cost control — pay only for the resource used during testing
Global reach — simulate traffic from multiple AWS regions
Container isolation — each load generator runs independently without affecting others

Prerequisites for Deployment

Before building your distributed load testing environment, you’ll need:

AWS CLI configured with IAM permissions
Docker installed locally
Basic understanding of ECS concepts
An Amazon ECR (Elastic Container Registry) repository
Prepared k6 test scripts (e.g., load-test.js)

Step-by-Step Implementation Guide

Step 1: Creating the Optimized Docker Image

Create a Dockerfile that builds a custom k6 image with additional capabilities:

FROM golang:1.24-alpine AS builder
RUN apk add --no-cache git
RUN go install go.k6.io/xk6/cmd/xk6@latest \
  && xk6 build --with github.com/LeonAdato/xk6-output-statsd

FROM grafana/k6:0.57.0-with-browser
WORKDIR /
COPY --from=builder /go/k6 /usr/bin/k6
ENV K6_STATSD_ENABLE_TAGS=true
COPY . .
CMD ["run", "-o", "output-statsd", "--include-system-env-vars", "--compatibility-mode=experimental_enhanced", "load-test.js"]

Important Note: This configuration includes xk6-output-statsd for real-time output of k6 test metrics to a StatsD service, enabling advanced monitoring capabilities.

Step 2: Building and Pushing the Docker Image

Build and deploy your Docker image to AWS ECR:

# Build the image (add --platform=linux/amd64 for Apple Silicon Macs)
docker build -t k6-ecommerce-load-test .

# Tag for ECR
docker tag k6-ecommerce-load-test:latest [your-ecr-uri]:[your-tag]

# Authenticate with ECR
aws ecr get-login-password --region [your-region] | docker login --username AWS --password-stdin [your-ecr-uri]

# Push to ECR
docker push [your-ecr-uri]:[your-tag]

Automated Build Script

For convenience, use this automated build script:

#!/bin/bash
# Usage: ./build-image.sh <ecr-uri> <tag> <region>

ECR_URI="$1"
TAG="$2"
REGION="$3"

if [ -z "$ECR_URI" ] || [ -z "$TAG" ] || [ -z "$REGION" ]; then
  echo "Usage: $0 <ecr-uri> <tag> <region>"
  exit 1
fi

echo "Building k6 load test image..."
docker build --platform=linux/amd64 -t k6-ecommerce-load-test .
docker tag k6-ecommerce-load-test:latest "$ECR_URI":"$TAG"

echo "Pushing to ECR..."
aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin "$ECR_URI"
docker push "$ECR_URI":"$TAG"

echo "Image successfully pushed to ECR!"

You should be able to find your image in ECR registry.

Step 3: ECS Task Definition Configuration

Create an ECS task definition file (task-definition.json) for your k6 load test:

{
  "family": "k6-ecommerce-load-test",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::YOUR-ACCOUNT:role/YOUR-EXECUTION-ROLE",
  "taskRoleArn": "arn:aws:iam::YOUR-ACCOUNT:role/YOUR-TASK-ROLE",
  "containerDefinitions": [
    {
      "name": "k6-load-test",
      "image": "[your-ecr-uri]:[tag-of-your-image]",
      "essential": true,
      "environment": [
        {
          "name": "RUNTIME_ENV",
          "value": "example"
        },
        {
          "name": "OTHER_ENV",
          "value": "true"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/k6-load-test",
          "awslogs-region": "[your-aws-region]",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

In addition to specifying the AWS region, ECR URI, image tag, and your runtime envs, you must also configure the essential IAM roles required for your ECS task to run successfully. If these roles don't exist in your AWS account, you'll need to create them first.

Below are the basic definitions for both required roles. Keep in mind that every use case is different, so you may need to extend these definitions with additional permissions based on your specific requirements.

Execution Role (for task startup)

{
  "Statement": [
    {
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability"
      ],
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Action": "ecr:GetAuthorizationToken",
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Action": [
        "logs:PutLogEvents",
        "logs:CreateLogStream"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ],
  "Version": "2012-10-17"
}

Task Role (for runtime permissions)

{
  "Statement": [
    {
      "Action": "cloudwatch:PutMetricData",
      "Effect": "Allow",
      "Resource": "*"
    }
  ],
  "Version": "2012-10-17"
}

Create the roles, and copy/paste ARN’s to your task definition.

Also don’t forget to create log group for your logs.

aws logs create-log-group --log-group-name /ecs/k6-load-test

Step 5: Register the Task Definition

aws ecs register-task-definition --cli-input-json file://task-definition.json

Verify the registration in the AWS ECS console under the k6-ecommerce-load-test family.

Step 6: Running Distributed Load Tests

Now the powerful part - running multiple k6 instances simultaneously across your ECS cluster. Here’s the script, fulfill and launch it. I suggest to start with only 1 task, just for safety 😏

#!/bin/bash
# run-distributed-test.sh <number_of_tasks>

CONCURRENT_TASKS=$1

if [ -z "$CONCURRENT_TASKS" ]; then
  echo "Usage: $0 <number_of_tasks>"
  exit 1
fi

# Configuration - Update these values for your environment
CLUSTER_NAME="k6-load-test-cluster"
TASK_DEFINITION="k6-ecommerce-load-test"
SUBNET_ID="subnet-xxxxxxxxx"
SECURITY_GROUP="sg-xxxxxxxxx"

echo "Starting $CONCURRENT_TASKS k6 load test tasks..."

for i in $(seq 1 "$CONCURRENT_TASKS"); do
  echo "Starting task $i of $CONCURRENT_TASKS"
  aws ecs run-task \
    --cluster "$CLUSTER_NAME" \
    --task-definition "$TASK_DEFINITION" \
    --launch-type FARGATE \
    --network-configuration "awsvpcConfiguration={subnets=[$SUBNET_ID],securityGroups=[$SECURITY_GROUP],assignPublicIp=ENABLED}" \
    --tags key=LoadTest,value=true key=TestRun,value="$(date +%Y%m%d-%H%M%S)"
done

echo "All $CONCURRENT_TASKS load test tasks started successfully!"
echo "Monitor progress in AWS ECS console and CloudWatch logs"

Required Configuration Parameters

CLUSTER_NAME: Your ECS cluster name where tasks will be executed. Create one if needed:

aws ecs create-cluster --cluster-name k6-load-test-cluster

TASK_DEFINITION: Your registered task definition name (k6-ecommerce-load-test)

SUBNET_ID: Subnet ID for network configuration (use your default VPC subnet or custom subnet)

SECURITY_GROUP: Security group ID (ensure it allows outbound internet access for your tests, you can also use default one from default VPC)

Cost Optimization Strategies

Running distributed load tests can become expensive without proper optimization. Implement these cost-saving strategies:

1. Leverage Fargate Spot Capacity

Consider using Fargate Spot for non-critical tests, which can provide up to 70% cost savings.

2. Right-size Your Resources

Start with minimal CPU/memory allocations and scale up as needed:

CPU: Begin with 0.5 vCPU and monitor utilization
Memory: Start with 1024MB (1GB) and adjust based on test requirements
Monitor CloudWatch metrics to optimize resource allocation

3. Implement Automatic Cleanup

Ensure tasks terminate after completion to avoid unnecessary charges.

Best Practices and Monitoring for E-commerce Load Testing

Load Testing Best Practices on AWS ECS Fargate

Test in a Staging Environment First – Avoid running load tests directly on production to prevent downtime and customer impact.
Monitor Database Performance Closely – Track queries, indexing, and resource usage to detect bottlenecks early.
Use Geographic Distribution – Run distributed load tests from multiple AWS regions for realistic simulation of global shoppers.

Real-time Metrics Dashboard with Amazon CloudWatch

For distributed load testing with k6 and AWS ECS Fargate, set up CloudWatch dashboards to monitor:

ECS task CPU and memory usage for scaling insights
Test execution progress to identify issues early
Target application response times and throughput to measure real performance

Conclusion

Implementing distributed load testing with k6 and AWS ECS Fargate is one of the most effective ways to ensure your e-commerce website can handle peak traffic without compromising user experience. This scalable, cost-efficient approach allows you to:

Simulate realistic user journeys across thousands of concurrent shoppers
Optimize infrastructure costs through precise resource management
Scale testing environments to meet seasonal or campaign-specific demand
Run tests from multiple geographic regions for global performance insight
Customize test scripts to match your unique business workflows

The combination of k6’s developer-friendly scripting and Fargate’s serverless scalability provides everything you need for online store performance testing—whether you’re preparing for Black Friday, launching a new product, or handling a viral sales spike.
By following this guide to distributed load testing with k6 and AWS ECS Fargate, you’ll be ready to validate and optimize your e-commerce platform’s performance under real-world conditions. Start your first distributed load test today and make sure your digital storefront delivers fast, reliable experiences—even at the busiest times of the year.

Deploying Next.js on AWS: Why We Migrated from Amplify to ECS?

Bartek Gałęzowski — Wed, 30 Jul 2025 12:47:45 +0000

When deploying Next.js applications on AWS, developers face a critical decision between two powerful but fundamentally different platforms: AWS Amplify and AWS ECS (Elastic Container Service). Both offer robust hosting solutions, yet they serve distinct use cases and present unique trade-offs. Understanding these differences is crucial for making an informed architectural decision that will impact your application's performance, scalability, and maintainability.

AWS Amplify: The Developer-First Platform

AWS Amplify represents the modern approach to application deployment, designed specifically for frontend and full-stack applications. As a fully managed service, Amplify abstracts away the complexities of infrastructure management, allowing developers to focus entirely on building features rather than managing servers. This platform excels particularly well with JAMstack applications and provides an remarkably streamlined deployment experience that can get applications from code to production in minutes.

The service shines brightest in its commitment to developer productivity, offering several key advantages:

Zero Infrastructure Management: Developers never need to configure servers, containers, or load balancers
Automatic Scaling: Responds to traffic spikes without manual intervention or pre-configuration
Built-in CI/CD: Git-based deployment workflow with preview environments for every branch
Global CDN: Every deployment automatically leverages CloudFront for worldwide content delivery
SSL Certificates: Automatic HTTPS provisioning and management, even for custom domains
Atomic Deployments: Zero downtime deployments with instant rollback capabilities

However, this simplicity comes with inherent limitations that become apparent as applications grow in complexity:

Limited Runtime Control: Reduced ability to customize the execution environment for specific requirements
Cold Start Latency: Server-side rendering may experience delays during Lambda function initialization
Build Time Constraints: 15-minute timeout limit can restrict larger applications with complex build pipelines
Cache Isolation: Lambda functions cannot share cache between instances, creating performance bottlenecks

The Critical Cache Isolation Problem

Perhaps the most significant limitation of AWS Amplify's architecture lies in its inability to share cache between Lambda function instances. This architectural constraint creates a fundamental problem for applications that rely on server-side caching strategies. Each Lambda execution begins with a fresh container, meaning the Next.js build cache stored in the .next/cache directory cannot persist or be shared between different requests.

In my latest project, our Next.js application was configured to fetch content from Strapi and cache it for reuse across multiple users. While this seems straightforward, Amplify's Lambda-based architecture made it impossible to implement effectively. Since AWS Lambda functions don't run continuously and are destroyed after periods of inactivity, any cached content is lost when the function terminates. New requests trigger fresh Lambda instances, which must make new requests to Strapi since they cannot access previously cached data.

The result was a cascading performance problem where our Strapi instance became severely overloaded with redundant requests that should have been served from cache. This not only degraded application performance but also significantly increased our infrastructure costs due to the needs of increasing resources for Strapi machine, excessive API calls and database queries that could have been avoided with proper caching.

This limitation became the primary driver for looking for a better solution and migrating from Amplify. After weeks of trying various workarounds and caching strategies within Amplify's constraints, it became evident that the solution required a fundamentally different architectural approach. That's when we turned our attention to AWS ECS.

AWS ECS: The Container Orchestration Powerhouse

AWS ECS represents a completely different philosophical approach to application deployment. As a fully managed container orchestration service, ECS provides complete control over your application's runtime environment while still handling the underlying infrastructure management. This platform is particularly well-suited for applications requiring custom configurations, microservices architectures, or specific scaling requirements that go beyond what serverless platforms can offer.

The control that ECS provides is its greatest strength, delivering several significant advantages:

Complete Runtime Control: Customize every aspect from operating system to specific library dependencies
Fine-grained Scaling: Implement custom scaling policies based on CPU, memory, or application-specific metrics
AWS Integration: Seamless access to the entire AWS ecosystem without platform constraints
Consistent Performance: Long-lived containers eliminate cold starts and provide predictable response times
Advanced Networking: VPC integration, custom security groups, and sophisticated load balancing strategies

Yet this power comes with increased complexity that teams must carefully consider:

Infrastructure Knowledge Required: Demands container orchestration expertise that may not exist in all teams
Complex Initial Setup: Significantly more configuration compared to Amplify's one-click deployment
Ongoing Maintenance: Cluster management, task definitions, and capacity planning add operational overhead
Custom Monitoring: Teams must implement their own logging, metrics, and alerting systems

Moving to AWS ECS represented a fundamental shift in our deployment strategy. Unlike Amplify's serverless approach, ECS runs applications in long-lived containers that can maintain state, share cache between requests, and provide the consistent performance our application demanded. This architectural difference immediately solved our caching problems—containers persist for hours or even days, allowing Next.js to build and maintain its cache across multiple requests. The shared cache that was impossible with Lambda became effortless with ECS.

Making the Strategic Decision

The choice between Amplify and ECS should be driven by your specific application requirements and team capabilities rather than general preferences. Amplify excels when you need rapid prototyping capabilities for MVPs and demo applications where time-to-market is critical. Small teams with limited DevOps expertise will find Amplify's managed approach removes significant operational burden while still providing professional-grade infrastructure.

Simple applications that utilize standard Next.js features without complex caching requirements or custom runtime needs are ideal candidates for Amplify. The platform's git-based workflow creates an excellent developer experience for teams that want automatic deployments triggered by repository changes. Applications that need global distribution benefit from Amplify's automatic CDN configuration without requiring additional setup or expertise.

However, you should avoid Amplify if your application relies heavily on server-side caching strategies, as the Lambda-based architecture fundamentally cannot support shared state between requests. Applications with high-frequency API routes that benefit from persistent connections or shared memory will face significant performance constraints. If performance consistency is critical to your user experience, the potential for cold starts in Amplify may be unacceptable. Similarly, applications requiring fine-grained control over caching strategies will find Amplify's managed approach too restrictive.

ECS becomes the preferred choice when you have custom requirements that demand specific runtime configurations or dependencies not supported by managed platforms. Microservices architectures with multiple services requiring complex communication patterns benefit from ECS's networking flexibility and container orchestration capabilities. Applications demanding high performance with consistent, predictable response times will find ECS's always-on container model superior to serverless alternatives.

The shared caching capabilities that ECS enables make it particularly beneficial for applications with expensive computations that can be cached and reused across requests. High-traffic applications requiring consistent performance characteristics will appreciate the elimination of cold starts and the ability to maintain persistent connections and in-memory state. Complex applications with multiple interconnected services can leverage ECS's container orchestration to manage sophisticated deployment patterns and service communication.

Enterprise applications often gravitate toward ECS due to its comprehensive security and compliance capabilities, along with the ability to integrate with existing containerized services in hybrid architectures. Teams with existing container expertise will find ECS's model familiar and powerful, allowing them to leverage their existing knowledge and tooling.

Conclusion: Aligning Technology with Requirements

The beauty of AWS's ecosystem lies in its evolutionary path. Many applications (including mine) begin their journey on Amplify, taking advantage of its rapid deployment capabilities and managed infrastructure to achieve fast time-to-market. As applications grow in complexity and requirements become more sophisticated, migrating to ECS becomes a natural progression rather than a fundamental architecture change.

Both platforms represent excellent choices within their respective domains, and neither is inherently superior to the other. The key is understanding your current requirements, anticipated growth patterns, and team capabilities. Start with the platform that best matches your immediate needs while keeping an eye on future requirements that might necessitate a different approach.

Remember that the best architectural decision is one that aligns with your team's expertise, project requirements, and long-term strategic goals. Both Amplify and ECS will serve your Next.js applications exceptionally well when chosen appropriately for your specific context and requirements.

Unleashing the power of serverless: a deep dive into web form deployment with our serverless plugin

Bartek Gałęzowski — Wed, 25 Jun 2025 06:27:00 +0000

Web forms are the lifeblood of online interaction, serving as the primary conduit between users and web services. However, deploying these forms can often feel like navigating a labyrinth. Fear not, as we're here to guide you through this maze.

In this post, we'll dissect the anatomy of form deployment, comparing the traditional server-side method with the modern serverless approach. We'll also shed light on why serverless may be the best choice, discuss the security measures against bots, and provide a step-by-step guide on how to swiftly and effortlessly create and deploy a form using @uninterrupted/serverless-plugin-webform.

Server-side vs. Serverless

Server-side and serverless computing are two different approaches to building and running applications. With server-side computing, the developer is responsible for provisioning and managing servers, while with serverless computing it is handled by the cloud provider. Server-side computing is more traditional, while serverless computing is a newer approach that is gaining popularity.

The Old Fellow: Server-side Deployment

Server-side deployment is the old fellow of deploying web forms. In this approach, the server shoulders all the logic related to the form. It's a bit like being a one-man band. It can be a time-consuming and costly endeavor. In the traditional server-side approach, web forms rely on a dedicated server to handle form submissions. This involves setting up and maintaining server infrastructure, managing databases, and handling user requests/form submissions. While this method has been the norm for years, it comes with several challenges:

Scalability and Cost: Scaling server resources to accommodate varying traffic levels can be complex and costly. Over-provisioning leads to unnecessary expenses, while under-provisioning results in performance issues.
Maintenance: Traditional server setups demand continuous maintenance, including security updates, database management, and server monitoring. This can be time-consuming and require technical expertise.
Complex Deployment: Deploying updates to forms or making changes often involves multiple steps, increasing the chances of errors or downtime.

The New Kid on the Block: Serverless Deployment

Enter serverless deployment, the new kid on the block. This modern approach takes the server management load off your shoulders. It allows you, the developer, to focus on your code, while the infrastructure is handled by the serverless provider. The result? Faster deployment, lower costs, and improved scalability. The serverless approach revolutionizes form deployment by eliminating the need for dedicated servers. It leverages cloud services to handle form submissions dynamically, scaling automatically based on demand. Key benefits include:

Auto-scaling: Serverless platforms like AWS Lambda or Azure Functions automatically scale resources based on traffic, ensuring optimal performance without manual intervention.
Cost Efficiency: With serverless, you pay only for the actual usage, making it more cost-effective as you're not charged for idle resources.
Simplified Deployment: Serverless frameworks provide streamlined deployment pipelines, enabling quick updates and reducing the risk of deployment errors.
Faster Development: By abstracting server management, developers can focus on building the form's functionality rather than dealing with infrastructure.

Securing the Digital Neighbourhood

Much like a safe and secure neighborhood, our web forms too require protection from lurking threats, often manifesting as relentless bots. In the realm of web forms, security stands as the guardian defending the estate against thieves use the watchful eye of the honeypot and the housing estate barrier of reCaptcha.

The Watchful Eye - Honeypot

Imagine strolling down your friendly neighborhood street, where houses are welcoming and familiar. Among them, a house stands with an unseen, yet effective, guardian – a concealed pitfall that only trespassers unwittingly fall into. Similarly, a web form armed with a honeypot possesses an invisible field, lying in wait for bots that blindly wander through. While legitimate visitors tread without concern, bots stumble into this trap, instantly revealing their true identity. This quiet sentinel may not deter all invaders, but it thwarts those who are less cunning, keeping the virtual streets cleaner and safer.
The honeypot technique is a cybersecurity strategy designed to detect, deflect, or study unauthorized access or malicious activity within a controlled environment. It involves setting up decoy systems, services, or resources that appear to be legitimate targets for attackers but are isolated from the main network infrastructure. The primary purpose of a honeypot is to gather valuable information about the tactics, techniques, and procedures (TTPs) employed by cybercriminals, thereby enhancing an organization's ability to defend against real-world threats.

Honeypots can be categorized into different types based on their goals and deployment:

Production Honeypots: These are designed to appear as normal systems or services within the organization's network. The intention is to observe and divert attackers from real assets while gathering information on their activities.
Research Honeypots: These are more elaborate and specialized systems that focus on in-depth analysis of an attacker's behavior. They often capture detailed information about the attack methods, such as the malware used, command and control traffic, and exploitation techniques.
High-Interaction Honeypots: These mimic actual systems and services to a high degree, providing attackers with a realistic environment. While they offer detailed insights, they are also more resource-intensive to maintain and require careful isolation to prevent unauthorized access to the main network.
Low-Interaction Honeypots: These are simpler decoy systems that emulate only a limited set of services, reducing the risk of an attacker gaining full access. They are easier to manage and deploy, but may not provide as much detailed information about attacker behavior.

Benefits of using the honeypot technique include:

Early Threat Detection: Honeypots can detect attacks that go unnoticed by traditional security measures. By attracting and engaging potential attackers, organizations can identify new attack vectors or vulnerabilities.
Behavioral Analysis: Detailed logs and data collected from honeypots can be analyzed to understand attackers' methods, tools, and motives. This information helps organizations improve their cybersecurity strategies.
Reduced False Positives: Since honeypots are isolated from critical infrastructure, any activity detected within them is highly likely to be malicious, reducing false positive alerts.
Experiential Learning: Cybersecurity professionals can gain hands-on experience with real-world attack scenarios in a controlled environment, enhancing their skills and understanding of threats.

In conclusion, the honeypot technique is a valuable tool in the cybersecurity arsenal, providing organizations with insights into emerging threats and attackers' methods. However, its implementation requires careful planning, management, and consideration of potential risks to ensure its effectiveness in enhancing overall security posture.

The Robust Barrier - reCaptcha

Picture your neighborhood equipped with an advanced security gate, challenging those who seek entry. This gate, known as reCaptcha, tasks newcomers with puzzles that distinguish between human interaction and automated trickery. Like a well-trained guard, reCaptcha vouches for genuine residents, while raising an alarm for suspicious characters. Whether it's a simple checkbox or a complex image recognition puzzle, reCaptcha adds an extra layer of protection to our digital community, deterring nefarious bots from entering our online neighborhood.
reCAPTCHA, short for "Completely Automated Public Turing test to tell Computers and Humans Apart," is a widely used security technology developed by Google to distinguish between human users and automated bots on the internet. It was initially introduced as a way to prevent bots from abusing online services, such as submitting forms, creating accounts, or making purchases, while allowing legitimate human users to access these services without unnecessary friction.

The primary purpose of reCAPTCHA is to provide an additional layer of security to various online platforms by challenging users to prove their human identity through a series of tests that are easy for humans to solve but difficult for automated bots. Over the years, reCAPTCHA has evolved to include several versions, each designed to address different security and user experience needs.

Here are some key aspects of reCAPTCHA:

CAPTCHA Challenges: reCAPTCHA typically presents users with challenges that require cognitive or perceptual skills that bots find difficult to replicate. These challenges have included identifying distorted text, selecting specific images from a grid, or simply checking a box to confirm their human status.
Types of reCAPTCHA:

reCAPTCHA v2 "I'm not a robot": This version introduced the checkbox-style CAPTCHA where users simply need to click on the checkbox to verify their humanity. It often relies on behavioral analysis to determine whether a user is human or not.
reCAPTCHA v2 "Invisible reCAPTCHA": This version is even less intrusive, as it runs in the background and only displays a CAPTCHA challenge if the system suspects the user might be a bot.
reCAPTCHA v3: This version focuses on passive user verification. It assigns a risk score to each user interaction, allowing site owners to take action based on the perceived risk level. It doesn't require any explicit user interaction.

Advanced Technology: Google uses a variety of technologies, including machine learning and advanced risk analysis, to continuously improve the accuracy of distinguishing humans from bots. These technologies help reduce the likelihood of false positives (incorrectly identifying humans as bots) and false negatives (failing to identify bots).
Integration: Website owners can integrate reCAPTCHA into their platforms by including Google's reCAPTCHA API in their code. Google provides detailed documentation on how to implement and customize reCAPTCHA to suit the website's needs.
User Experience Considerations: While reCAPTCHA serves as a security measure, it's important to consider user experience. Overly complex challenges can frustrate users and discourage them from using a website. Balancing security with a user-friendly interface is crucial.
Accessibility: Google has taken steps to make reCAPTCHA more accessible to users with disabilities. For example, audio challenges are provided for visually impaired users who may have difficulty with visual challenges.

In recent years, the evolution of reCAPTCHA has led to debates about its effectiveness, user privacy concerns, and the potential for unintended consequences. Some users find certain challenges, especially those involving image recognition, to be frustrating or time-consuming. Additionally, there are concerns about the amount of behavioral data that Google collects as users interact with reCAPTCHA challenges.

In conclusion, reCAPTCHA plays a significant role in safeguarding online platforms from automated bots and enhancing overall cybersecurity. However, its implementation should be balanced with user experience considerations and privacy concerns to ensure a seamless and secure online environment for both humans and legitimate users.

An Impenetrable Alliance

Much like a vigilant neighborhood combining security systems, the strategic union of honeypot and reCaptcha forms an impervious barrier against the dragon of bots. While the honeypot lures and traps the naive intruders, reCaptcha stands tall as the fortified castle gate, testing the mettle of even the craftiest foes. By employing both methods, we build a formidable defense, ensuring that our virtual streets remain safe for residents while deterring those who aim to exploit our online community.

In the ever-evolving landscape of the web, where bots prowl like shadowy figures, the harmonious coexistence of honeypot and reCaptcha serves as our armor. Just as a tight-knit neighborhood watches out for its own, these security measures safeguard our digital spaces, enabling seamless interactions for genuine users while safeguarding against the encroaching darkness of automated threats.

The Neighborhood Builder: Streamlined Form Deployment with @uninterrupted/serverless-plugin-webform

@uninterrupted/serverless-plugin-webform plugin is your guide to easy and secure form deployment. Here's how it works:

Begin with installing the plugin. Run the following command in your terminal within your serverless project:

npm install --save-dev uninterrupted-tech/serverless-plugin-webform

You can also use other package managers such as yarn or pnpm.

yarn add --dev @uninterrupted/serverless-plugin-webform

pnpm add --save-dev @uninterrupted/serverless-plugin-webform

After that you have to add the plugin to your serverless.yaml file. To do this add the name of the plugin to the plugins array:

plugins:
    - @uninterrupted/serverless-plugin-webform

Configure the plugin according to your preferences. Add or extend the custom property in your serverless.yaml file by pluginWebform. Here we will place all configuration of the plugin.

custom:
  pluginWebform:

The plugin has been designed with the intention of automating the form deployment process as much as possible. However, there is one property that requires user input: the configuration for Amazon Simple Email Service.

Amazon Simple Email Service is responsible for sending email notifications when someone fill the form and for sending email confirmation to the visitor. Since the email notification feature is optional, the visitor email confirmation is not, and you have to fill in the configuration of the email address from which the emails will be sent.

To do this, add a new property to your configuration named ses which stands for Simple Email Service, and set the sourceAddress property.

custom:
  pluginWebform:
        ses:
            sourceAddress: hello@uninterrupted.tech

That is actually all that is required. You can deploy the service with the default configuration.

serverless deploy

As a result, you will receive an endpoint to Amazon API Gateway that will execute the lambda function.

Detailed configuration

However, as the creators, we want to make it as flexible and configurable as possible. So, let's dive a bit deeper. In the next section we will guide you through each part of plugin configuration.

Simple Email Service (SES)

As mentioned earlier, the ses section contains the configuration for Amazon Simple Email Service

ses:
  sourceAddress: source@address.com
  notificationAddresses:
    - notification@address.com
    - notification@address2.com
  visitorNotification:
    subject: "New message"
    text: ./templates/visitor-notification.txt
    html: ./templates/visitor-notification.html
  visitorConfirmation:
    subject: Hello {{ name }}!
    text: ./templates/visitor-confirmation.txt
    html: ./templates/visitor-confirmation.html
  visitorConfirmationWitMessage:
    subject: Hello {{ name }}!
    text: ./templates/visitor-confirmation-with-message.txt
    html: ./templates/visitor-confirmation-with-message.html

sourceAddress - email address from which the emails will be sent,

notificationAddresses - You can add as many notification addresses as you need. When the array will contain at least one element, the lambda function will send a notification about new visitor to the email address. We intended to provide a functionality to notify admins, form owners, and maintainers about new visitors. If you do not configure the visitor notification property, it will be disabled.

visitorNotification - the optional notification email template configuration property. If no value is provided, the lambda will use the default template. Otherwise, you must fill three fields to provide your own template:

subject - contains a subject of the email. You can use replacement tags here, such as {{ name }}. The replacement tags are used to personalize the email by inserting dynamic content, such as the recipient's name, into the subject line. The plugin documentation will provide a list of all the available replacement tags.
html - contains path from root directory to your .html template message. You can also use replacement tags here.
text - contains path from root directory to your .txt template message. You can also use replacement tags here.

Note: The HTML file is used to define the visual appearance of the email. However, some email clients may not display HTML emails correctly. To ensure that all recipients can read your email, you should also define a plain text version.

visitorConfirmation - The template is optional and can be used to send a confirmation message to the visitor. The configuration is the same for both the HTML and text templates.

visitorConfirmationWithMessage - The template can be used to send a confirmation message with the message/description provided in the form. The lambda function will use this template if the ccMe property in the API request is set to true. The template is optional.

Properties/Honeypot technique

As explained, the honeypot technique is a way to protect your forms from spam bots. Bots will usually fill out all of the fields searching for a common patterns. This way, you can identify spam bots and block them from submitting your form.

To use the honeypot technique, you need to configure the properties property in a configuration. This property is a mapping between a property and its value. The name property is an alias of the real field.
As an example instead of email: hello@uninterrupted.tech we will send ssadads: hello@uninterrupted.tech.

properties:
  email:
    name: ssadads
  name:
    name: wmhhgio
  phoneNumber:
    name: idocynv
  description:
    name: xhqpdaf

Configuration allows to configure four properties:

email,
name,
phoneNumber, and
description.

The properties section is optional. If you do not provide any configuration, the honeypot technique will not be used.

reCAPTCHA

reCAPTCHA is a more advanced security mechanism that helps identify and block abusive traffic on a website. reCAPTCHA v3 does this without interrupting users with CAPTCHA challenges. Instead, reCAPTCHA v3 returns a score that you can use to decide how to handle each request. The reCAPTCHA configuration is quite simple and requires configuration of captcha property.

captcha:
  secret: secret
  threshold: 0.8

secret - reCAPTCHA secret value,
threshold - the score threshold. Requests with a score less than the threshold will be blocked and reported.

The captcha section is optional. If you do not fill it out, the CAPTCHA will be turned off. If you provide the secret property, the CAPTCHA will be enabled. However, it is important to never load the secret using an environment variable or put sensitive data directly in your code.

The default value for the threshold is 0.5. You can experiment with different values to find the best threshold for your needs. Here you can learn more about the score threshold and learn how to configure reCAPTCHA and generate secret.

Lambda function

This section covers the technical aspects of the configuration, specifically the Lambda function settings. While it is optional, you can modify the Lambda function name if you need to increase its resources or if the default name is already in use. The configuration is under the lambda property.

lambda:
  name: myLambda
  memorySize: 512

name - the Lambda function name. Combined with the service and deployment stage name to form a unique identifier. The format is: ${serviceName}${stageName}${lambdaName}. The default value is createVisitor.
memorySize - specifies the amount of memory and computing power allocated to the lambda function, measured in megabytes. The default value is 1024MB.

DynamoDB

DynamoDB is a fully managed, serverless, key-value NoSQL database. Here, we use it to store information about visitors and bots (e.g., data provided and reCAPTCHA details). Since two tables are required (one for visitors and one for bots), we have added the possibility to configure the names of the databases to prevent naming conflicts. The table name is a concatenation of the service and stage names, following the format:
${serviceName}${stageName}${tableName}, similarly to the Lambda naming convention applied previously. This configuration is located under the dynamoDb property and is entirely optional. When not provided, tables will be named using default values: visitors and bot-visitors.

dynamoDb:
  visitorsTableName: contacts
  botVisitorsTableName: bot-contacts

visitorsTableName - property specifies the name of the table where comprehensive visitor information will be stored. The default value is visitors.
botVisitorsTableName - property specifies the name of the table dedicated to storing data regarding bot visitors. The default value is bot-visitors.

Slack integration

Slack is a popular communication tool used by many organizations. We use it ourselves, and that's why we decided to add support for Slack notifications to our plugin. You can configure Slack notifications to be sent for new visitors. This is an optional feature, but the setup process is straightforward. The configuration for Slack is under the slack property.

slack:
  url: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
  channel: "#web-form-notifications"
  username: webhook-bot
  message: ./slack/message.txt
  iconEmoji: ":email:"

url - Slack incoming webhook URL. Please refer to the instruction on how to generate the Slack incoming webhook URL,
channel - name of an existing channel in your Slack organization where notifications will be sent,
username - the username of the message sender,
message - path from the root directory to your .txt template message. Within this file, you can define the appearance of your messages. Similar to the SES templates you can also use replacement tags here,
iconEmoji - refers to the icon emoji of the channel. You can choose from a variety of emojis listed here. By default emoji is "📧" :email:.

Conclusion

In the ever-evolving landscape of web development, the deployment of web forms has transitioned from the traditional server-side approach to the modern serverless paradigm. This shift has brought about enhanced scalability, reduced costs, simplified deployment processes, and faster development cycles. To fortify the security of our digital neighborhoods against the onslaught of automated threats, the strategic alliance of honeypot and reCaptcha techniques provides a robust defense. In conclusion, the synergy between serverless deployment, honeypot and reCaptcha security techniques, and the @uninterrupted/serverless-plugin-webform plugin transforms the deployment and protection of web forms into a seamless and efficient process. By leveraging these tools, developers can enhance user experiences, bolster security measures, and contribute to the creation of a safer and more user-friendly digital environment.

Hassle free Redis Cluster deployment using Docker

Bartek Gałęzowski — Wed, 25 Jun 2025 06:24:46 +0000

Distributed Redis Cluster is an efficient solution for applications that require a scalable and reliable data store. Redis Cluster enables automatic data partitioning and replication within the cluster, ensuring high availability and fault tolerance. In this article, we will discuss how to run Redis Cluster using Docker.

We will start by preparing and describing in detail the Docker Compose file with Redis Cluster. To accomplish this, we will utilize the bitnami/redis-cluster image, which will enable us to run six containers (Redis Nodes), with one of them being designated as responsible for creating the cluster.

The cluster consists of nodes categorized as masters and slaves. Each master node can have one or multiple assigned slaves, which essentially act as replicas of the master. In the event of a master node failure, its corresponding slave node automatically takes over and becomes the new master. This mechanism ensures high availability within the cluster.

Composing a multi-container Redis Cluster

x-redis-base: &redis-base
  image: docker.io/bitnami/redis-cluster:7.0.10
  environment:
    ALLOW_EMPTY_PASSWORD: yes
    REDIS_NODES: redis-node-0 redis-node-1 redis-node-2 redis-node-3 redis-node-4 redis-node-5

The anchor contains the fundamental configuration for the Redis node. The presence of ALLOW_EMPTY_PASSWORD permits connecting to the cluster without requiring credentials, which aligns with our requirements.

Note that this article shows setup for development purposes, but we encourage to use authentication everywhere.

Additionally, REDIS_NODES comprises the hostnames of all nodes that will constitute the cluster, separated by spaces.
Once we have created the anchor with the basic configuration, we can utilize it to generate five individual nodes.

redis-node-0:
  container_name: redis-node-0
  <<: *redis-base
redis-node-1:
  container_name: redis-node-1
  <<: *redis-base
redis-node-2:
  container_name: redis-node-2
  <<: *redis-base
redis-node-3:
  container_name: redis-node-3
  <<: *redis-base
redis-node-4:
  container_name: redis-node-4
  <<: *redis-base

The last, sixth node (redis-node-5), will have the specific role of establishing the cluster by setting the REDIS_CLUSTER_CREATOR parameter.

redis-node-5:
  container_name: redis-node-5
  <<: *redis-base
  depends_on:
    - redis-node-0
    - redis-node-1
    - redis-node-2
    - redis-node-3
    - redis-node-4
  environment:
    ALLOW_EMPTY_PASSWORD: yes
    REDIS_NODES: redis-node-0 redis-node-1 redis-node-2 redis-node-3 redis-node-4 redis-node-5
    REDIS_CLUSTER_REPLICAS: 1
    REDIS_CLUSTER_CREATOR: yes

I set REDIS_CLUSTER_REPLICAS: 1 what based on six nodes give us three masters and three slaves.

Now our docker-compose file looks like below:

x-redis-base: &redis-base
  image: docker.io/bitnami/redis-cluster:7.0.10
  environment:
    ALLOW_EMPTY_PASSWORD: yes
    REDIS_NODES: redis-node-0 redis-node-1 redis-node-2 redis-node-3 redis-node-4 redis-node-5

services:
  redis-node-0:
    container_name: redis-node-0
    <<: *redis-base
  redis-node-1:
    container_name: redis-node-1
    <<: *redis-base
  redis-node-2:
    container_name: redis-node-2
    <<: *redis-base
  redis-node-3:
    container_name: redis-node-3
    <<: *redis-base
  redis-node-4:
    container_name: redis-node-4
    <<: *redis-base

  redis-node-5:
    container_name: redis-node-5
    <<: *redis-base
    depends_on:
      - redis-node-0
      - redis-node-1
      - redis-node-2
      - redis-node-3
      - redis-node-4
    environment:
      ALLOW_EMPTY_PASSWORD: yes
      REDIS_NODES: redis-node-0 redis-node-1 redis-node-2 redis-node-3 redis-node-4 redis-node-5
      REDIS_CLUSTER_REPLICAS: 1
      REDIS_CLUSTER_CREATOR: yes

Let's execute docker-compose up to run the Redis Cluster.

redis-node-5  | >>> Performing Cluster Check (using node 172.18.0.2:6379)
redis-node-5  | M: 025420b382c7d631ebfe4959b346eaf255caeaba 172.18.0.2:6379
redis-node-5  |    slots:[0-5460] (5461 slots) master
redis-node-5  |    1 additional replica(s)
redis-node-5  | S: 1d693ab3d6b630768359615889bfcdc69642cea3 172.18.0.5:6379
redis-node-5  |    slots: (0 slots) slave
redis-node-5  |    replicates 025420b382c7d631ebfe4959b346eaf255caeaba
redis-node-5  | M: 9239ec8481a3ec411dd0f2f832d0f7a4b07472ef 172.18.0.6:6379
redis-node-5  |    slots:[10923-16383] (5461 slots) master
redis-node-5  |    1 additional replica(s)
redis-node-5  | S: 4d8b42ab42c2f589f31ea2310ccc630a899d71f1 172.18.0.7:6379
redis-node-5  |    slots: (0 slots) slave
redis-node-5  |    replicates 9c5e768c2aaae24e48bb62c0be8395d13592a940
redis-node-5  | S: 07fc9c307fc4fca6371e8832821638d412c8c350 172.18.0.4:6379
redis-node-5  |    slots: (0 slots) slave
redis-node-5  |    replicates 9239ec8481a3ec411dd0f2f832d0f7a4b07472ef
redis-node-5  | M: 9c5e768c2aaae24e48bb62c0be8395d13592a940 172.18.0.3:6379
redis-node-5  |    slots:[5461-10922] (5462 slots) master
redis-node-5  |    1 additional replica(s)
redis-node-5  | [OK] All nodes agree about slots configuration.
redis-node-5  | >>> Check for open slots...
redis-node-5  | >>> Check slots coverage...
redis-node-5  | [OK] All 16384 slots covered.
redis-node-5  | Cluster correctly created

Created!

Connecting to the Redis Cluster

Next, let's consider a hypothetical scenario where we have an application that needs to connect to our Redis Cluster. This application is also executed within a Docker container so shares the same network. To simulate the application connection we will connect to our cluster using redis-cli from within one of the created containers.

Let’s run docker ps to list all containers.

❯ docker ps
CONTAINER ID   IMAGE                          COMMAND                  CREATED              STATUS              PORTS      NAMES
4a0e6c6ce02a   bitnami/redis-cluster:7.0.10   "/opt/bitnami/script…"   About a minute ago   Up About a minute   6379/tcp   redis-node-5
ff2570e6567c   bitnami/redis-cluster:7.0.10   "/opt/bitnami/script…"   About a minute ago   Up About a minute   6379/tcp   redis-node-2
18b9f0a68e87   bitnami/redis-cluster:7.0.10   "/opt/bitnami/script…"   About a minute ago   Up About a minute   6379/tcp   redis-node-1
2375812e5c93   bitnami/redis-cluster:7.0.10   "/opt/bitnami/script…"   About a minute ago   Up About a minute   6379/tcp   redis-node-0
492f879f178c   bitnami/redis-cluster:7.0.10   "/opt/bitnami/script…"   About a minute ago   Up About a minute   6379/tcp   redis-node-3
77e0549a66a8   bitnami/redis-cluster:7.0.10   "/opt/bitnami/script…"   About a minute ago   Up About a minute   6379/tcp   redis-node-4

And now use docker exec to go into the selected container:

❯ docker exec -it 4a0e6c6ce02a sh

Okay, now we are in and we can run redis-cli

$ redis-cli -c
127.0.0.1:6379>

It looks that everything is functioning properly. However, to verify whether our cluster is correctly configured, let's execute the CLUSTER NODES command to retrieve a list of all nodes within the cluster.

127.0.0.1:6379> CLUSTER NODES
82d2bee961c7a4b73f099550d72a232e55d12d60 172.18.0.2:6379@16379 master - 0 1683707451345 2 connected 5461-10922
e09bd0f03f71d5ca9e1db6804ac28f2470eb70db 172.18.0.7:6379@16379 myself,slave 82d2bee961c7a4b73f099550d72a232e55d12d60 0 1683707449000 2 connected
8cb609962e074807b56f1a01bbbde3e6a436e7ca 172.18.0.3:6379@16379 master - 0 1683707450331 1 connected 0-5460
7dd24d5ffc732189f7b32a5468d9b20ebc1f60d7 172.18.0.5:6379@16379 master - 0 1683707450000 3 connected 10923-16383
c02f2c7285074d9d5b23b8faf07ec287c6e94636 172.18.0.4:6379@16379 slave 8cb609962e074807b56f1a01bbbde3e6a436e7ca 0 1683707449316 1 connected
5105b2780cabbff516e0f834a694bcdca310e8b7 172.18.0.6:6379@16379 slave 7dd24d5ffc732189f7b32a5468d9b20ebc1f60d7 0 1683707448291 3 connected

Based on the provided information, we have a Redis Cluster consisting of three masters and three slaves, with each master having its corresponding slave. The "myself" indicator specifies the node to which we are currently connected.

Now, let's proceed to set a value in the cluster.

127.0.0.1:6379> SET key "value"
-> Redirected to slot [12539] located at 172.18.0.5:6379
OK

Voilà! Thanks to the -c flag, which runs redis-cli in cluster mode, we have been redirected to the master node responsible for slot 12539, allowing us to write our value.

No problemo, but…

Outside Docker Network

Imagine that your hypothetical application is not ready yet, and you would like to expose Redis Cluster outside of the Docker network. This will give you the possibility to develop application without the need to run it in Docker with every change you made. To achieve this, we will make some modifications to our cluster creator container (redis-node-5).

redis-node-5:
  container_name: redis-node-5
  <<: *redis-base
  depends_on:
    - redis-node-0
    - redis-node-1
    - redis-node-2
    - redis-node-3
    - redis-node-4
  ports:
    - 6379:6379
  environment:
    ALLOW_EMPTY_PASSWORD: yes
    REDIS_NODES: redis-node-0 redis-node-1 redis-node-2 redis-node-3 redis-node-4 redis-node-5
    REDIS_CLUSTER_REPLICAS: 1
    REDIS_CLUSTER_CREATOR: yes

We’ve added the "ports" keyword, which maps the local port 6379 to port 6379 inside the Docker network. As a result, we should now be able to connect to the Redis Cluster from the local network (local terminal).

❯ redis-cli -c
127.0.0.1:6379> CLUSTER NODES
4359876c953a0d1577b75203cddde191b2ac69bc 172.20.0.4:6379@16379 slave 5c7b8bd362ff414ac41861ea8cf5758a1d981bcc 0 1683709816000 3 connected
a95eb7d5b68e925bc8adff2ee79cf2384889a5c2 172.20.0.6:6379@16379 master - 0 1683709816687 2 connected 5461-10922
5c7b8bd362ff414ac41861ea8cf5758a1d981bcc 172.20.0.3:6379@16379 master - 0 1683709814651 3 connected 10923-16383
440ec475bf64e1496ba661b3f7ac49a77f2379cc 172.20.0.5:6379@16379 slave ce88b4c234d6e7203ef94c5970cd85ca38c4bce0 0 1683709816000 1 connected
de7b60d66e94a2905afd5d450bd2029690564f74 172.20.0.7:6379@16379 myself,slave a95eb7d5b68e925bc8adff2ee79cf2384889a5c2 0 1683709815000 2 connected
ce88b4c234d6e7203ef94c5970cd85ca38c4bce0 172.20.0.2:6379@16379 master - 0 1683709815665 1 connected 0-5460

And setting a value…

127.0.0.1:6379> SET key "value"
-> Redirected to slot [12539] located at 172.20.0.3:6379
Could not connect to Redis at 172.20.0.3:6379: Operation timed out
(75.00s)

Oops... Redis is unable to connect to the master behind 172.22.0.3:6379. However, if we think about it, the reason becomes apparent. As mentioned earlier, we were attempting to set a key, but we can not do that because we were connected to a slave node (indicated by the "myself" tag). When we asked Redis about the location of "our master," Redis responded with "Okay, you have to connect to 172.20.0.3:6379". However, since we didn't expose every node outside of the Docker network, we received an "Operation timed out" error, we don’t see other nodes. And here begins our problem...

Oh, wait! Are you Linux user? You’re lucky man!

In Linux we are able to use network host mode, in this mode the container shares the network stack of the host, meaning it uses the host's network interfaces directly, so allows us to use localhost.

All we have to do is to add network_mode: host for each node (I’ve added it in anchor), add REDIS_PORT_NUMBER environment for each node and modify REDIS_NODES.

version: "3.7"

x-redis-base: &redis-base
  image: docker.io/bitnami/redis-cluster:7.0.10
  network_mode: host

services:
  redis-node-0:
    container_name: redis-node-0
    <<: *redis-base
    environment:
      REDIS_PORT_NUMBER: 6370
      REDIS_NODES: 127.0.0.1:6370 127.0.0.1:6371 127.0.0.1:6372 127.0.0.1:6373 127.0.0.1:6374 127.0.0.1:6375
      ALLOW_EMPTY_PASSWORD: yes
  redis-node-1: 
    container_name: redis-node-1
    <<: *redis-base
    environment:
      REDIS_PORT_NUMBER: 6371
      REDIS_NODES: 127.0.0.1:6370 127.0.0.1:6371 127.0.0.1:6372 127.0.0.1:6373 127.0.0.1:6374 127.0.0.1:6375
      ALLOW_EMPTY_PASSWORD: yes
  redis-node-2:
    container_name: redis-node-2
    <<: *redis-base
    environment:
      REDIS_PORT_NUMBER: 6372 
      REDIS_NODES: 127.0.0.1:6370 127.0.0.1:6371 127.0.0.1:6372 127.0.0.1:6373 127.0.0.1:6374 127.0.0.1:6375
      ALLOW_EMPTY_PASSWORD: yes
  redis-node-3:
    container_name: redis-node-3
    <<: *redis-base
    environment:
      REDIS_PORT_NUMBER: 6373
      REDIS_NODES: 127.0.0.1:6370 127.0.0.1:6371 127.0.0.1:6372 127.0.0.1:6373 127.0.0.1:6374 127.0.0.1:6375
      ALLOW_EMPTY_PASSWORD: yes
  redis-node-4:
    container_name: redis-node-4
    <<: *redis-base
    environment:
      REDIS_PORT_NUMBER: 6374
      REDIS_NODES: 127.0.0.1:6370 127.0.0.1:6371 127.0.0.1:6372 127.0.0.1:6373 127.0.0.1:6374 127.0.0.1:6375
      ALLOW_EMPTY_PASSWORD: yes
  redis-node-5:
    container_name: redis-node-5
    <<: *redis-base
    depends_on:
      - redis-node-0
      - redis-node-1
      - redis-node-2
      - redis-node-3
      - redis-node-4
    environment:
      REDIS_PORT_NUMBER: 6375
      REDIS_NODES: 127.0.0.1:6370 127.0.0.1:6371 127.0.0.1:6372 127.0.0.1:6373 127.0.0.1:6374 127.0.0.1:6375
      ALLOW_EMPTY_PASSWORD: yes
      REDIS_CLUSTER_REPLICAS: 1
      REDIS_CLUSTER_CREATOR: yes

docker compose up and testing

~$ redis-cli -c -h 127.0.0.1 -p 6375
127.0.0.1:6375> CLUSTER NODES
88d08d5a84f7f9879623111c4b3bae028e465d0a 127.0.1.1:6373@16373 slave a816a5d3484177bb90c86e59d1a93a1e81d4bb2d 0 1683801476781 3 connected
69ab6dbf70298ffe19f388440703f30de177e59f 127.0.1.1:6370@16370 master - 0 1683801475761 1 connected 0-5460
b1ab22f03c0c99f17dce4980944d7180f94c154c 127.0.1.1:6371@16371 master - 0 1683801474743 2 connected 5461-10922
a816a5d3484177bb90c86e59d1a93a1e81d4bb2d 127.0.1.1:6372@16372 master - 0 1683801476000 3 connected 10923-16383
9a79480966b1da9a7f10e5c7304b0c3463e93176 127.0.1.1:6375@16375 myself,slave b1ab22f03c0c99f17dce4980944d7180f94c154c 0 1683801475000 2 connected
ebf22feb960eeaf1a7642deec1910a182e900c6f 127.0.1.1:6374@16374 slave 69ab6dbf70298ffe19f388440703f30de177e59f 0 1683801476000 1 connected

As you can see we have all nodes run on the same host, but on different ports. Let’s try set our test value.

127.0.0.1:6375> SET key "value"
-> Redirected to slot [12539] located at 127.0.1.1:6372
OK

Okay! We’ve redirected from the node running on 127.0.0.1:6375 to 127.0.0.1:6372, and were able to write the value without any issues.

Are you macOS user? Solution is more complex

Unlike Linux, other operating systems, such as macOS, spins-up Linux VM under the hood which makes real host networking unavailable. To resolve this problem, we need to expose each node outside the Docker network on the same host but on different ports. However, determining the exact host to set becomes challenging. We cannot use 127.0.0.1. Instead, we can obtain the external host IP and utilize it in both REDIS_NODES and REDIS_CLUSTER_ANNOUCE_IP configurations to ensure proper communication.

To receive your current external host IP you can use:

echo "$(route get uninterrupted.tech | grep interface | sed -e 's/.*: //' | xargs ipconfig getifaddr)"

My IP is 10.0.18.181 so Docker Compose will looks like below:

version: "3.7"

x-redis-base: &redis-base
  image: docker.io/bitnami/redis-cluster:7.0.10

services:
  redis-node-0:
    container_name: redis-node-0
    <<: *redis-base
    ports:
      - 6370:6370
      - 16370:16370
    environment:
      REDIS_CLUSTER_DYNAMIC_IPS: no
      REDIS_CLUSTER_ANNOUNCE_IP: 10.0.18.181
      REDIS_PORT_NUMBER: 6370
      ALLOW_EMPTY_PASSWORD: yes
      REDIS_NODES: 10.0.18.181:6370 10.0.18.181:6371 10.0.18.181:6372 10.0.18.181:6373 10.0.18.181:6374 10.0.18.181:6375
  redis-node-1:
    container_name: redis-node-1
    <<: *redis-base
    ports:
      - 6371:6371
      - 16371:16371
    environment:
      REDIS_CLUSTER_DYNAMIC_IPS: no
      REDIS_CLUSTER_ANNOUNCE_IP: 10.0.18.181
      REDIS_PORT_NUMBER: 6371
      ALLOW_EMPTY_PASSWORD: yes
      REDIS_NODES: 10.0.18.181:6370 10.0.18.181:6371 10.0.18.181:6372 10.0.18.181:6373 10.0.18.181:6374 10.0.18.181:6375
  redis-node-2:
    container_name: redis-node-2
    <<: *redis-base
    ports:
      - 6372:6372
      - 16372:16372
    environment:
      REDIS_CLUSTER_DYNAMIC_IPS: no
      REDIS_CLUSTER_ANNOUNCE_IP: 10.0.18.181
      REDIS_PORT_NUMBER: 6372
      ALLOW_EMPTY_PASSWORD: yes
      REDIS_NODES: 10.0.18.181:6370 10.0.18.181:6371 10.0.18.181:6372 10.0.18.181:6373 10.0.18.181:6374 10.0.18.181:6375
  redis-node-3:
    container_name: redis-node-3
    <<: *redis-base
    ports:
      - 6373:6373
      - 16373:16373
    environment:
      REDIS_CLUSTER_DYNAMIC_IPS: no
      REDIS_CLUSTER_ANNOUNCE_IP: 10.0.18.181
      REDIS_PORT_NUMBER: 6373
      ALLOW_EMPTY_PASSWORD: yes
      REDIS_NODES: 10.0.18.181:6370 10.0.18.181:6371 10.0.18.181:6372 10.0.18.181:6373 10.0.18.181:6374 10.0.18.181:6375
  redis-node-4:
    container_name: redis-node-4
    <<: *redis-base
    ports:
      - 6374:6374
      - 16374:16374
    environment:
      REDIS_CLUSTER_DYNAMIC_IPS: no
      REDIS_CLUSTER_ANNOUNCE_IP: 10.0.18.181
      REDIS_PORT_NUMBER: 6374
      ALLOW_EMPTY_PASSWORD: yes
      REDIS_NODES: 10.0.18.181:6370 10.0.18.181:6371 10.0.18.181:6372 10.0.18.181:6373 10.0.18.181:6374 10.0.18.181:6375
  redis-node-5:
    container_name: redis-node-5
    <<: *redis-base
    ports:
      - 6375:6375
      - 16375:16375
    environment:
      REDIS_CLUSTER_DYNAMIC_IPS: no
      REDIS_CLUSTER_ANNOUNCE_IP: 10.0.18.181
      REDIS_PORT_NUMBER: 6375
      ALLOW_EMPTY_PASSWORD: yes
      REDIS_NODES: 10.0.18.181:6370 10.0.18.181:6371 10.0.18.181:6372 10.0.18.181:6373 10.0.18.181:6374 10.0.18.181:6375
      REDIS_CLUSTER_REPLICAS: 1
      REDIS_CLUSTER_CREATOR: yes

After modified the REDIS_NODES configuration and added REDIS_CLUSTER_ANNOUCE_IP, we needed to set REDIS_CLUSTER_DYNAMIC_IPS to "no". Additionally, we extended the ports array to include new ports known as CLUSTER BUS PORTS. These ports are utilized for various purposes such as failure detection, configuration updates, failover authorization, and more. By default, the cluster bus port is calculated by adding 10000 to the data port (e.g. 16375).

Let’t connect to Redis Cluster and check cluster nodes:

❯ redis-cli -c -h 127.0.0.1 -p 6375
127.0.0.1:6375> CLUSTER NODES
275c337ffe6073071088bb0706a2536608c03fe9 192.168.1.184:6372@16372 master - 0 1683717016000 3 connected 10923-16383
0e779e30ce3879ee37b470b299a97d41c0e16779 192.168.1.184:6370@16370 master - 0 1683717018000 1 connected 0-5460
3e7dc06681938425f71a39a2a7d189b336132e4a 192.168.1.184:6374@16374 slave 0e779e30ce3879ee37b470b299a97d41c0e16779 0 1683717020706 1 connected
841b05c2890454b345da8380ee63fa41c03fae6b 192.168.1.184:6371@16371 master - 0 1683717020000 2 connected 5461-10922
44444520eb2bbc346ab4dba9b1c495973399a227 192.168.1.184:6375@16375 myself,slave 841b05c2890454b345da8380ee63fa41c03fae6b 0 1683717017000 2 connected
8f14d7d1faac0e131d315ee34c0c7fc3836716c9 192.168.1.184:6373@16373 slave 275c337ffe6073071088bb0706a2536608c03fe9 0 1683717019000 3 connected

Great! Each node has the same IP, different port and different bus port.
Final set key attempt…

127.0.0.1:6375> SET key "value"
-> Redirected to slot [12539] located at 192.168.1.184:6372
OK

Excellent, everything works flawlessly, now we can connect to cluster from our app using 127.0.0.1 and any port from 6370 to 6375.

Conclusion

We have covered the process of setting up Redis Cluster inside Docker and exposing it externally. By following the steps outlined, you should now have a solid understanding of how to deploy and manage Redis Cluster within a Docker environment.

Additionally, we briefly touched upon Docker networking and discussed the limitations that can arise when using Docker on macOS. It's important to be aware of these limitations and consider alternative solutions if you encounter any issues specific to the macOS platform.

By exploring these concepts and working with Docker, you have taken a deeper dive into containerization and gained practical knowledge that can be applied to other projects and scenarios.

I hope this article has provided you with a clear understanding of Redis Cluster, Docker networking, and how to leverage these technologies together. Remember to keep experimenting and learning, as continuous improvement is key to mastering any technology.

Useful links

https://redis.io/docs/reference/cluster-spec/

https://redis.io/docs/management/scaling/

https://hub.docker.com/r/bitnami/redis-cluster/

https://docs.docker.com/network/

https://redis.io/docs/ui/cli/