DEV Community: Azam Akram

I Built a Collection of 100+ Free Developer Tools That Run Entirely in the Browser

Azam Akram — Tue, 09 Jun 2026 00:01:16 +0000

I Built a Collection of 100+ Free Developer Tools That Run Entirely in the Browser

As developers, we constantly run into small tasks that interrupt our workflow:

Formatting JSON
Decoding JWTs
Converting timestamps
Comparing configuration files
Generating UUIDs
Building cron expressions

Most of these tasks don't require a full application or a paid SaaS product. They just need a simple utility that works immediately.

That's why I started building Solution Toolkit — a collection of browser-based developer tools focused on everyday development tasks.

My Goals

When building the toolkit, I wanted it to be:

Free to use
No sign-up required
Privacy-first
Fast and lightweight
Available directly in the browser

Most tools run entirely client-side, so data never leaves your device.

What's Included?

Some of the categories currently available:

JSON & API Tools

JSON Formatter
JSON Validator
JSON Escape / Unescape
JSON Converters
JWT Debugger

Encoding & Decoding

Base64 Encoder / Decoder
URL Encoder / Decoder
HTML Encoder / Decoder
ASCII Converter
GZip Base64 Decoder

Formatting & Validation

SQL Formatter
YAML Formatter
CSS Formatter
JavaScript Formatter
HTML Formatter
Markdown Formatter

Developer Utilities

UUID Generator
Cron Expression Builder
Epoch Timestamp Converter
QR Code Generator
Hash Generators

Image Tools

Image Compression
Image Resizing
PNG/JPG/WebP Conversion
SVG Utilities

What I Learned Building It

A few things surprised me:

Developers care a lot about privacy for utility tools.
Browser APIs are powerful enough to handle many tasks entirely client-side.
Small utilities often provide more daily value than large applications.

Looking for Feedback

I'm actively adding new tools and improving existing ones.

What browser-based developer tool do you wish existed?

Or what's a utility you find yourself searching for repeatedly?

I'd love to hear suggestions.

🔗 Project: https://www.solutiontoolkit.com

AWS ALB Scaling: Set Up Application Load Balancer with Auto Scaling Group (ASG)

Azam Akram — Mon, 08 Jun 2026 23:38:40 +0000

In any well-architected cloud setup, managing traffic efficiently and scaling resources on demand are key to keeping your applications fast, reliable, and cost-efficient.

AWS makes this easy with two core services: the Elastic Load Balancer (ELB) for routing traffic, and Auto Scaling Groups (ASG) for automatically adjusting compute capacity as traffic changes.

The AWS Elastic Load Balancer automatically distributes incoming requests across multiple targets, such as, EC2 instances, containers, or IPs, across different Availability Zones (AZs). AWS offers several types of load balancers, including Application, Network, and Gateway Load Balancers, each suited for different scenarios.

In this guide, we’ll set up an Application Load Balancer (ALB) connected to an Auto Scaling Group (ASG) using the AWS CLI.

Our setup will dynamically launch and manage EC2 instances, organized into a Target Group, ensuring smooth load distribution and high availability.

What We'll Do

Create a security group to allow necessary inbound traffic.
Define a launch template with EC2 instance configuration and a user-data script to deploy a simple web server.
Set up an Auto Scaling Group (ASG) to handle scaling based on demand.
Create a Target Group to manage and distribute traffic.
Configure an Application Load Balancer (ALB) and listener, linking it to the Target Group for seamless load balancing.

Prerequisites

An AWS account. If you don’t have one, follow this quick guide to create a free-tier AWS account.
AWS access keys configured in your local CLI environment. These are needed for deploying resources. Check out Section 9 of our AWS starter guide for details.

Why Combine ALB with ASG?

Pairing an Application Load Balancer (ALB) with an Auto Scaling Group (ASG) gives you a scalable, cost-effective, and fault-tolerant setup. Here’s why it’s a great combo:

Automatic Scaling – ASG adjusts the number of EC2 instances in real time as traffic changes.
Cost Optimization – You only pay for what you use, saving costs during low-traffic hours.
High Availability – ALB spreads requests across healthy instances in multiple AZs, avoiding single points of failure.
Better Fault Tolerance – If one instance fails, ALB automatically routes traffic to healthy ones, ensuring smooth performance.

Let’s dive in and start building!

Step 1: Create a Security Group

Before launching EC2 instances or attaching them to a Load Balancer, we need to define a security group, which is a virtual firewall that controls inbound and outbound traffic. In this step, we’ll create a security group that allows SSH (for remote access) and HTTP (for web traffic) connections.

Run the following command to create a new security group:

aws ec2 create-security-group \
  --group-name my-test-security-group \
  --description "Security Group for My ALB" \
  --region <your-region-id>

This command creates a security group in your specified AWS region. Next, we’ll add inbound rules that define what types of traffic are allowed to reach our EC2 instances.

aws ec2 authorize-security-group-ingress \
  --group-name my-test-security-group \
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0 \
  --region <your-region-id>

This rule enables SSH access on port 22, allowing you to connect to the instance from your terminal or SSH client.
We use tcp as the protocol since SSH operates over the TCP layer.

Note: Allowing SSH from all IP addresses (0.0.0.0/0) is convenient for testing, but not secure for production. In real deployments, you should restrict this to your own IP or a trusted network range, for example: --cidr 203.0.113.25/32

Now we create another inbound rule to allow HTTP traffic on port 80 over TCP.

aws ec2 authorize-security-group-ingress \
  --group-name my-test-security-group \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0 \
  --region <your-region-id>

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/ec2-security-group-console.webp"
alt="ec2-security-group-console"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Let's verify the security group in the AWS Management Console:

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/ec2-security-group-gui.webp"
alt="ec2-security-group-gui"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 2: Create a Launch Template

An AWS Launch Template is a reusable blueprint that defines the configuration settings for your EC2 instances, such as the AMI, instance type, key pair, security groups, and optional user-data scripts.

Using a launch template helps standardize instance launches and simplifies scaling operations within an Auto Scaling Group (ASG).

In this step, we’ll manually create a launch template using the AWS Management Console.

Open the EC2 Dashboard in the AWS Management Console.
In the left sidebar, choose Launch Templates, then click Create launch template.
Enter a name, such as MyLaunchTemplate.
Under Application and OS Images (Amazon Machine Image), select Amazon Linux 2023 AMI (eligible for the free tier).
Choose an Instance type, e.g., t2.micro.
Skip the Key pair step for now (this is fine for testing, but in production, you should always create one for SSH access).
Under Network settings, select the previously created security group (my-test-security-group).
Expand Advanced details and paste the following user data script to automatically install and configure a simple web server. Finally, click Create launch template.

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd

# Get the EC2 instance's availability zone
EC2AZ=$(TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/placement/availability-zone)

# Create a simple HTML file with the availability zone info
echo '<center><h1>Hello from Web Server in Availability Zone: AZID </h1></center>' > /var/www/html/index.txt
sed "s/AZID/$EC2AZ/" /var/www/html/index.txt > /var/www/html/index.html

This user-data script runs automatically when the instance starts. It:

Installs and enables the Apache (httpd) web server.
Fetches the Availability Zone from the instance’s metadata.
Displays a custom message in the browser showing the zone where the instance is running — useful when testing load balancing across multiple zones.

Note:

Every EC2 instance has access to instance metadata, which contains information like instance ID, region, IP addresses, and Availability Zone.

AWS exposes this data through a special internal endpoint — 169.254.169.254 — accessible only from within the instance.

Learn more about instance metadata in the official AWS documentation.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/launch-template.webp"
alt="launch-template"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 3: Create an Auto Scaling Group (ASG)

Now we will create an Auto Scaling group named "my-auto-scaling-group" using a launch template we previously created "MyLaunchTemplate." It sets the desired capacity to 2 instances, with a minimum of 1 and a maximum of 5 instances, distributed across two availability zones. The instances are launched in two different subnets within a Virtual Private Cloud (VPC) to ensure scalability and high availability.

aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-auto-scaling-group \
  --launch-template "LaunchTemplateName=MyLaunchTemplate" \
  --min-size 1 --max-size 5 --desired-capacity 2 \
  --availability-zones "<availability-zone-1>" "<availability-zone-2>" \
  --vpc-zone-identifier "<subnet-id-1>,<subnet-id-2>"

Note: Replace <subnet-id-x> and <availablity-zone-x> according to your setup.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/security-group.webp"
alt="security-group"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 4: Create Target Group and Load Balancer

Create a Target Group

A Target Group defines the set of resources (such as EC2 instances) that an Application Load Balancer (ALB) routes incoming requests to. It continuously performs health checks to ensure traffic is sent only to healthy instances, improving reliability and availability.

In this step, we’ll create an HTTP-based target group named my-target-group that listens on port 80 within your VPC. This target group will later be linked to your Auto Scaling Group (ASG) so that any new instances launched by the ASG are automatically registered as targets.

aws elbv2 create-target-group \
--name my-target-group \
--protocol HTTP \
--port 80 \
--vpc-id <vpc-id>

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/target-group.webp"
alt="target-group"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Note: Target group is created but no EC2 instances are registered yet. Instances will be registered automatically once the Auto Scaling Group is attached in a later step.

Create an Application Load Balancer (ALB)

An Application Load Balancer (ALB) intelligently distributes incoming HTTP and HTTPS traffic across multiple targets, such as EC2 instances, in one or more Availability Zones (AZs).

The following command creates an ALB named my-alb, specifying the subnets and security groups that determine where and how the load balancer operates:

aws elbv2 create-load-balancer \
--name my-alb \
--subnets <subnet-id-1> <subnet-id-2> \
--security-groups <security-group-id> \

This command:

Creates an Application Load Balancer called my-alb.
Associates it with two subnets (usually in different Availability Zones) for high availability.
Applies the specified security group, which defines what inbound and outbound traffic is allowed for the load balancer.

Note: Replace <subnet-id-1>, <subnet-id-2>, and <security-group-id> with actual values from your AWS setup.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/create-load-balancer.webp"
alt="create-load-balancer"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Note: You need to note down LoadBalancerArn, which we will use in coming sections.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/load-balancer-setting.webp"
alt="load-balancer-setting"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Create a Listener and Link it to the Target Group

A Listener is a key component of an Application Load Balancer (ALB). It checks for incoming connection requests on a specific port and protocol, then forwards the traffic to a designated Target Group based on defined rules.
In this step, we’ll create an HTTP listener on port 80 for our ALB, which will route all incoming web requests to the previously created target group.

aws elbv2 create-listener \
  --load-balancer-arn <alb-arn> \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=<target-group-arn>

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/create-listener.webp"
alt="create-listener"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Attach the Target Group to the Auto Scaling Group

The Target Group must be linked to your Auto Scaling Group (ASG) so that any instances launched by the ASG are automatically registered with the Application Load Balancer (ALB).

This ensures that traffic is distributed only to healthy, actively running instances managed by the ASG.

Use the following command to attach the target group to your Auto Scaling group named ASG1:

aws autoscaling attach-load-balancer-target-groups \
  --auto-scaling-group-name ASG1 \
  --target-group-arns <target-group-arn>

This command:

Connects the specified Target Group to your ASG.
Ensures that new instances launched by the ASG are automatically added to the target group for load balancing.
Enables health checks so unhealthy instances are replaced automatically.

After this step, the Auto Scaling Group will launch two EC2 instances (based on the desired capacity you configured earlier).

Once these instances pass their health checks, they’ll be marked as healthy, and the ALB will begin routing traffic to them automatically.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/create-auto-scaling.webp"
alt="create-auto-scaling"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

We can also check the Target Group to see that both instances are healthy.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/target-group.webp"
alt="target-group"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 5: Testing the Load Balancer

To verify that the Application Load Balancer (ALB) is correctly distributing traffic, open the ALB Dashboard in the AWS Management Console and note down the DNS name of your ALB.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/test-elb.webp"
alt="test-elb"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Enter this ALB DNS name in your web browser.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/browser-elb-1.webp"
alt="browser-elb-1"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Now, refresh the browser several times.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/browser-elb-2.webp"
alt="browser-elb-2"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

As you refresh, you’ll notice that the web page alternates between different Availability Zones (AZs). This confirms that the Application Load Balancer is intelligently distributing incoming traffic across multiple EC2 instances (targets) in different zones.

Each request may reach a different instance within the Target Group, depending on factors like health status, capacity, and routing algorithm.

In summary, this test proves that your ALB and Auto Scaling Group (ASG) are working together as intended, automatically balancing the load between multiple healthy EC2 instances.

Step 6: Deleting the Setup

Once you’ve verified that your Application Load Balancer (ALB) and Auto Scaling Group (ASG) are working correctly, it’s good practice to clean up the resources to avoid ongoing AWS charges.

Run the following commands to delete the setup:

aws elbv2 delete-load-balancer --load-balancer-arn <alb-arn>
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name ASG1 --force-delete

These commands:

Remove the ALB and its associated listeners and target group.
Delete the Auto Scaling Group along with any EC2 instances it launched (using the --force-delete flag ensures immediate deletion).

Note: You may also want to delete other related resources such as the launch template, target group, and security group if they are no longer needed.

Conclusion

You’ve successfully set up an AWS Application Load Balancer (ALB) integrated with an Auto Scaling Group (ASG) and Target Group — all using the AWS CLI.

This architecture automatically adjusts capacity based on demand while distributing traffic evenly across multiple instances, ensuring:

High availability across Availability Zones,
Fault tolerance through automatic health checks and scaling, and
Cost efficiency by running only the resources you need.

With this foundation, you can now expand the setup, for example, adding HTTPS with an SSL certificate, customizing health checks, or deploying containerized workloads behind the load balancer.

Building Kafka Producer-Consumer Using Go and Docker

Azam Akram — Mon, 08 Jun 2026 23:34:22 +0000

In this blog, we'll walk through the process of building Kafka Producer and Consumer microservices using Go, integrated with Docker.

We will,

Build a Go Kafka producer with an HTTP endpoint.
Build a Go Kafka consumer with retry and dead-letter support.
Set up Kafka using Docker (KRaft mode — no Zookeeper required).
Run the application end-to-end.

Introduction

Microservices architecture is a popular approach for building scalable and maintainable applications. By breaking down applications into smaller, independent services, developers can enhance flexibility and streamline deployment cycles. We will implement Kafka producer and consumer applications in Go and demonstrate how to run Kafka in a Docker container with Docker Compose to create a seamless microservices environment.

Go

Go is an open-source, statically typed, compiled language designed at Google for simplicity, reliability, and efficiency. It ships with a rich standard library, first-class concurrency primitives (goroutines and channels), and produces single, statically-linked binaries — making it an excellent fit for microservices and containerised workloads.

Apache Kafka

Kafka is a distributed streaming platform used to build real-time data pipelines and streaming applications. It allows producers to send messages to topics, which are then consumed by various consumers, making it ideal for event-driven architectures.

Docker

Docker is a platform that allows developers to automate the deployment of applications inside lightweight, portable containers. With Docker Compose, you can manage services like Kafka in isolated containers, making it easy to build and maintain microservices architectures.

Prerequisites

Go 1.22 or later. If you haven't installed Go yet, this guide walks you through the setup.
Docker
Docker Compose
Basic knowledge of Go and Kafka

Download Code from Github

Download full code from this github repository.

Project Overview

We will create two Go applications:

Kafka Producer: Exposes a GET /send HTTP endpoint that publishes a message to a Kafka topic.
Kafka Consumer: Connects to the topic, processes each message, and retries on failure with dead-letter support.

kafka-docker-go/
├── kafka-producer/
│   ├── go.mod
│   ├── main.go
│   ├── producer.go
│   ├── handler.go
│   └── model.go
├── kafka-consumer/
│   ├── go.mod
│   ├── main.go
│   ├── consumer.go
│   └── model.go
└── docker-compose.yml

Building and Running the Application

Docker Compose for Kafka Setup

Before we start building the Go producer and consumer, we first need a running Kafka instance locally. Instead of manually installing Kafka and managing all its dependencies, we'll use Docker Compose to spin up a ready-to-use environment in a single command.

We'll be using Apache Kafka running in KRaft mode (Kafka without ZooKeeper). Traditionally, Kafka relied on Apache ZooKeeper for cluster coordination, but modern Kafka versions (3.3+) have introduced KRaft (Kafka Raft metadata mode), which simplifies the architecture by removing ZooKeeper entirely.

docker-compose.yml:

This configuration provisions a single Kafka broker that also acts as a controller (KRaft mode):

services:
  kafka:
    image: apache/kafka:latest
    container_name: kafka
    ports:
      - "9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: 'broker,controller'
      KAFKA_CONTROLLER_QUORUM_VOTERS: '1@localhost:9093'
      KAFKA_LISTENERS: 'PLAINTEXT://:9092,CONTROLLER://:9093'
      KAFKA_ADVERTISED_LISTENERS: 'PLAINTEXT://localhost:9092'
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: 'CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT'
      KAFKA_CONTROLLER_LISTENER_NAMES: 'CONTROLLER'
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

KAFKA_PROCESS_ROLES: 'broker,controller'
Instructs this single container to act simultaneously as both the metadata controller and the message broker, completely eliminating the need for ZooKeeper.
KAFKA_ADVERTISED_LISTENERS
Defines the network address and port (localhost:9092) that external clients, such as your Go producers and consumers, will use to connect to the cluster.
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
Sets the replication factor for the internal offsets topic to 1. This is ideal for single-node local development, ensuring the cluster stays healthy without requiring peer nodes.

To launch your local Kafka environment in detached mode, run:

$ docker-compose up -d
[+] up 2/2
 ✔ Network golang-kafka-docker_default  Created                          0.0s
 ✔ Container kafka                      Started

Verify the container is running:

$ docker ps
CONTAINER ID   IMAGE                COMMAND                  CREATED         STATUS         PORTS                    NAMES
ae58e1252135   apache/kafka:latest  "/__cacert_entrypoin…"   3 minutes ago   Up 3 minutes   0.0.0.0:9092->9092/tcp   kafka

Now that Kafka is running, let's quickly verify it using the built-in console tools.

In a terminal, start a Kafka console consumer that reads all messages from the beginning of the topic:

I wrote following command in git Bash. Git Bash on Windows automatically converts paths starting with / to Windows paths, turning /opt/kafka/bin/... into C:/Program Files/Git/opt/kafka/bin/....
SO I wrote path starting with double slashes, //opt/kafka/bin/kafka-console-consumer.sh

docker exec -it kafka //opt/kafka/bin/kafka-console-consumer.sh \
  --bootstrap-server localhost:9092 \
  --topic demo-kafka-topic \
  --from-beginning

In a second terminal, start a producer to send a test message:

docker exec -it kafka //opt/kafka/bin/kafka-console-producer.sh \
  --bootstrap-server localhost:9092 \
  --topic demo-kafka-topic

Type a message and press Enter:

Hello from kafka Producer

The consumer terminal will immediately display:

Hello from kafka Producer

src="/static/images/golang-kafka-producer-consumer-with-docker/kafka-producer-consumer-manual-test.webp"
alt="kafka-producer-consumer-manual-test"
className="mx-auto my-6 h-5/6 w-5/6 rounded-lg shadow-lg"
/>

Kafka Consumer Service (Go)

Now that our Kafka broker is running, let's build the consumer service that listens to messages from the topic and processes them in real time.

We'll use kafka-go — a pure Go Kafka client that is a light-weight dependency, and gives fine-grained control over offset commits.

`go.mod`

module github.com/azam-akram/kafka-docker-go/kafka-consumer

go 1.22

require github.com/segmentio/kafka-go v0.4.51

Run go mod tidy after creating this file to download the dependency.

Message Model (`model.go`)

The Message struct is the shared data contract between producer and consumer. It is marshalled to JSON by the producer and unmarshalled back by the consumer.

package main

type Message struct {
    UUID    string `json:"uuid"`
    From    string `json:"from"`
    To      string `json:"to"`
    Message string `json:"message"`
}

Kafka Consumer (`consumer.go`)

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"
    "time"

    "github.com/segmentio/kafka-go"
)

const (
    maxRetries = 3
    retryDelay = time.Second
)

type KafkaConsumer struct {
    reader    *kafka.Reader
    dlqWriter *kafka.Writer
}

func NewKafkaConsumer(broker, topic, groupID string) *KafkaConsumer {
    dlqTopic := topic + "-dlt"
    return &KafkaConsumer{
        reader: kafka.NewReader(kafka.ReaderConfig{
            Brokers:     []string{broker},
            Topic:       topic,
            GroupID:     groupID,
            MinBytes:    10e3,
            MaxBytes:    10e6,
            StartOffset: kafka.FirstOffset,
        }),
        dlqWriter: &kafka.Writer{
            Addr:                   kafka.TCP(broker),
            Topic:                  dlqTopic,
            Balancer:               &kafka.LeastBytes{},
            AllowAutoTopicCreation: true,
        },
    }
}

// Run fetches messages in a loop until ctx is cancelled.
func (c *KafkaConsumer) Run(ctx context.Context) {
    for {
        m, err := c.reader.FetchMessage(ctx)
        if err != nil {
            if ctx.Err() != nil {
                return // clean shutdown on SIGTERM / SIGINT
            }
            log.Printf("ERROR fetch: %v", err)
            continue
        }

        if err := c.processWithRetry(m); err != nil {
            log.Printf("ERROR retries exhausted, routing to DLQ — uuid=%s", string(m.Key))
            c.sendToDLQ(ctx, m)
        }

        if err := c.reader.CommitMessages(ctx, m); err != nil {
            log.Printf("ERROR commit: %v", err)
        }
    }
}

func (c *KafkaConsumer) processWithRetry(m kafka.Message) error {
    var lastErr error
    for attempt := 1; attempt <= maxRetries; attempt++ {
        if err := process(m); err != nil {
            lastErr = err
            log.Printf("WARN attempt %d/%d failed: %v", attempt, maxRetries, err)
            if attempt < maxRetries {
                time.Sleep(retryDelay)
            }
            continue
        }
        return nil
    }
    return lastErr
}

func process(m kafka.Message) error {
    var msg Message
    if err := json.Unmarshal(m.Value, &msg); err != nil {
        return fmt.Errorf("unmarshal: %w", err)
    }

    log.Println("=================================")
    log.Println("Received message:")
    log.Printf("  UUID:    %s", msg.UUID)
    log.Printf("  From:    %s", msg.From)
    log.Printf("  To:      %s", msg.To)
    log.Printf("  Message: %s", msg.Message)
    log.Println("=================================")
    return nil
}

func (c *KafkaConsumer) sendToDLQ(ctx context.Context, m kafka.Message) {
    if err := c.dlqWriter.WriteMessages(ctx, kafka.Message{
        Key:   m.Key,
        Value: m.Value,
    }); err != nil {
        log.Printf("ERROR DLQ write: %v", err)
    }
}

func (c *KafkaConsumer) Close() {
    c.reader.Close()
    c.dlqWriter.Close()
}

Key design decisions explained:

kafka.NewReader with GroupID: registering a GroupID enables consumer-group semantics — Kafka assigns partitions to group members and tracks committed offsets per group. Multiple consumer instances sharing the same GroupID can scale horizontally across partitions.
FetchMessage vs ReadMessage: kafka-go provides two fetch APIs. ReadMessage automatically commits the offset after each fetch, which risks marking a message as processed even if your handler panics. FetchMessage leaves the offset uncommitted; we call CommitMessages only after the message has been fully processed (or routed to the DLQ). This gives us at-least-once delivery semantics.
StartOffset: kafka.FirstOffset: equivalent to auto-offset-reset: earliest in a Spring Boot config. On first start (no committed offset for the group), the consumer reads from the beginning of the topic.
processWithRetry: wraps process in a simple retry loop — up to maxRetries attempts with a retryDelay between each. If a transient error causes process to fail, the message is retried in place before being sent to the DLQ.
Dead-letter topic (-dlt suffix): if all retry attempts are exhausted, the raw message bytes are forwarded to demo-kafka-topic-dlt. Failed messages are captured for inspection or manual reprocessing rather than silently dropped — the same pattern as @DltHandler in Spring Kafka.

Application Entry Point (`main.go`)

package main

import (
    "context"
    "log"
    "net/http"
    "os"
    "os/signal"
    "syscall"
)

func main() {
    broker := "localhost:9092"
    topic := "demo-kafka-topic"
    groupID := "demo-kafka-consumer"
    port := "5555"

    consumer := NewKafkaConsumer(broker, topic, groupID)
    defer consumer.Close()

    // Simple health endpoint
    go func() {
        mux := http.NewServeMux()
        mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
            w.Header().Set("Content-Type", "application/json")
            w.Write([]byte(`{"status":"up"}`))
        })
        log.Printf("Health endpoint on :%s", port)
        http.ListenAndServe(":"+port, mux)
    }()

    ctx, cancel := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    defer cancel()

    log.Printf("Consumer started topic=%s group=%s", topic, groupID)
    consumer.Run(ctx)
    log.Println("Consumer stopped")
}

signal.NotifyContext: creates a context that is cancelled when the process receives SIGINT (Ctrl+C) or SIGTERM (e.g. from docker stop). When the context is cancelled, FetchMessage returns immediately, allowing the Run loop to exit cleanly.
Health goroutine: a minimal GET /health endpoint runs on port 5555 in a background goroutine, so the consumer can be probed by Docker health checks or an orchestrator without interfering with the main consume loop.

Kafka Producer Service (Go)

The producer service exposes a simple REST endpoint. When called, it builds a Message and publishes it to the Kafka topic.

`go.mod`

module github.com/azam-akram/kafka-docker-go/kafka-producer

go 1.22

require github.com/segmentio/kafka-go v0.4.47

Message Model (`model.go`)

The producer's Message model mirrors the consumer's exactly, ensuring the JSON wire format is compatible on both sides.

package main

type Message struct {
    UUID    string `json:"uuid"`
    From    string `json:"from"`
    To      string `json:"to"`
    Message string `json:"message"`
}

In a larger system you would extract this into a shared Go module to avoid duplication.
For this self-contained example, both services define their own copy.

Kafka Producer (`producer.go`)

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"

    "github.com/segmentio/kafka-go"
)

type KafkaProducer struct {
    writer *kafka.Writer
}

func NewKafkaProducer(broker, topic string) *KafkaProducer {
    return &KafkaProducer{
        writer: &kafka.Writer{
            Addr:                   kafka.TCP(broker),
            Topic:                  topic,
            Balancer:               &kafka.LeastBytes{},
            RequiredAcks:           kafka.RequireOne,
            AllowAutoTopicCreation: true,
        },
    }
}

func (p *KafkaProducer) Send(ctx context.Context, msg Message) error {
    value, err := json.Marshal(msg)
    if err != nil {
        return fmt.Errorf("marshal: %w", err)
    }

    if err := p.writer.WriteMessages(ctx, kafka.Message{
        Key:   []byte(msg.UUID),
        Value: value,
    }); err != nil {
        return fmt.Errorf("write: %w", err)
    }

    log.Printf("Sent  uuid=%s topic=%s", msg.UUID, p.writer.Topic)
    return nil
}

func (p *KafkaProducer) Close() error {
    return p.writer.Close()
}

Key design decisions:

RequiredAcks: kafka.RequireOne: the broker acknowledges the write once the leader partition has persisted the message. This balances throughput and durability for a single-node development setup. In production, use kafka.RequireAll to wait for all in-sync replicas.
AllowAutoTopicCreation: true: if demo-kafka-topic does not exist yet, the broker creates it automatically on first write — no need to pre-create topics manually.
Message key set to UUID: using the UUID as the partition key ensures messages with the same UUID always land on the same partition. For random distribution across partitions, omit the key.
fmt.Errorf("...: %w", err): wraps errors with context using the %w verb so callers can use errors.Is / errors.As for structured error handling.

HTTP Handler (`handler.go`)

package main

import (
    "context"
    "fmt"
    "log"
    "net/http"
    "time"

    "github.com/google/uuid"
)

type SendHandler struct {
    producer *KafkaProducer
}

func (h *SendHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    msg := Message{
        UUID:    uuid.New().String(),
        From:    "Alice",
        To:      "Bob",
        Message: "Hello from Go producer",
    }

    ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
    defer cancel()

    if err := h.producer.Send(ctx, msg); err != nil {
        log.Printf("ERROR send: %v", err)
        http.Error(w, "failed to send message", http.StatusInternalServerError)
        return
    }

    fmt.Fprintln(w, "Message sent!")
}

ServeHTTP: implementing the http.Handler interface directly (rather than a plain func) lets us inject the *KafkaProducer dependency cleanly and register the handler with mux.Handle("/send", &SendHandler{...}).
context.WithTimeout: the send is bound to a 5-second deadline. If the Kafka broker is unavailable, WriteMessages returns promptly with a deadline-exceeded error rather than hanging the HTTP request indefinitely.
newUUID: generates a RFC 4122 v4 UUID via github.com/google/uuid.

Application Entry Point (`main.go`)

package main

import (
    "log"
    "net/http"
)

func main() {
    broker := "localhost:9092"
    topic := "demo-kafka-topic"
    port := "4444"

    producer := NewKafkaProducer(broker, topic)
    defer producer.Close()

    mux := http.NewServeMux()
    mux.Handle("/send", &SendHandler{producer: producer})
    mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        w.Write([]byte(`{"status":"up"}`))
    })

    log.Printf("Producer listening on :%s", port)
    log.Fatal(http.ListenAndServe(":"+port, mux))
}

The producer uses Go's built-in net/http server, no third-party web framework needed. A GET /health endpoint is registered alongside /send so that the service can be health-checked by Docker or an orchestrator.

Running the Application End-to-End

Step 1 — Start Kafka

docker-compose up -d

Step 2 — Start the Consumer

From the kafka-consumer directory:

go mod tidy
go run .

The consumer starts on port 5555 and begins listening to demo-kafka-topic.

2026/05/29 10:00:00 Health endpoint on :5555
2026/05/29 10:00:00 Consumer started topic=demo-kafka-topic group=demo-kafka-consumer

Step 3 — Start the Producer

From the kafka-producer directory:

go mod tidy
go run .

The producer starts on port 4444.

2026/05/29 10:00:05 Producer listening on :4444

Step 4 — Send a Message

Trigger the producer's REST endpoint:

curl http://localhost:4444/send

You should see the response:

Message sent!

Step 5 — Observe the Consumer Logs

In the consumer terminal you will see:

=================================
Received message:
  UUID:    3f2504e0-4f89-11d3-9a0c-0305e82c3301
  From:    Alice
  To:      Bob
  Message: Hello from Go producer
=================================

And in the producer terminal, the send confirmation:

2026/05/29 10:00:10 Sent  uuid=3f2504e0-4f89-11d3-9a0c-0305e82c3301 topic=demo-kafka-topic

src="/static/images/golang-kafka-producer-consumer-with-docker/kafka-docker-go-e2e-test.png"
alt="kafka-docker-go-e2e-test"
className="mx-auto my-6 h-5/6 w-5/6 rounded-lg shadow-lg"
/>

Step 6 — Check Health Endpoints

Both services expose a /health endpoint:

# Producer health
curl http://localhost:4444/health

# Consumer health
curl http://localhost:5555/health

Both return:

{"status":"up"}

Step 7 — Graceful Shutdown

Press Ctrl+C in the consumer terminal. The signal.NotifyContext cancels the context, FetchMessage returns, and the consumer exits cleanly:

2026/05/29 10:01:00 Consumer stopped

Summary

In this blog we built two Go microservices that communicate asynchronously through Apache Kafka running in Docker:

Component	Responsibility
`docker-compose.yml`	Runs a single-node Kafka broker in KRaft mode (no ZooKeeper)
`KafkaProducer`	Marshals a `Message` to JSON and publishes it to a topic
`SendHandler`	Exposes a `GET /send` HTTP endpoint to trigger the producer
`KafkaConsumer`	Unmarshals and processes messages with manual offset commits
`processWithRetry`	Retries failed messages up to 3 times with a 1-second backoff
`sendToDLQ`	Routes exhausted messages to a dead-letter topic (`-dlt`)

The key production-ready features we added beyond a minimal example:

Manual offset commit — FetchMessage + CommitMessages ensures an offset is committed only after successful processing, giving at-least-once delivery semantics.
Retry with backoff — transient failures are retried up to 3 times before escalating to the DLQ.
Dead-letter topic — messages that exhaust all retries are forwarded to demo-kafka-topic-dlt for inspection rather than silently dropped.
Graceful shutdown — signal.NotifyContext cancels the consume loop on SIGTERM/SIGINT, preventing data loss on process stop.
Health endpoints — both services expose GET /health for Docker and orchestrator health checks.
Environment-driven config — all connection parameters (KAFKA_BROKER, KAFKA_TOPIC, etc.) are read from environment variables, making both services container-ready out of the box.

Deploy Your First Go App with Docker and Kubernetes

Azam Akram — Mon, 08 Jun 2026 23:30:09 +0000

This blog is the practical companion to Kubernetes Fundamentals.
We will build a real Go HTTP server, containerize it with Docker, and deploy it to a local Kubernetes cluster powered by kind.
kind stands for Kubernetes in Docker: it runs Kubernetes nodes as Docker containers, which makes it a convenient way to practise Kubernetes locally without needing a cloud account.
By the end you will have run a rolling update and scaled your application — all from your local machine.

Prerequisites

Go 1.21 or later installed.
Docker Desktop installed and running.
kubectl installed — the CLI for talking to a Kubernetes cluster.

Verify everything is working before proceeding:

go version
docker version
kubectl version --client

Step 1: Create the Go Application

Create a project directory and initialise a Go module:

mkdir go-k8s-demo
cd go-k8s-demo
go mod init go-k8s-demo

Create main.go:

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
    "os"
    "time"
)

type Response struct {
    Message  string    `json:"message"`
    Hostname string    `json:"hostname"`
    Version  string    `json:"version"`
    Time     time.Time `json:"time"`
}

func handler(w http.ResponseWriter, r *http.Request) {
    hostname, _ := os.Hostname()
    resp := Response{
        Message:  "Hello from Kubernetes!",
        Hostname: hostname,
        Version:  os.Getenv("APP_VERSION"),
        Time:     time.Now(),
    }

    w.Header().Set("Content-Type", "application/json")
    if err := json.NewEncoder(w).Encode(resp); err != nil {
        log.Printf("encode response: %v", err)
    }
}

func healthcheck(w http.ResponseWriter, r *http.Request) {
    fmt.Fprint(w, "ok")
}

func main() {
    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }

    http.HandleFunc("/", handler)
    http.HandleFunc("/healthcheck", healthcheck)

    log.Printf("Server listening on :%s", port)
    if err := http.ListenAndServe(":"+port, nil); err != nil {
        log.Fatalf("Listen error: %v", err)
    }
}

A few things to note:

os.Hostname() returns the Pod name when running inside Kubernetes. This is handy for verifying which replica handled a request.
APP_VERSION is read from an environment variable so we can inject different values at deploy time without changing the image.
/healthcheck is the liveness and readiness probe endpoint Kubernetes will call to check if the container is healthy.

Test the application locally:

go run main.go

In another terminal:

curl http://localhost:8080

Expected response:

{
  "message": "Hello from Kubernetes!",
  "hostname": "your-machine-name",
  "version": "",
  "time": "2026-06-02T10:00:00Z"
}

Step 2: Containerize with Docker

Create a Dockerfile in the project root:

# Build stage
FROM golang:1.25.3-alpine AS builder
WORKDIR /app
COPY go.mod ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o server .

# Runtime stage
FROM alpine:3.21
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /app/server .
USER app
EXPOSE 8080
CMD ["./server"]

This is a multi-stage build:

The first stage (builder) compiles the binary inside a full Go toolchain image.
The second stage copies only the compiled binary into a minimal Alpine image.
The final image is a few megabytes, not hundreds. There is no Go compiler, no source code — only the binary the application needs.
CGO_ENABLED=0 produces a fully static binary with no C library dependencies, which is required on the minimal Alpine base.
adduser -S app runs the process as a non-root user — a standard security baseline.

Build and test the image locally

docker build -t go-k8s-demo:v1 .

Run it locally to verify:

docker run -p 8080:8080 -e APP_VERSION=v1 go-k8s-demo:v1

curl http://localhost:8080

The response now includes "version": "v1" because the environment variable was injected at runtime.

Step 3: Create a Kubernetes Cluster in Docker Desktop

So far we have only used Docker directly: we built an image and proved the container can run on our machine.

Kubernetes is the next layer. Instead of starting one container manually with docker run, we will ask Kubernetes to keep the application running for us. It will create Pods, restart unhealthy containers, expose the app through a Service, and later perform a rolling update.

For this local tutorial, Docker Desktop can create a small Kubernetes cluster using kind. Because kind runs Kubernetes nodes as Docker containers, your cluster is still local, but it behaves like a real Kubernetes cluster from the point of view of kubectl.

Go to Settings → Kubernetes → Create a Kubernetes Cluster.

You will be offered two cluster types:

kind — recommended. Creates a cluster using kind. Requires the containerd image store. Locally built images must be explicitly loaded into the cluster with kind load docker-image before Kubernetes can use them.
Kubeadm — creates a single-node cluster with kubeadm. Same requirement: locally built images need to be loaded or pushed to a registry.

Select kind, leave the node count at 1, and click Create. The first creation pulls cluster components and takes a minute or two. Once the status indicator turns green, verify the cluster is up:

kubectl get nodes

NAME                    STATUS   ROLES           AGE   VERSION
desktop-control-plane   Ready    control-plane   60s   v1.34.3

Docker Desktop automatically sets the kubectl context to the new cluster, so no extra context switching is needed.

Load the image into the kind cluster

Now that the kind cluster exists, we need to make the image available inside it.

This is a common point of confusion: the image go-k8s-demo:v1 exists in Docker's local image store because we built it with docker build, but the kind cluster has its own container runtime inside the node container. Kubernetes will not automatically see every image on your host machine. We must explicitly load or import the image before the Deployment can start Pods from it.

On Mac/Linux — use the kind CLI:

kind load docker-image go-k8s-demo:v1

On Windows (Git Bash + Docker Desktop) — kind may be blocked by Windows Application Control policies. Use the following three-step method instead. Docker Desktop's kind node runs inside the desktop-linux context and the node container is named desktop-control-plane.

Save the image as a tar file in the current directory (avoid /tmp — Git Bash maps it to a Windows temp path which causes issues):

docker save go-k8s-demo:v1 -o go-k8s-demo-v1.tar

Copy the tar into the kind node container (MSYS_NO_PATHCONV=1 prevents Git Bash from converting the Linux path to a Windows path):

MSYS_NO_PATHCONV=1 docker --context desktop-linux cp go-k8s-demo-v1.tar desktop-control-plane:/go-k8s-demo-v1.tar

Import the image into containerd inside the node:

MSYS_NO_PATHCONV=1 docker --context desktop-linux exec desktop-control-plane ctr images import /go-k8s-demo-v1.tar

On Windows (PowerShell or Command Prompt + Docker Desktop) — use the same manual import method, but you do not need MSYS_NO_PATHCONV because PowerShell and Command Prompt do not rewrite Linux-style container paths.

Save the image as a tar file in the current directory:

docker save go-k8s-demo:v1 -o go-k8s-demo-v1.tar

Copy the tar into the kind node container:

docker --context desktop-linux cp go-k8s-demo-v1.tar desktop-control-plane:/go-k8s-demo-v1.tar

Import the image into containerd inside the node:

docker --context desktop-linux exec desktop-control-plane ctr images import /go-k8s-demo-v1.tar

Verify the image is available.

Git Bash:

MSYS_NO_PATHCONV=1 docker --context desktop-linux exec desktop-control-plane ctr images ls

PowerShell or Command Prompt:

docker --context desktop-linux exec desktop-control-plane ctr images ls

You should see docker.io/library/go-k8s-demo:v1 in the list. From here on, Kubernetes can create Pods from that local image without pulling it from Docker Hub or another registry.

Step 4: Write Kubernetes Manifests

Create a directory for the manifests:

mkdir k8s

Deployment

Create k8s/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-k8s-demo
  labels:
    app: go-k8s-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-k8s-demo
  template:
    metadata:
      labels:
        app: go-k8s-demo
    spec:
      containers:
        - name: go-k8s-demo
          image: go-k8s-demo:v1
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
          env:
            - name: APP_VERSION
              value: 'v1'
          livenessProbe:
            httpGet:
              path: /healthcheck
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /healthcheck
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5
          resources:
            requests:
              cpu: '50m'
              memory: '32Mi'
            limits:
              cpu: '200m'
              memory: '64Mi'

Key settings explained:

replicas: 3 — Kubernetes will keep exactly 3 Pods running. If one dies, it creates a replacement.
imagePullPolicy: IfNotPresent — Kubernetes uses the image already present on the node and only pulls from a registry if it is missing. Since we manually loaded the image into the kind node's containerd runtime in Step 3, the image is already present and no registry push is needed.
livenessProbe — Kubernetes restarts the container if /healthcheck stops returning 200.
readinessProbe — Kubernetes only sends traffic to a Pod once /healthcheck returns 200. During startup or a slow restart, unhealthy Pods are excluded from load balancing automatically.
resources — requests are what the scheduler uses to find a node with enough room. limits are the hard cap. Setting both is a production best practice.

Service

Create k8s/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: go-k8s-demo
spec:
  selector:
    app: go-k8s-demo
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: NodePort

The Service uses NodePort so we can reach it from outside the cluster. Port 80 on the Service maps to port 8080 on each Pod. The selector ties the Service to any Pod labelled app: go-k8s-demo.

Step 5: Deploy to Kubernetes

Apply both manifests:

kubectl apply -f k8s/

Check that the Deployment and Pods are running:

kubectl get deployments
kubectl get pods

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
go-k8s-demo    3/3     3            3           20s

NAME                            READY   STATUS    RESTARTS   AGE
go-k8s-demo-6d8b9f5c4d-4xqjk   1/1     Running   0          20s
go-k8s-demo-6d8b9f5c4d-7pnl2   1/1     Running   0          20s
go-k8s-demo-6d8b9f5c4d-kztr9   1/1     Running   0          20s

Check the Service:

kubectl get services

NAME           TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
go-k8s-demo   NodePort   10.96.145.203   <none>        80:31234/TCP   20s

Reach the application

With a kind cluster, NodePort services are not directly reachable on localhost. Use kubectl port-forward to tunnel traffic from your machine to the Service:

kubectl port-forward service/go-k8s-demo 8080:80

Leave that running and in a second terminal:

curl http://localhost:8080

Expected response:

{
  "message": "Hello from Kubernetes!",
  "hostname": "go-k8s-demo-7c7b7dd9f9-n7q56",
  "version": "v1",
  "time": "2026-06-02T16:36:47Z"
}

Note: kubectl port-forward tunnels to a single Pod, so the hostname field will be the same across multiple requests. In a real production cluster with a LoadBalancer service (AWS ELB, GCP LB), traffic would be distributed across all Pods and you would see different hostnames on each request.

Step 6: Perform a Rolling Update

Let's build a second version of the image with a changed message to simulate an application update.

Edit main.go — change the message to "Hello from Kubernetes v2!".

Build the new image and load it into the kind cluster using the same method as Step 3:

docker build -t go-k8s-demo:v2 .
docker save go-k8s-demo:v2 -o go-k8s-demo-v2.tar
MSYS_NO_PATHCONV=1 docker --context desktop-linux cp go-k8s-demo-v2.tar desktop-control-plane:/go-k8s-demo-v2.tar
MSYS_NO_PATHCONV=1 docker --context desktop-linux exec desktop-control-plane ctr images import /go-k8s-demo-v2.tar

Update the Deployment to use the new image:

kubectl set image deployment/go-k8s-demo go-k8s-demo=go-k8s-demo:v2

Watch the rollout happen in real time:

kubectl rollout status deployment/go-k8s-demo

Waiting for deployment "go-k8s-demo" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "go-k8s-demo" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "go-k8s-demo" rollout to finish: 1 old replicas are pending termination...
deployment "go-k8s-demo" successfully rolled out

Kubernetes terminates old Pods and starts new ones one at a time, keeping at least two running throughout. The application never went offline.

To roll back to v1:

kubectl rollout undo deployment/go-k8s-demo

Step 7: Scale the Deployment

Scale to 5 replicas:

kubectl scale deployment go-k8s-demo --replicas=5
kubectl get pods

Scale back down:

kubectl scale deployment go-k8s-demo --replicas=2

Kubernetes sends SIGTERM to the excess Pods and waits for them to exit before removing them.

Step 8: Inspect and Troubleshoot

Useful commands for day-to-day Kubernetes work:

# Describe a Pod — shows events, probe results, resource usage
kubectl describe pod <pod-name>

# Stream logs from all Pods matching the label
kubectl logs -l app=go-k8s-demo -f

# Get logs from a specific Pod
kubectl logs <pod-name>

# Open a shell inside a running container
kubectl exec -it <pod-name> -- sh

# Watch all resources in the default namespace
kubectl get all

Clean Up

When you are done:

kubectl delete -f k8s/

This removes the Deployment and Service. The kind cluster keeps running in the background. To delete it, go to Settings → Kubernetes in Docker Desktop and delete the cluster, or recreate it with a fresh state.

Project Structure Summary

The finished project looks like this:

go-k8s-demo/
├── main.go
├── go.mod
├── Dockerfile
└── k8s/
    ├── deployment.yaml
    └── service.yaml

What We Covered

Built a Go HTTP server with a /healthcheck endpoint.
Packaged it into a minimal Docker image using a multi-stage build.
Loaded the image into a local kind Kubernetes cluster running in Docker Desktop.
Declared the desired state with a Deployment (3 replicas, liveness/readiness probes, resource limits) and a Service (stable DNS, load balancing).
Performed a zero-downtime rolling update and rollback.
Scaled replicas up and down with a single command.

These same deployment.yaml and service.yaml files work unchanged on a production Kubernetes cluster (AWS EKS, GCP GKE, Azure AKS) — the main difference would be pointing the image at a real registry and usually setting imagePullPolicy to Always or using a unique version tag for each release. The concepts and workflow you practised here transfer directly.

You now have a fully functional local development playground running real Kubernetes nodes inside Docker!

If you want to look at the complete source files or check out more developer tools I've built to simplify cloud-native setups, head over to the original post:

Read the full guide on Solution Toolkit

Top 10 Free Online Tools Every Developer Should Bookmark

Azam Akram — Mon, 08 Jun 2026 23:21:22 +0000

Top 10 Free Online Tools Every Developer Should Bookmark

Disclosure: I built these tools after repeatedly running into the same development tasks over and over again. They're free to use, browser-based, and process data locally whenever possible.

As developers, we spend a surprising amount of time doing small repetitive tasks:

Decoding JWTs
Comparing configuration files
Converting timestamps
Generating UUIDs
Building cron expressions
Inspecting API payloads

Most of these tasks shouldn't require installing software or opening an IDE.

Here are 10 browser-based tools that save me time almost every week.

Quick Overview

Tool	Common Use Case
File Size Calculator	Check upload limits
Gzip Base64 Decoder	Decode compressed API payloads
JWT Debugger	Inspect authentication tokens
Text Compare	Compare configs and code
JSON Escape / Unescape	Work with encoded JSON
Cron Expression Builder	Create and validate cron schedules
YAML Formatter	Validate YAML files
Epoch Converter	Convert timestamps
UUID Generator	Generate unique IDs
JSON to Go Struct	Generate Go models

1. File Size Calculator

The Problem

You need to check how large a file is before:

Uploading it to S3
Sending it as an email attachment
Passing it through an API with payload limits

The Solution

A file size calculator lets you drop a file and instantly view its size in:

Bytes
KB
MB
GB

No uploads required.

Tool:

https://www.solutiontoolkit.com/tools/file-size-calculator

This is surprisingly useful when debugging upload failures caused by hidden size limits.

2. Gzip Base64 Decoder and Encoder

The Problem

You receive an API response that looks like this:

H4sIAAAAAAAAA6tWKkktLlGyUlIqS...

Instead of JSON, you're staring at compressed gibberish.

The Solution

A Gzip + Base64 decoder can:

Decode Base64
Decompress Gzip payloads
Reveal the original JSON

Tool:

https://www.solutiontoolkit.com/tools/gzip-base64-encoder-decoder

I've used this frequently when debugging:

AWS Lambda responses
EventBridge events
Internal microservice communication

3. JWT Debugger

The Problem

Authentication suddenly stops working.

You have a JWT token, but no idea whether:

It's expired
It contains the expected claims
The wrong signing algorithm was used

Example

{
  "sub": "123",
  "role": "admin",
  "exp": 1788336000
}

A quick inspection immediately reveals whether the token is still valid.

The Solution

A JWT debugger decodes:

Header
Payload
Expiration time
Algorithm

Tool:

https://www.solutiontoolkit.com/tools/jwt-debugger

No libraries or command-line tools required.

4. Text Compare and Diff Tool

The Problem

You have two configuration files that should be identical but aren't behaving the same.

Common examples:

Kubernetes manifests
Terraform configs
SQL queries
YAML files
JSON payloads

The Solution

A diff tool highlights:

Additions
Deletions
Modifications

Tool:

https://www.solutiontoolkit.com/tools/text-comparison-tool

It's often faster than creating a temporary Git repository just to compare two snippets.

5. JSON Escape and Unescape Tool

The Problem

You encounter JSON that looks like this:

"{\"name\":\"John\",\"age\":30}"

Technically valid.

Practically unreadable.

The Solution

Convert between:

Escaped JSON:

"{\"name\":\"John\"}"

and readable JSON:

{
  "name": "John"
}

Tool:

https://www.solutiontoolkit.com/tools/json-escape-unescape

Useful when working with:

Lambda payloads
Elasticsearch queries
Nested API requests

6. Cron Expression Builder

The Problem

You need a schedule that runs:

Every weekday at 9 AM UTC

But cron syntax is easy to forget.

Is it:

0 9 * * 1-5

9 0 * * 1-5

The Solution

A cron builder translates schedules into plain English.

Example:

0 9 * * 1-5

becomes:

Every weekday at 09:00 UTC

Tool:

https://www.solutiontoolkit.com/tools/cron-expression-builder

Supports:

Standard cron
AWS EventBridge
Kubernetes CronJobs
Jenkins

7. YAML Formatter and Validator

The Problem

YAML is whitespace-sensitive.

One incorrect indentation level can break:

Kubernetes deployments
GitHub Actions workflows
Docker Compose files
Helm charts

The Solution

A YAML validator can:

Format YAML
Validate syntax
Highlight exact error locations

Tool:

https://www.solutiontoolkit.com/tools/yaml-formatter

Finding the exact line number saves a surprising amount of frustration.

8. Epoch and Timestamp Converter

The Problem

Your logs contain:

1748563200

You need to know:

What date and time is this?

The Solution

Convert:

Unix timestamps → Human-readable dates
Dates → Unix timestamps

Tool:

https://www.solutiontoolkit.com/tools/timestamp-converter

This is one of those tools every backend developer eventually bookmarks.

9. UUID Generator and Inspector

The Problem

You need:

Test identifiers
Seed data
Temporary resource IDs

Or you're working with UUID v7 and want to inspect its embedded timestamp.

The Solution

Generate and validate:

UUID v4
UUID v7

Tool:

https://www.solutiontoolkit.com/tools/uuid-generator

Being able to generate multiple UUIDs with one click is especially useful during testing.

10. JSON to Go Struct Converter

The Problem

You receive a JSON response like this:

{
  "user": {
    "id": 123,
    "name": "John"
  }
}

Now you need matching Go structs.

Writing them manually is repetitive and error-prone.

The Solution

Generate:

Struct definitions
Nested structs
Array types
JSON tags

Tool:

https://www.solutiontoolkit.com/tools/json-to-go-struct

What would normally take several minutes can often be done in seconds.

Honourable Mentions

A few more tools that developers may find useful:

YAML to JSON Converter
URL Encoder and Decoder
Base64 Encoder and Decoder
Word Frequency Counter
File Hash Generator

Available here:

https://www.solutiontoolkit.com/tools

Final Thoughts

The best developer tools aren't always the biggest frameworks or the most advanced IDE plugins.

Sometimes they're the small utilities that eliminate a repetitive task and save a few minutes every day.

Those minutes add up.

What browser-based developer tools do you find yourself using most often?

I'd love to discover a few new ones for my own bookmarks list.

DEV Community: Azam Akram

I Built a Collection of 100+ Free Developer Tools That Run Entirely in the Browser

I Built a Collection of 100+ Free Developer Tools That Run Entirely in the Browser

My Goals

What's Included?

JSON & API Tools

Encoding & Decoding

Formatting & Validation

Developer Utilities

Image Tools

What I Learned Building It

Looking for Feedback

AWS ALB Scaling: Set Up Application Load Balancer with Auto Scaling Group (ASG)

What We'll Do

Prerequisites

Why Combine ALB with ASG?

Step 1: Create a Security Group

Step 2: Create a Launch Template

Step 3: Create an Auto Scaling Group (ASG)

Step 4: Create Target Group and Load Balancer

Create a Target Group

Create an Application Load Balancer (ALB)

Create a Listener and Link it to the Target Group

Attach the Target Group to the Auto Scaling Group

Step 5: Testing the Load Balancer

Step 6: Deleting the Setup

Conclusion

Building Kafka Producer-Consumer Using Go and Docker

Introduction

Go

Apache Kafka

Docker

Prerequisites

Download Code from Github

Project Overview

Building and Running the Application

Docker Compose for Kafka Setup

Kafka Consumer Service (Go)

go.mod

Message Model (model.go)

Kafka Consumer (consumer.go)

Application Entry Point (main.go)

Kafka Producer Service (Go)

go.mod

Message Model (model.go)

Kafka Producer (producer.go)

HTTP Handler (handler.go)

Application Entry Point (main.go)

Running the Application End-to-End

Step 1 — Start Kafka

Step 2 — Start the Consumer

Step 3 — Start the Producer

Step 4 — Send a Message

Step 5 — Observe the Consumer Logs

Step 6 — Check Health Endpoints

Step 7 — Graceful Shutdown

Summary

Deploy Your First Go App with Docker and Kubernetes

Prerequisites

Step 1: Create the Go Application

Step 2: Containerize with Docker

Build and test the image locally

Step 3: Create a Kubernetes Cluster in Docker Desktop

Load the image into the kind cluster

Step 4: Write Kubernetes Manifests

Deployment

Service

Step 5: Deploy to Kubernetes

Reach the application

Step 6: Perform a Rolling Update

Step 7: Scale the Deployment

Step 8: Inspect and Troubleshoot

Clean Up

Project Structure Summary

What We Covered

Top 10 Free Online Tools Every Developer Should Bookmark

Top 10 Free Online Tools Every Developer Should Bookmark

Quick Overview

1. File Size Calculator

The Problem

`go.mod`

Message Model (`model.go`)

Kafka Consumer (`consumer.go`)

Application Entry Point (`main.go`)

`go.mod`

Message Model (`model.go`)

Kafka Producer (`producer.go`)

HTTP Handler (`handler.go`)

Application Entry Point (`main.go`)