DEV Community: Kaushik Mitra

Creating a GKE Cluster and Deploying a Microservice Application (End-to-End)

Kaushik Mitra — Sat, 03 Oct 2026 22:41:59 +0000

We've reached the final milestone of our Kubernetes learning journey!

So far, we have:

Set up a local Kubernetes cluster using Docker Desktop.
Built two microservices (add-service and multiply-service) and wired them together using Namespaces, Pods, and ClusterIP Services.
Configured NGINX Ingress Controller for path-based routing (/api/add and /api/multiply) with URL rewriting.
Pushed our container images to Google Cloud Artifact Registry.

Now, it's time to bring everything together into production: we'll provision a real Google Kubernetes Engine (GKE) cluster on Google Cloud, deploy our application, configure cloud ingress with a public Google Cloud Load Balancer, and test our live API on the internet!

Why GKE Autopilot?

Google Kubernetes Engine offers two operation modes:

Standard Mode: You manage and pay for the underlying virtual machines (Compute Engine worker nodes). You handle node provisioning, OS patching, and node pool configurations.
Autopilot Mode: Google manages the entire underlying node infrastructure, node pools, OS upgrades, and security hardening. You only define what your workloads need, and you pay exclusively for the CPU, memory, and storage requested by your actively running Pods.

For modern applications and learning environments, Autopilot is fantastic because it eliminates node management overhead completely while enforcing Kubernetes production best practices out of the box.

Prerequisites

Make sure you have:

A GCP account and project (e.g., kkm-kube-practice) with billing enabled.
Container images already pushed to Artifact Registry (asia-south1-docker.pkg.dev/...).
gcloud and kubectl installed on your machine.
The Kubernetes manifests and source code available on GitHub: MitraKumar/kube-prac-calculator-app.

Step 1: Enable the Kubernetes Engine API

Before creating a cluster, ensure the GKE API is active on your project:

gcloud services enable container.googleapis.com

Step 2: Provision the GKE Autopilot Cluster

Let's create an Autopilot cluster named autopilot-cluster-1 in the us-central1 region:

gcloud container clusters create-auto autopilot-cluster-1 \
    --region us-central1 \
    --project kkm-kube-practice

Note: Cluster provisioning usually takes 4 to 7 minutes as Google provisions the regional control planes and private VPC networking. Sit back, grab a coffee, and let Google do the heavy lifting!

Once creation finishes, you'll see:

NAME                 LOCATION     MASTER_VERSION      STATUS
autopilot-cluster-1  us-central1  1.31.x-gke.xxx      RUNNING

Step 3: Connect `kubectl` to Your GKE Cluster

To instruct your local kubectl to talk to your brand new GKE cluster, download the cluster credentials:

gcloud container clusters get-credentials autopilot-cluster-1 \
    --region us-central1 \
    --project kkm-kube-practice

Verify your active context:

kubectl config current-context

Output:

gke_kkm-kube-practice_us-central1_autopilot-cluster-1

Let's inspect the nodes:

kubectl get nodes

You will see the initial worker nodes provisioned by Autopilot.

Step 4: Important Autopilot Requirement — Resource Requests

One key difference between local Docker Desktop and GKE Autopilot is that Autopilot requires every container to declare CPU and memory requests and limits.

Because Autopilot scales nodes dynamically based on workload demands and bills based on pod resource consumption, it needs to know your pod's requirements.

If you inspect our Pod manifests (k8s/01-add-service-pod.yaml and k8s/03-multiply-service-pod.yaml), you'll see we explicitly declared:

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "250m"

💡 Tip: If you deploy a pod without resources on GKE Autopilot, Autopilot will automatically inject default resource values, but it's best practice to specify them explicitly.

Step 5: Install NGINX Ingress Controller on GKE using Helm

Just like we did locally, we need an Ingress Controller to route external HTTP traffic to our services. We'll install the official chart using Helm:

# 1. Add and update the official repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# 2. Install the NGINX Ingress Controller chart into GKE
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace

Output:

NAME: ingress-nginx
LAST DEPLOYED: Sat Oct  3 20:08:22 2026
NAMESPACE: ingress-nginx
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The ingress-nginx controller has been installed.
It may take a few minutes for the LoadBalancer IP to be available.

What happens on Google Cloud?

When Helm installs this chart on GKE:

GKE Autopilot schedules the ingress-nginx-controller pod and allocates compute resources automatically.
GKE detects the type: LoadBalancer Service in the ingress-nginx namespace.
Google Cloud automatically provisions a Google Cloud Network Load Balancer (NLB) in your GCP project!
Google assigns a public, routable IPv4 address to that Load Balancer.

Watch the service until the public EXTERNAL-IP is assigned:

kubectl get svc -n ingress-nginx -w

Initial output:

NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)
ingress-nginx-controller   LoadBalancer   34.118.235.60   <pending>     80:32234/TCP,443:32055/TCP

After about 1 to 2 minutes, the external IP will appear:

NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)
ingress-nginx-controller   LoadBalancer   34.118.235.60   136.80.62.73    80:32234/TCP,443:32055/TCP

We now have a dedicated public IP (136.80.62.73) routing internet traffic directly into our cluster!

Step 6: Deploy the Calculator Microservices

Now, let's deploy our manifests:

Namespace: 00-namespace.yaml
Add Service Pod & Service: 01-add-service-pod.yaml, 02-add-service-cluster-ip.yaml
Multiply Service Pod & Service: 03-multiply-service-pod.yaml, 04-multiply-service-cluster-ip.yaml
Docs Service Pod & Service: 06-docs-service-pod.yaml, 07-docs-service-cluster-ip.yaml
Ingress Routing Rules: 05-nginx-ingress-controller.yaml

Apply them sequentially (or all together):

kubectl apply -f k8s/00-namespace.yaml
kubectl apply -f k8s/01-add-service-pod.yaml
kubectl apply -f k8s/02-add-service-cluster-ip.yaml
kubectl apply -f k8s/03-multiply-service-pod.yaml
kubectl apply -f k8s/04-multiply-service-cluster-ip.yaml
kubectl apply -f k8s/06-docs-service-pod.yaml
kubectl apply -f k8s/07-docs-service-cluster-ip.yaml
kubectl apply -f k8s/05-nginx-ingress-controller.yaml

Verify the Deployments

Check the pods and services:

kubectl get all -n calculator-app

Output:

NAME                       READY   STATUS    RESTARTS   AGE
pod/add-service            1/1     Running   0          2m
pod/docs-service           1/1     Running   0          1m
pod/multiply-service       1/1     Running   0          2m

NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/add-service-cluster-ip        ClusterIP   34.118.228.222   <none>        3000/TCP   2m
service/docs-service-cluster-ip       ClusterIP   34.118.228.50    <none>        3000/TCP   1m
service/multiply-service-cluster-ip   ClusterIP   34.118.230.113   <none>        3000/TCP   2m

Check the Ingress resource:

kubectl get ingress -n calculator-app

Output:

NAME                     CLASS   HOSTS   ADDRESS        PORTS   AGE
calculator-api-ingress   nginx   *       136.80.62.73   80      2m

The Ingress is active and bound to our Google Cloud Load Balancer IP (136.80.62.73).

Step 7: Test Your Live Production Application!

Let's test our live microservices from anywhere in the world using curl (or directly from your browser):

1. Test Interactive Swagger UI Documentation:

curl -sI "http://136.80.62.73/"

Response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

🌐 Open http://136.80.62.73/ in your browser to explore the interactive Swagger documentation and test API endpoints right from the UI!

2. Test Addition API:

curl -s "http://136.80.62.73/api/add?a=10&b=20"

Response:

{
  "service": "add-service",
  "operation": "addition",
  "a": 10,
  "b": 20,
  "result": 30
}

3. Test Multiplication API:

curl -s "http://136.80.62.73/api/multiply?a=5&b=6"

Response:

{
  "service": "multiply-service",
  "operation": "multiplication",
  "a": 5,
  "b": 6,
  "result": 30
}

3. Test Health Check:

curl -s "http://136.80.62.73/api/add/health"

Response:

{
  "status": "UP",
  "service": "add-service"
}

It works! The Google Cloud Load Balancer receives the HTTP request on port 80, directs it to the NGINX Ingress Controller, which rewrites the path and dispatches it over the internal cluster network to our respective Node.js pods.

Step 8: Clean Up Resources (Don't Skip This!)

Cloud resources cost money when left running. If you are experimenting or practicing, remember to tear down the cluster once you're done:

gcloud container clusters delete autopilot-cluster-1 \
    --region us-central1 \
    --project kkm-kube-practice \
    --quiet

Deleting the GKE cluster will automatically clean up the associated Google Cloud Network Load Balancer and internal VPC forwarding rules.

Conclusion & Series Retrospective

Over this 5-part journey, we built a complete end-to-end Kubernetes workflow:

Local Setup: Bootstrapped a frictionless single-node cluster using Docker Desktop.
Kubernetes Core: Built multi-service Node.js Express apps and mastered Namespaces, Pods, ClusterIP Services, Labels, and Selectors.
Ingress Routing: Configured the NGINX Ingress Controller to route path-based traffic with regex rewrites.
Artifact Management: Tagged and published production containers to Google Cloud Artifact Registry.
Cloud Deployment: Created a managed GKE Autopilot cluster, provisioned a Cloud Load Balancer, and served live API traffic.

I hope this step-by-step guide helps you navigate Kubernetes and cloud deployments with confidence.

If you followed along or have questions about GKE, Ingress, or microservices, drop a comment below—I'd love to hear your thoughts!

Pushing Container Images to Google Cloud Artifact Registry (Step-by-Step)

Kaushik Mitra — Sat, 03 Oct 2026 22:40:54 +0000

When running Kubernetes locally with Docker Desktop, you have a handy superpower: your local Kubernetes cluster shares your computer's local Docker daemon. Any image you build via docker build is immediately available to your local pods without needing to push it to the internet.

However, the moment you decide to deploy to a managed cloud cluster like Google Kubernetes Engine (GKE), that magic ends. GKE nodes run in Google Cloud's data centers and have no access to your laptop's disk. They need a secure, centralized container registry from which to pull your container images.

Google Container Registry (gcr.io) has now been deprecated in favor of Google Cloud Artifact Registry.

In this guide, we'll walk through setting up Google Cloud Artifact Registry, configuring Docker authentication, tagging our images, and pushing our microservices to Google Cloud.

Prerequisites

Before starting, make sure you have:

A Google Cloud Platform (GCP) account with an active project (e.g., kkm-kube-practice) and billing enabled.
The Google Cloud SDK (gcloud CLI) installed.
Docker installed and running on your machine.
The sample microservices and Dockerfiles from our GitHub repository: MitraKumar/kube-prac-calculator-app.

Step 1: Authenticate and Set Up Your GCP Project

First, let's log into GCP from our terminal and set our active project.

# Authenticate your Google account
gcloud auth login

# Set your active project ID
gcloud config set project kkm-kube-practice

💡 Tip: Replace kkm-kube-practice with your own GCP Project ID throughout this tutorial!

Enable the Artifact Registry API

Before we can create a repository, we must enable the Artifact Registry API on our project:

gcloud services enable artifactregistry.googleapis.com

Step 2: Create a Docker Repository in Artifact Registry

Google Cloud Artifact Registry supports multiple package types (Docker, npm, Maven, Python, etc.). We need a Docker repository.

We will create a repository named kkm-dock located in the asia-south1 region (Mumbai). You can choose any region closest to you or your future GKE cluster (e.g., us-central1, europe-west1):

gcloud artifacts repositories create kkm-dock \
    --repository-format=docker \
    --location=asia-south1 \
    --description="Docker repository for K8s practice microservices"

Verify that the repository was created successfully:

gcloud artifacts repositories list

Output:

REPOSITORY  FORMAT  MODE                 LOCATION     DESCRIPTION
kkm-dock    DOCKER  STANDARD_REPOSITORY  asia-south1  Docker repository for K8s practice microservices

Step 3: Configure Docker Authentication

In order for your standard docker push and docker pull commands to securely authenticate against Google Cloud, Docker needs to know how to obtain GCP access tokens.

Google provides a credential helper integrated right into gcloud. Run this command:

gcloud auth configure-docker asia-south1-docker.pkg.dev

When prompted, confirm with Y.

What did this command just do? It updated your local ~/.docker/config.json file so that any time Docker interacts with asia-south1-docker.pkg.dev, it automatically retrieves an authentication token using your active gcloud session. No hardcoded passwords or long-lived API keys on your machine!

Step 4: Understand the Artifact Registry Image Naming Structure

Google Cloud Artifact Registry requires a specific image naming format:

[REGION]-docker.pkg.dev/[PROJECT_ID]/[REPOSITORY_NAME]/[IMAGE_NAME]:[TAG]

Let's break down our path:

Region Host: asia-south1-docker.pkg.dev
Project ID: kkm-kube-practice
Repository: kkm-dock
Image Name: add-service, multiply-service, and docs-service
Tag: 1.0

Putting it all together gives our fully qualified image URLs:

asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/add-service:1.0
asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/multiply-service:1.0
asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/docs-service:1.0

Step 5: Tag Your Local Images

Now, let's tag our existing local images with the Artifact Registry URL.

If you already built add-service:1.0, multiply-service:1.0, and docs-service:1.0 locally, you can tag them directly:

docker tag add-service:1.0 \
  asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/add-service:1.0

docker tag multiply-service:1.0 \
  asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/multiply-service:1.0

docker tag docs-service:1.0 \
  asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/docs-service:1.0

Verify with docker images:

docker images | grep pkg.dev

Output:

REPOSITORY                                                               TAG   IMAGE ID       SIZE
asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/add-service        1.0   420017c8b88f   49.9MB
asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/docs-service       1.0   517e75577f70   60.4MB
asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/multiply-service   1.0   c91c40363892   49.9MB

Step 6: Push the Images to Artifact Registry

Now comes the exciting moment—pushing your images to the cloud!

docker push asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/add-service:1.0
docker push asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/multiply-service:1.0
docker push asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/docs-service:1.0

Step 7: Verify the Uploaded Images

You can list the images stored in your repository directly from the command line:

gcloud artifacts docker images list asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock

Output:

IMAGE                                                                    TAGS  DIGEST        CREATE_TIME
asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/add-service        1.0   sha256:...   2026-10-03
asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/docs-service       1.0   sha256:...   2026-10-03
asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/multiply-service   1.0   sha256:...   2026-10-03

You can also open the Google Cloud Console, navigate to Artifact Registry -> Repositories -> kkm-dock, and inspect your uploaded image layers, vulnerabilities, and tags visually.

Step 8: Update Your Kubernetes Manifests

Now that our images are hosted in Artifact Registry, we update the image: fields in our Kubernetes manifests so GKE knows where to pull them from.

In k8s/01-add-service-pod.yaml:

spec:
  containers:
  - name: add-service
    image: asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/add-service:1.0

In k8s/03-multiply-service-pod.yaml:

spec:
  containers:
  - name: multiply-service
    image: asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/multiply-service:1.0

And in k8s/06-docs-service-pod.yaml:

spec:
  containers:
  - name: docs-service
    image: asia-south1-docker.pkg.dev/kkm-kube-practice/kkm-dock/docs-service:1.0

Note on Permissions: When running on GKE within the same GCP project, GKE default service accounts automatically have read/pull permissions to Artifact Registry repositories in the same project! No complex imagePullSecrets required.

Conclusion & Next Step

Our microservice container images are now safely built, tagged, and published to Google Cloud Artifact Registry.

In the final post of this series, we will:

Spin up a managed Google Kubernetes Engine (GKE Autopilot) cluster.
Install the NGINX Ingress controller on GKE.
Deploy our calculator application to production and test it using a real public Cloud Load Balancer IP!

Stay tuned, and drop any questions in the comments below!

Installing NGINX Ingress Controller in Docker Desktop: A Step-by-Step Guide

Kaushik Mitra — Sat, 03 Oct 2026 22:39:58 +0000

In our previous post, we deployed three microservices (add-service, multiply-service, and docs-service) and exposed them using Kubernetes ClusterIP services. While everything was running smoothly, there was one major limitation: ClusterIP services are internal to the cluster. To access them, we had to rely on kubectl port-forward.

In a real-world scenario, you want a single entry point (usually port 80 or 443) that acts as an intelligent reverse proxy, routing:

Requests for / to the docs-service (Swagger/OpenAPI documentation)
Requests for /api/add to the add-service
Requests for /api/multiply to the multiply-service

If you've read my previous article on how DDEV and Lando use Traefik for routing, this concept will feel very familiar. In Kubernetes, this reverse-proxy layer is handled by an Ingress Controller.

In this guide, we'll install the official NGINX Ingress Controller in Docker Desktop and configure path-based routing with URL rewrites.

📦 Source Code: All the manifests, Dockerfiles, and architecture diagrams used in this post are available on GitHub: MitraKumar/kube-prac-calculator-app.

Ingress Resource vs. Ingress Controller

Before we run any commands, let's clarify an important distinction that trips up many beginners:

Ingress Resource (kind: Ingress): This is just a set of routing rules written in YAML (e.g., "forward /api/add to service A"). By itself, this YAML file does nothing!
Ingress Controller: This is the actual software engine (like NGINX, Traefik, or HAProxy) running inside your cluster. It watches for Ingress resources, reads the rules, and automatically configures its internal reverse-proxy routing tables.

To route traffic, you must have an Ingress Controller running.

Step 1: Install NGINX Ingress Controller using Helm

While you can install the Ingress Controller using static YAML manifests, the recommended and industry-standard way to manage it is using Helm (the package manager for Kubernetes).

Using Helm makes upgrading, modifying configurations, and uninstalling as simple as running a single command.

💡 Don't have Helm installed? You can install Helm in seconds:

macOS: brew install helm

Ubuntu/Debian: sudo snap install helm --classic or sudo apt-get install helm

Windows: winget install Helm.Helm or choco install kubernetes-helm

1. Add the Ingress-NGINX Helm Repository

First, add the official NGINX Ingress repository to Helm:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

Update your local Helm repository cache:

helm repo update

2. Install the Helm Chart

Now, install the chart into its own dedicated namespace (ingress-nginx):

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace

Output:

NAME: ingress-nginx
LAST DEPLOYED: Sat Oct  3 20:08:22 2026
NAMESPACE: ingress-nginx
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The ingress-nginx controller has been installed.
It may take a few minutes for the LoadBalancer IP to be available.

What did Helm just create?

By default, the Helm chart creates:

The ingress-nginx namespace.
The NGINX Ingress Controller deployment and replica pods.
RBAC roles, cluster roles, service accounts, and admission webhooks.
A LoadBalancer service that Docker Desktop automatically binds to ports 80 and 443 on localhost.

Step 2: Verify the Controller is Running

Let's monitor the deployment and wait until the controller pod is in the Running state:

kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=120s

Check the pods in the ingress-nginx namespace:

kubectl get pods -n ingress-nginx

Output:

NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-controller-7c444fc6cf-djw7s   1/1     Running     0          45s

Now let's check the Service:

kubectl get svc -n ingress-nginx

Output:

NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.96.231.158   localhost     80:30905/TCP,443:30913/TCP   60s
ingress-nginx-controller-admission   ClusterIP      10.96.233.245   <none>        443/TCP                      60s

Notice: The EXTERNAL-IP is listed as localhost (or an internal bridge IP like 172.18.0.x). This means traffic sent to http://localhost:80 will now be routed directly to the NGINX Ingress Controller!

Step 3: Create the Ingress Rules (`05-nginx-ingress-controller.yaml`)

Now that the controller is listening, let's give it rules to route our calculator microservices.

Here is k8s/05-nginx-ingress-controller.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: calculator-api-ingress
  namespace: calculator-app
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /api/add(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: add-service-cluster-ip
            port:
              number: 3000
      - path: /api/multiply(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: multiply-service-cluster-ip
            port:
              number: 3000
      - path: /()(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: docs-service-cluster-ip
            port:
              number: 3000

Breaking Down the Configuration

Let's dissect the important parts of this manifest:

ingressClassName: nginx:
Tells Kubernetes that this Ingress resource should be managed by the NGINX Ingress Controller we just installed.
nginx.ingress.kubernetes.io/use-regex: "true":
Enables regular expression matching on the paths.
Path Matching & Rewrite Target (/$2):
Our microservices are simple Express apps that listen for requests on the root path / (e.g., /?a=10&b=20).
However, our public URL is /api/add?a=10&b=20.

If NGINX forwarded /api/add directly to the container, Express would return a 404 Not Found because it doesn't have an /api/add route!

Here is where regex capture groups save the day:

/api/add(/|$)(.*) matches the addition route. Group 1 is (/|$), Group 2 is (.*).
/api/multiply(/|$)(.*) matches the multiplication route.
rewrite-target: /$2: NGINX strips the prefix /api/add and rewrites the incoming request to /$2 before forwarding it to our Node.js pod!

Serving Swagger Documentation at Root (/ via /()(.*)): For our docs-service, we match /()(.*).
- Group 1 is empty ().
- Group 2 (.*) captures the rest of the path (e.g. / becomes /, /swagger-ui.css becomes /swagger-ui.css, /openapi.json becomes /openapi.json).
- NGINX matches the longer paths (/api/add and /api/multiply) first, and falls back to our Swagger UI documentation for all root and documentation requests!

Step 4: Apply the Ingress and Test on Localhost

Let's apply our Ingress manifest:

kubectl apply -f k8s/05-nginx-ingress-controller.yaml

Verify that the Ingress resource was created:

kubectl get ingress -n calculator-app

Output:

NAME                     CLASS   HOSTS   ADDRESS     PORTS   AGE
calculator-api-ingress   nginx   *       localhost   80      10s

Testing the Endpoints!

No port-forwarding needed anymore! We can query http://localhost directly on port 80:

1. Test Swagger UI Documentation (Root Route `/`):

curl -sI "http://localhost/"

Response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

🌐 You can now open http://localhost/ directly in your browser to view and interact with the Swagger UI documentation!

2. Test Addition Service:

curl -s "http://localhost/api/add?a=10&b=20"

Response:

{
  "service": "add-service",
  "operation": "addition",
  "a": 10,
  "b": 20,
  "result": 30
}

3. Test Multiplication Service:

curl -s "http://localhost/api/multiply?a=5&b=6"

Response:

{
  "service": "multiply-service",
  "operation": "multiplication",
  "a": 5,
  "b": 6,
  "result": 30
}

4. Test Health Checks:

curl -s "http://localhost/api/add/health"

Response:

{
  "status": "UP",
  "service": "add-service"
}

All three services are working seamlessly through a single local entry point on standard port 80!

Troubleshooting Common Gotchas

Port 80 Already in Use on Host: If the ingress controller pod stays in Pending or crashes with port binding errors, another application on your machine (Apache, system Nginx, IIS, Skype, or local dev tools) is already listening on port 80. Stop that service or inspect who is using port 80 with:

   sudo lsof -i :80

Getting a 404 from NGINX vs Node.js:
- If the response header contains Server: openresty or Server: nginx and returns HTML 404 Not Found, your Ingress path regex didn't match the URL.
- If the response returns JSON Cannot GET /api/add, your rewrite-target annotation is missing or misconfigured, and the un-rewritten path reached Express.

Conclusion & Next Step

We now have a complete, professional local Kubernetes environment running on Docker Desktop:

Multi-service backend in its own Namespace.
Stable internal routing via ClusterIP Services.
External path routing and URL rewrites via NGINX Ingress Controller.

Our next big step is taking this to the cloud. But before we can deploy to Google Kubernetes Engine (GKE), GKE needs a way to download our container images.

In the next post, we will set up Google Cloud Artifact Registry, configure Docker authentication, and push our microservice images to GCP!

Leave a comment below if you ran into any regex or routing issues!

A Hands-On Guide with Microservices

Kaushik Mitra — Sat, 03 Oct 2026 21:45:11 +0000

When starting out with Kubernetes, terms like Pods, Deployments, Services, and Namespaces get thrown around constantly. Reading definitions in the documentation is one thing, but seeing how they actually connect and route traffic between multiple services is where the concepts truly click.

Today, we're going to build and deploy a practical multi-service application: a Calculator App composed of three independent microservices:

add-service: An Express.js microservice handling addition requests (:3001).
multiply-service: An Express.js microservice handling multiplication requests (:3002).
docs-service: An Express.js microservice serving interactive Swagger/OpenAPI documentation (:3003).

We will package them with Docker, create Kubernetes manifests, and understand how Pods and ClusterIP Services work together under the hood.

📦 Source Code: You can find the full source code, Dockerfiles, and Kubernetes manifests for this project on GitHub: MitraKumar/kube-prac-calculator-app.

The Application Architecture

Before touching any Kubernetes YAML, let's understand what we are deploying:

                          [Client Request]
                                 |
        +------------------------+------------------------+
        |                        |                        |
        v                        v                        v
+-----------------------+ +----------------------------+ +------------------------+
| add-service-cluster-ip| | multiply-service-cluster-ip| | docs-service-cluster-ip|
| Service (Port 3000)   | | Service (Port 3000)        | | Service (Port 3000)    |
+-----------------------+ +----------------------------+ +------------------------+
        |                                |                        |
        v                                v                        v
+-----------------------+ +----------------------------+ +------------------------+
| Pod: add-service      | | Pod: multiply-service      | | Pod: docs-service      |
| (:3001)               | | (:3002)                    | | (:3003 - Swagger UI)   |
+-----------------------+ +----------------------------+ +------------------------+

Each service is a lightweight Node.js Express server.

1. `add-service` (`add-service/index.js`)

Listens on port 3001 and handles addition via query parameters ?a=10&b=20 or JSON body:

const express = require('express');
const app = express();

const PORT = process.env.PORT || 3001;
app.use(express.json());

function handleAddition(req, res) {
  const a = parseFloat(req.query.a ?? req.body?.a);
  const b = parseFloat(req.query.b ?? req.body?.b);

  if (isNaN(a) || isNaN(b)) {
    return res.status(400).json({
      error: 'Please provide valid numbers for "a" and "b" via query params or JSON body.'
    });
  }

  return res.json({
    service: 'add-service',
    operation: 'addition',
    a,
    b,
    result: a + b
  });
}

app.get('/health', (req, res) => res.json({ status: 'UP', service: 'add-service' }));
app.get('/', handleAddition);

app.listen(PORT, () => console.log(`Add Service is running on http://localhost:${PORT}`));

2. `multiply-service` (`multiply-service/index.js`)

Identical structure, but performs multiplication and listens on port 3002:

const express = require('express');
const app = express();

const PORT = process.env.PORT || 3002;
app.use(express.json());

function handleMultiplication(req, res) {
  const a = parseFloat(req.query.a ?? req.body?.a);
  const b = parseFloat(req.query.b ?? req.body?.b);

  if (isNaN(a) || isNaN(b)) {
    return res.status(400).json({
      error: 'Please provide valid numbers for "a" and "b" via query params or JSON body.'
    });
  }

  return res.json({
    service: 'multiply-service',
    operation: 'multiplication',
    a,
    b,
    result: a * b
  });
}

app.get('/health', (req, res) => res.json({ status: 'UP', service: 'multiply-service' }));
app.get('/', handleMultiplication);

app.listen(PORT, () => console.log(`Multiply Service is running on http://localhost:${PORT}`));

3. `docs-service` (`docs-service/index.js`)

Listens on port 3003 and serves an interactive Swagger UI documentation at / and OpenAPI specification at /openapi.json:

const express = require('express');
const swaggerUi = require('swagger-ui-express');
const swaggerDocument = require('./swagger.json');

const app = express();
const PORT = process.env.PORT || 3003;

app.use(express.json());

// Health check endpoint
app.get('/health', (req, res) => res.json({ status: 'UP', service: 'docs-service' }));

// Raw OpenAPI JSON spec
app.get('/openapi.json', (req, res) => res.json(swaggerDocument));

// Swagger UI at root route /
app.use('/', swaggerUi.serve);
app.get('/', swaggerUi.setup(swaggerDocument));

app.listen(PORT, () => console.log(`Docs Service is running on http://localhost:${PORT}`));

4. Dockerizing the Services

All three services use a clean, lightweight Dockerfile based on Node Alpine:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install --omit=dev

COPY . .

EXPOSE 3001 # 3002 for multiply, 3003 for docs
CMD ["node", "index.js"]

Build the local images with:

docker build -t add-service:1.0 ./add-service
docker build -t multiply-service:1.0 ./multiply-service
docker build -t docs-service:1.0 ./docs-service

Diving into Kubernetes Concepts

Now, let's deploy these microservices into our Kubernetes cluster. We organize all our manifests inside a k8s/ folder:

k8s/
├── 00-namespace.yaml
├── 01-add-service-pod.yaml
├── 02-add-service-cluster-ip.yaml
├── 03-multiply-service-pod.yaml
├── 04-multiply-service-cluster-ip.yaml
├── 06-docs-service-pod.yaml
└── 07-docs-service-cluster-ip.yaml

Step 1: Isolating with Namespaces (`00-namespace.yaml`)

Namespaces help you group related resources logically and prevent naming collisions across teams or environments.

apiVersion: v1
kind: Namespace
metadata:
  name: calculator-app

Apply it:

kubectl apply -f k8s/00-namespace.yaml

Step 2: What is a Pod? (`01-add-service-pod.yaml`)

In Docker, the atomic unit is a container. In Kubernetes, the smallest deployable unit is a Pod.

A Pod is a wrapper around one or more tightly coupled containers that share the same network namespace (IP address and port space) and storage volumes.

Here is our Pod manifest for add-service:

apiVersion: v1
kind: Pod
metadata:
  name: add-service
  namespace: calculator-app
  labels:
    app.kubernetes.io/name: add-service
spec:
  containers:
  - name: add-service
    image: add-service:1.0
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "250m"
    ports:
      - containerPort: 3001

Key details:

metadata.labels: We attach a label app.kubernetes.io/name: add-service. This label acts as a metadata tag that our Service will look for.

resources.requests & limits: Specifies the minimum and maximum CPU/RAM the pod can consume.

containerPort: 3001: The port on which our Node.js app inside the container listens.

Likewise, 03-multiply-service-pod.yaml defines the multiply Pod (containerPort 3002) and 06-docs-service-pod.yaml defines the Swagger UI docs Pod (containerPort 3003):

apiVersion: v1
kind: Pod
metadata:
  name: docs-service
  namespace: calculator-app
  labels:
    app.kubernetes.io/name: docs-service
spec:
  containers:
  - name: docs-service
    image: docs-service:1.0
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "250m"
    ports:
      - containerPort: 3003

Apply all three pods:

kubectl apply -f k8s/01-add-service-pod.yaml
kubectl apply -f k8s/03-multiply-service-pod.yaml
kubectl apply -f k8s/06-docs-service-pod.yaml

Check the pods:

kubectl get pods -n calculator-app

Output:

NAME               READY   STATUS    RESTARTS   AGE
add-service        1/1     Running   0          25s
docs-service       1/1     Running   0          18s
multiply-service   1/1     Running   0          20s

Step 3: Why Do We Need Services?

Here is the fundamental challenge with Pods in Kubernetes: Pods are ephemeral.

Pods get created, crash, get restarted, or get scheduled onto different nodes. Every time a Pod restarts, it receives a new internal IP address. If multiply-service needs to talk to add-service, it cannot rely on a hardcoded Pod IP.

Enter the Kubernetes Service.

A Service provides a stable virtual IP (ClusterIP) and a stable DNS name that never changes, even if underlying pods die and get replaced.

Let's look at k8s/02-add-service-cluster-ip.yaml:

apiVersion: v1
kind: Service
metadata:
  name: add-service-cluster-ip
  namespace: calculator-app
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: add-service
  ports:
  - port: 3000
    targetPort: 3001

The Secret Sauce: Labels and Selectors

How does the Service know which Pod to send traffic to?

Look at:

Service spec.selector: app.kubernetes.io/name: add-service
Pod metadata.labels: app.kubernetes.io/name: add-service

The Service continuously queries the Kubernetes API for any pods bearing that exact label and maintains an internal list of endpoints.

Port vs Target Port

This often confuses beginners:

port: 3000: The port that the Service itself exposes inside the cluster. Other services will talk to add-service-cluster-ip:3000.
targetPort: 3001: The port that the underlying Pod container is actually listening on.

Kubernetes automatically routes incoming requests on port 3000 to port 3001 on the container!

Now let's check k8s/04-multiply-service-cluster-ip.yaml:

apiVersion: v1
kind: Service
metadata:
  name: multiply-service-cluster-ip
  namespace: calculator-app
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: multiply-service
  ports:
  - port: 3000
    targetPort: 3002

Notice how all three services expose port 3000 to the internal cluster network, even though their underlying containers listen on 3001, 3002, and 3003. That is the elegance of Service abstraction.

Here is k8s/07-docs-service-cluster-ip.yaml:

apiVersion: v1
kind: Service
metadata:
  name: docs-service-cluster-ip
  namespace: calculator-app
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: docs-service
  ports:
  - port: 3000
    targetPort: 3003

Apply all three services:

kubectl apply -f k8s/02-add-service-cluster-ip.yaml
kubectl apply -f k8s/04-multiply-service-cluster-ip.yaml
kubectl apply -f k8s/07-docs-service-cluster-ip.yaml

Check the services:

kubectl get svc -n calculator-app

Output:

NAME                          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
add-service-cluster-ip        ClusterIP   10.96.220.14     <none>        3000/TCP   40s
docs-service-cluster-ip       ClusterIP   10.96.180.25     <none>        3000/TCP   15s
multiply-service-cluster-ip   ClusterIP   10.96.115.82     <none>        3000/TCP   35s

Step 4: Testing Internal Connectivity

Because ClusterIP services are strictly internal, they do not have an external IP address (EXTERNAL-IP: <none>). They cannot be directly reached from your browser yet.

To verify that our Services are properly routing to our Pods, we can use kubectl port-forward to tunnel traffic from our host machine into each Service:

# In Terminal 1: Forward add-service
kubectl port-forward svc/add-service-cluster-ip 8001:3000 -n calculator-app

In another terminal, test addition:

curl "http://localhost:8001/?a=15&b=25"

Response:

{
  "service": "add-service",
  "operation": "addition",
  "a": 15,
  "b": 25,
  "result": 40
}

Now let's test the multiplication service:

# In Terminal 2: Forward multiply-service
kubectl port-forward svc/multiply-service-cluster-ip 8002:3000 -n calculator-app

Test multiplication:

curl "http://localhost:8002/?a=6&b=7"

Response:

{
  "service": "multiply-service",
  "operation": "multiplication",
  "a": 6,
  "b": 7,
  "result": 42
}

And finally, test the documentation service:

# In Terminal 3: Forward docs-service
kubectl port-forward svc/docs-service-cluster-ip 8003:3000 -n calculator-app

Test docs health check and Swagger HTML:

curl -s "http://localhost:8003/health"

Response:

{
  "status": "UP",
  "service": "docs-service"
}

It works! Each Service successfully accepts traffic on port 3000 and maps it to the respective container ports (3001, 3002, and 3003).

Summary & What's Missing?

Here is what we achieved:

Created a dedicated Namespace (calculator-app).
Created Pods for three independent microservices with resource constraints.
Created ClusterIP Services that decouple network routing from ephemeral pod lifecycles using Labels & Selectors.

The Big Question:
In a production app, we cannot ask users to run kubectl port-forward to access our API, nor do we want to open multiple random ports for each service. We want a single entry point (e.g., http://localhost/api/add and http://localhost/api/multiply) on standard HTTP port 80.

In the next post, we will install and configure the NGINX Ingress Controller in Docker Desktop to achieve intelligent path-based routing.

Have any questions about Labels, Selectors, or ClusterIP? Drop a comment below!

Setting up a Kubernetes Cluster Locally with Docker Desktop

Kaushik Mitra — Sat, 03 Oct 2026 21:43:25 +0000

Recently I've started diving deeper into Kubernetes. If you are starting your cloud-native or container orchestration journey, the sheer number of tools out there can feel overwhelming—Minikube, Kind, K3s, MicroK8s, and cloud-managed options.

When you just want to get your hands dirty without spending money on cloud resources or configuring complex virtual machines, Docker Desktop offers the simplest starting point.

Did you know that Docker Desktop comes with a fully functional single-node Kubernetes cluster built right into it? With a single checkbox, you can spin up a control plane and node right on your machine!

In this guide, we'll walk through enabling Kubernetes in Docker Desktop, verifying your environment with kubectl, and testing our local cluster.

Why Docker Desktop for Local Kubernetes?

For beginners and everyday local development, Docker Desktop has a few distinct advantages:

Zero Extra Virtualization Setup: If you already use Docker Desktop on macOS, Windows (via WSL2), or Linux, you don't need to install VirtualBox, Hyper-V extras, or special network bridges.
Shared Docker Daemon: Container images built locally via docker build are instantly accessible to your local Kubernetes cluster without needing to push to Docker Hub or a remote registry first!
Low Friction: Starting, stopping, or resetting your entire cluster takes just one click from the UI.

Prerequisites

Before we start, make sure you have:

Docker Desktop installed and running.
A terminal (Bash, Zsh, or PowerShell).
Recommended: At least 4GB to 8GB of RAM allocated to Docker Desktop (check Settings -> Resources).

📦 Source Code: You can find the complete source code, Dockerfiles, and Kubernetes manifests for this entire series on GitHub: MitraKumar/kube-prac-calculator-app.

Step 1: Enable Kubernetes in Docker Desktop

By default, Docker Desktop runs only the Docker engine. Enabling Kubernetes is straightforward:

Open Docker Desktop.
Click on the Settings gear icon in the top-right corner.
In the left navigation menu, click on Kubernetes.
Check the box labeled Enable Kubernetes.
(Optional) You can leave "Show system containers" unchecked for now to keep your docker ps output clean.
Click Apply & restart.

Step 2: Verify `kubectl` and Cluster Connection

kubectl is the official command-line tool for communicating with a Kubernetes cluster. Docker Desktop automatically installs and configures kubectl for you.

Let's open our terminal and verify our client version:

kubectl version --client

You should see output similar to:

Client Version: v1.31.0
Kustomize Version: v5.4.2

Checking Configured Contexts

Kubernetes uses a "context" to know which cluster and user account to communicate with. Docker Desktop creates a context named docker-desktop.

Run:

kubectl config get-contexts

Output:

CURRENT   NAME             CLUSTER          AUTHINFO         NAMESPACE
*         docker-desktop   docker-desktop   docker-desktop

If the asterisk (*) is not next to docker-desktop, switch to it explicitly:

kubectl config use-context docker-desktop

Step 3: Inspect Your Local Node and Control Plane

Now that kubectl is pointed at your local cluster, let's verify cluster health:

kubectl cluster-info

Output:

Kubernetes control plane is running at https://kubernetes.docker.internal:6443
CoreDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Let's check the cluster nodes:

kubectl get nodes

Output:

NAME             STATUS   ROLES           AGE   VERSION
docker-desktop   Ready    control-plane   1d    v1.31.0

Notice that docker-desktop acts as both the control-plane and the worker node. It is in the Ready status, meaning it is ready to schedule workloads!

Step 4: Test Driving the Cluster

To ensure everything is working as expected, let's deploy a quick standalone Nginx pod:

kubectl run test-nginx --image=nginx --port=80

Check the pod status:

kubectl get pods

Output:

NAME         READY   STATUS    RESTARTS   AGE
test-nginx   1/1     Running   0          15s

Let's forward a local port to test traffic reaching the pod:

kubectl port-forward pod/test-nginx 8080:80

Now open another terminal or your browser at http://localhost:8080 (or run curl http://localhost:8080). You should see the welcome page for Nginx!

Once verified, press Ctrl+C to stop the port-forward and delete the test pod:

kubectl delete pod test-nginx

Useful Tips for Docker Desktop Kubernetes

How Local Images Work (The Magic Trick): When running Docker Desktop Kubernetes, your local Docker engine and Kubernetes share the same image store. If you build an image locally:

   docker build -t my-app:1.0 .

You can specify image: my-app:1.0 in your Kubernetes pod manifest with imagePullPolicy: Never or imagePullPolicy: IfNotPresent, and Kubernetes will use your local image without needing any push or registry setup!

Resetting the Cluster: If something goes wrong while experimenting, you don't have to troubleshoot for hours. Go back to Docker Desktop Settings -> Kubernetes and click Reset Kubernetes Cluster. In seconds, you get a clean slate.

Conclusion & What's Next

Setting up Kubernetes locally shouldn't be intimidating. Docker Desktop gives you an instant, robust environment right out of the box with zero fuss.

In the next post, we will build a real multi-service calculator application using Node.js & Express, package it into containers, and explore the core building blocks of Kubernetes: Namespaces, Pods, and ClusterIP Services.

Please leave a comment below if you found this guide helpful or if you run into any issues during your setup!

Multi-Agent Interview Coach

Kaushik Mitra — Sun, 19 Jul 2026 18:41:06 +0000

This post is my submission for DEV Education Track: Build Multi-Agent Systems with ADK.

What I Built

Preparing for technical interviews can be overwhelming. I wanted to build a tool that doesn't just give generic questions, but actually analyzes my specific resume to challenge my unique skill set. This led me to build a multi-agent system using the ADK. This multi-agent system, will take user resume and extracts their profile for generating Interview Questions specialized to the candidate profile. The agents communicate in a sequential loop: The Profiler extracts data -> The Interviewer generates questions -> The Judge validates them. If the Judge rejects a question, the Interviewer re-drafts it, ensuring only high-quality, resume-relevant questions make it to the user.

Cloud Run Embed

Your Agents

Profiler

Receives a resume PDF GCS path, downloads it in-memory, parses the text content, and builds a summary of skills.

Interviewer

Reads the candidate summary and drafts 3 technical interview questions designed to test the boundaries of their experience.

Analyzes the drafted questions. Passes the iteration if they are resume-specific; rejects/fails them if they are too generic.

Key Learnings

This project was a fantastic weekend challenge. Working through the Google Codelab gave me a solid grasp of agent-based architectures, specifically implementing Agent, LoopAgent, and SequentialAgent to create a robust workflow.

A few key technical takeaways included:

Managing Statelessness: Learning to handle agent sessions in a Cloud Run environment was a great lesson in explicit session lifecycle management.
Cloud Integration: Integrating Google Cloud Storage for file handling taught me how to bridge in-memory document processing with persistent cloud storage efficiently.
Deployment Architecture: Mastering the transition from local development to a containerized, production-ready Cloud Run deployment provided deep insights into modern backend orchestration.

Check the Code from Github: https://github.com/MitraKumar/interview-coach

Magic behind DDEV & Lando Routing

Kaushik Mitra — Tue, 28 Oct 2025 11:14:57 +0000

Today we'll discuss how the these docker based local environments for development like ddev or lando works.
These tools makes everything magical, and the end user just needs to setup a project run commands like ddev start or lando start and all the docker containers will spins up and the user will be able to visit the web page by with the url .ddev.site or in case of lando .lndo.site.

😉 Spoiler Alert all these tools uses cheeky DNS mapping & reverse proxy like tool traefik.

This guide is perfect for beginners or intermediate developers looking to understand how containerized local dev environments like DDEV use Traefik for networking.

If you're new to tools like DDEV or Lando and don't know what they are used for, they are local development environment based on Docker. You can easily setup a development environment for Drupal or Wordpress or MERN/MEAN and many other frameworks. As they use Docker containers for installing dependencies local development becomes very easy.

Let's take an example with DDEV.
In DDEV you can setup a Wordpress Project simply with the following commands, considering DDEV is already setup on your system.

cd <project-directory-name>
ddev config --project-type=wordpress --docroot=.
ddev wp core download
ddev wp core install --url=https://<project-directory-name>.ddev.site --title="<Site Name>"
--admin_user=admin --admin_password=admin --admin_email=admin@example.com

Now after setting up the project, ddev start will spin up all the containers & run your site in the URL https://<project-directory-name>.ddev.site

Today we'll discuss how this internal routing of https://<project-directory-name>.ddev.site works to your local site.

This is mainly done in two phases

DNS Mapping

DNS or Domain Name Server mapping is done to assign an IP address to a specific domain. When you type https://google.com on the browser. The browser doesn't know what server to request & how it can serve the html. The domain https://google.com is being resolved to a IP & then the client or the browser requests the server. This is called DNS Mapping.
Now in order the browser to know that accessing a site with the URL https://<project-directory-name>.ddev.site needs to request it's own machine where the project belongs. The URL needs to be resolve to 127.0.0.1.
This custom DNS mapping is created for DDEV & Lando.
You can check this by resolving the URLs *.ddev.site or *.lndo.site

In this simple way, ddev or lando creates custom URL for local Development.

Proxy Server — Enter Traefik

Now that DNS mapping ensures *.ddev.site (or *.lndo.site) resolves to your local machine (127.0.0.1), the next question is: how does your browser’s request for
https://<project-directory-name>.ddev.site actually reach the correct container running your project?

This is where Traefik steps in.

Traefik is a modern reverse proxy and load balancer designed for containerized environments. It automatically discovers running containers and routes incoming HTTP/HTTPS requests to the right service — all without you lifting a finger.

In DDEV (and similarly in Lando), Traefik runs as a global container that listens on ports 80 (HTTP) and 443 (HTTPS). When you run ddev start, your project containers register themselves with Traefik through Docker labels. These labels contain routing information — such as the domain name (.ddev.site) and the internal container port (like 80 or 8080).

Here’s what happens under the hood when you visit https://<project-directory-name>.ddev.site:

Browser Request: Your browser sends a request to https://<project-directory-name>.ddev.site.
DNS Resolution: The *.ddev.site wildcard DNS resolves to 127.0.0.1, pointing to your local machine.
Traefik Intercepts: The request hits Traefik’s HTTPS listener (port 443). Traefik inspects the hostname .ddev.site and checks its internal routing table.
Container Discovery: Traefik, using Docker’s API, has already discovered that a container labeled Host(.ddev.site) exists. It knows this container’s internal IP and port.
Secure Routing: Traefik forwards the request securely to the correct container. It also handles SSL/TLS termination — meaning your site works seamlessly over HTTPS using Traefik’s automatically generated certificates.
Response: The container serves your app, and Traefik relays the response back to the browser.

So while it looks like you’re visiting a remote, hosted website at https://<project-directory-name>.ddev.site, you’re actually interacting with your own machine. Traefik quietly proxies everything behind the scenes — no hosts file edits, no manual configuration.

Diving into the details of how these local development environments handled routing was a great learning for me. In a future article we can try and implement similar kind of model with simple docker & docker compose and run our local sites with custom URL.

Please leave a comment below, if you've like this article or have any kind of queries or suggestions for me.

Setting up mailcow on mail server on an EC2 instance

Kaushik Mitra — Sun, 13 Apr 2025 09:55:31 +0000

Recently I've been exploring how we can create our own mail server with our own custom domains.

In my research I've come across a tool named mailcow.

So let's dive in to learn about mailcow, and how we can set it up in an AWS EC2 instance.

So what is `mailcow`?

From the official documentation, it is given that....

mailcow: dockerized is an open source groupware/email suite based on docker.

mailcow basically generates a docker-compose file for helping setup a mail server. It already comes with preconfigured components such as

acme - For creating Let's encrypt Certificates.
ClamAV - For scanning Anti-virus
Devcot - For IMAP/POP servers
MariaDB - For storing user information
SOGo - Integrated Webmailer
Memcached - Cache for the webmailer SOGo
Nginx - Web server for components of the stack
Olefy - Analysis of Office documents for viruses, macros, etc.
PHP - Programming language of most web-based mailcow applications
Postfix - MTA (Mail Transfer Agent) for e-mail traffic on the Internet
Redis - Storage for spam information, DKIM key, etc.
Rspamd - Spam filter with automatic learning of spam mails
Unbound - Integrated DNS server for verifying DNSSEC etc.
etc. etc.

How would we install mailcow then?

Installing & setting up a mailcow server is very easy, you would just need to basically run a docker-compose file for installation. Then everything can be done from the UI.

But, there are some prerequisites we need to follow....

Setting up an EC2 instance.

Our mail goal here would be to create an EC2 instance with sufficient RAM & necessary open ports on the server.

Note: For best experience it is recommended to use atleast 4GB RAM, that's why we are using t3.medium here.

For the creation of the instance I'm using terraform.

You can find the full source code from here.

First of all for our server we need a few necessary ports to be opened.
We can create a security group for this requirement like this...

resource "aws_security_group" "mailcow-security-group" {
  name        = "mailcow-sg"
  description = "Allow TLS inbound traffic"
  
  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    description = "SSH"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    description = "SSH"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 25
    to_port     = 25
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 465
    to_port     = 465
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 587
    to_port     = 587
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 143
    to_port     = 143
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 993
    to_port     = 993
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 110
    to_port     = 110
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 995
    to_port     = 995
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]

  }

  ingress {
    description = "SSH"
    from_port   = 4190
    to_port     = 4190
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "mailcow-sg"
  }
}

Now, we can create a EC2 instance with the Ubuntu image with the above security group, like this...

resource "aws_instance" "mailcow_server" {
  ami                    = "ami-0e35ddab05955cf57"
  instance_type          = "t3.medium"
  key_name               = aws_key_pair.deployer.key_name
  vpc_security_group_ids = [aws_security_group.mailcow-security-group.id]
  user_data = file("${path.module}/install-script.sh")
  tags = {
    Name = "mailcow-vm"
  }
}

During the creation of the EC2 instance we are including an install script for installing Docker & Docker compose.
Here is the script....

#!/bin/bash

echo "Starting Docker Install" >> "/home/ubuntu/install-logs"

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

echo "Completed Docker Install" >> "/home/ubuntu/install-logs"
echo "Manage Docker as a non-root user" >> "/home/ubuntu/install-logs"

sudo usermod -aG docker $USER
newgrp docker

Now, that we have setup the EC2 instance as needed, let's move on to our next requirements....

Setting up an DNS for the mail server

First of all we need a domain for this step, you can buy it from anywhere like namecheap or godady

I've bought my domain from namecheap, and added my domain to cloudflare for managing various DNS records.

For the basic mailserver we need atleast two DNS records - MX Record, A Record.

MX Record

A MX Record is basically used to point DNS servers where your domain is located.

Suppose someone trying to send a mail from a@gmail.com to your domain user@yoursite.com.

Now, the problem is how gmail would figure out where this user@yoursite.com is located. So gmail would the DNS server a MX record for yoursite.com.

We generally add a MX record for your domain to mail.yourdomain.com

For example, if you have a domain yousite.com

You would add a MX Record, like this

@ -> mail.yoursite.com

A Record

An A Record, is used to tell the DNS Servers where your site is.

Following the given example above, after adding the MX Record, you would need to add the A Record like this

mail.yourdomain.com -> IP Address

Now that we are done with the server configs, let dive in with the actual setup...

Installing Mailcow

Now that we have setup our server properly, for installing mailcow we need to just basically download the git repo of the mailcow and run the docker image...

Let's see, how can we do that...

Verify current user to have proper privilage

Before cloning the git repo, first we have to check if we have proper user privileges

Run this command

umask

The output of the above command should be 0022.

For EC2 instance, by default the output should not be as expected. We need to switch the user to root, for this to work.
You can do that by running

sudo su

Clone mailcow repo

Let's clone to the repo, into /opt directory and generate the configurations.

$ cd /opt
$ git clone git clone https://github.com/mailcow/mailcow-dockerized
$ cd mailcow-dockerized
$ ./generate_config.sh

Note: If you wan to change any of the configuration, you can edit the file mailcow.conf

Run the image

Now that we have setup all the things, let's run the docker compose in the background, and hope everything is working properly.

docker compose up -d

After the running the image, visit the domain you have setup with the A record. Like in our example we will open yourdomain.com

Now that you have installed mailcow, you manage various admin tasks from the UI.

Few links for managing mailcow

Admin portal can be accessed via /admin. The default username/password is admin/moohoo.

All Department portal can be accessed via /department. The default username/password is department/moohoo.

Using markdown to manage content to NextJS App Router

Kaushik Mitra — Tue, 26 Mar 2024 02:12:43 +0000

Recently I have been building my portfolio site using NextJs/TailwindCSS.
Here is the link to the site - Visit here
It's still a work in progress, here is the source code for the site.

In the site I have used markdown files to manage the Projects data on the site.

Today we will discuss how we can use the markdown files to generate contents for a NextJS site with Server Components and integrate with Typescript.

So let's dive in...

Why `next-mdx-remote`...

If we follow the official documentation there it is mentioned that how we can basically use .mdx to generate our JSX components which we can render on our site.

But following this way can be a bit difficult as it will be very difficult to manage dynamically generated content or if the markdown is coming from somewhere else like some CMS or some other place from the file system.

To solve this issue we can use a community package next-mdx-remote. This package actually compiles a given markdown string and generates HTML, so it will solve our problem of maintaining markdown if we want to scale in future and it is coming from some other database or something.

Integrating `next-mdx-remote` to React Server components in NextJS.

Installation

npm install next-mdx-remote

Basic Usage

As we are using react server components we can simply fetch the markdown data from a file and display it with the MDXRemote component.


// page.tsx

export default async function IndexPage() {

  const markdown_data = await getProject();

  if (markdown_data === "") {
    return notFound();
  }

  return (
    <>
     <MDXRemote source={markdown_data} />
    </>
  );

}

Advance Usage

We can setup our own custom components when generating the HTML form the Markdown files.

For this we can create our own component which will wrap the libraries MDXRemote component.

// mdx-remote.ts

import { MDXRemote, MDXRemoteProps } from "next-mdx-remote/rsc";

const components = {
  h1: (props: ComponentProps<"h1">) => <HeaderOne {...props}>{props.children}</HeaderOne>,
  h2: (props: ComponentProps<"h2">) => <HeaderTwo {...props}>{props.children}</HeaderTwo>,
  p: (props: ComponentProps<"p">) => <Paragragraph {...props}>{props.children}</Paragragraph>,
  img: (props: ComponentProps<"img">) => <MdxImage {...props} />,
  a: (props: ComponentProps<"a">) => <MdxLink {...props}>{props.children}</MdxLink>,
};

export function CustomMDX(props: MDXRemoteProps) {
  return (
    <MDXRemote
      {...props}
      components={{ ...components, ...(props.components || {}) }}
    />
  );
}

And these HeaderOne, HeaderTwo, etc can be simple components with our custom styles.

For example...

// HeaderOne.tsx

import { ComponentProps } from "react";

export function HeaderOne({ children, ...props }: ComponentProps<"h1">) {
  return (
    <h1 {...props} className="mb-6 mt-16 text-5xl">
      {children}
    </h1>
  );
}

// MDXImage.tsx

import Image from "next/image";
import { ComponentProps } from "react";

type MdxImageProps = ComponentProps<"img">;
export function MdxImage(props: MdxImageProps) {
  return (
    <div className="flex justify-center">
      <div className="border-4 border-primary">
        <Image
          {...props}
          src={props.src ?? ""}
          alt={props.alt ?? ""}
          width={500}
          height={300}
        />
      </div>
    </div>
  );
}

Now we have created our custom wrapper component for the MDXRemote we can use this in our server component.

// /projects/[title]/page.tsx

export default async function IndexPage({
  params,
}: {
  params: { title: string };
}) {

  const markdown_data = await getProjectWithTitle(params.title);

  if (markdown_data === "") {
    return notFound();
  }

  return (
    <>
     <MDXRemote source={markdown_data} />
    </>
  );

}

Now as we are using NextJS we can further more optise our site by staticly generating the page with generateStaticParams function

// /projects/[title]/page.tsx

...

export async function generateStaticParams() {
  return getProjectTitles();
}

The source code for the above can be found here

Conclusion

So, in conclusion we discussed how we can integrate this community package next-mdx-remote for managing content with markdown and also how we can use Typescript to add proper types and have proper type safe development.

If you have any discussions regarding the topic feel free to comment below.

Use bunx for running npm packages with lightning fast speed.

Kaushik Mitra — Mon, 11 Sep 2023 20:34:38 +0000

Introduction
Use Case for the package
Comparing with npx
Conclusion

Introduction

bun is the latest and greatest runtime for Javascript which ships with many features like built in Typescript support and testing support and etc. etc.. bunx, alias for bun x, is a package manger for bun which can be used for auto installing and running npm packages. We can you bunx just similarly like we use npx or yarn dlx.

According to this twitter post, bunx is 100x faster than npx, which means we can use bunx and run our npm cli with lightning fast speed.

Today we will discuss an use case of running a npm package with bunx and compare the result with running it with npx.

You can view the package from here, it is a simple package that I wrote which generates a random quote of Phil Dunphy from Mordern Family. You can also view a post that I have written with my learnings and take aways from creating this package.

Use case for the package

As the package phil-s-osophy just spits out basic string output we can pipe that to any program, like I have used to pipe the value in cowsay and added the whole thing at the bottom of my zshrc file to show text at every shell creation.

bunx phil-s-osophy | bunx cowsay

Comparing with npx

To compare my changes with the npx, I have created a function which will run the shell few times and time it.

timezsh() {
    for i in $(seq 1 10); do /usr/bin/time $SHELL -i -c exit; done
}

So after running both my program with bunx and npx I timed it to aroud 0.3 to 0.4s when running with bunx but when running with npx the program took around 2s to ran.

Note: there are many more things happening in my zshrc file, but I am ignoring this as they are running in bot scenarios.

Left running - bunx phil-s-osophy | bunx cowsay
Right running - npx phil-s-osophy | npx cowsay

Conclusion

So, in conclusion we have seen how bunx is so much faster than npx and how we can use this lightning fast speed to install and use packages for that great developer experience.

For more information about the bun, you can visit bun.sh.

Journey of creating and publishing a nodejs package with typescript & eslint support

Kaushik Mitra — Fri, 08 Sep 2023 22:26:38 +0000

Today we will discuss how I've written a npm package and published it to npmjs.

You can checkout the codebase from here

This is a simple package which just generates random quotes from Phil Dunphy, the lovable and hilarious character from the TV show Modern Family. I have chosen Phil Dunphy as I love Mordern Family and he is one of my favorite caracter from the show.

The target of this package was not to create something unique and useful for everyone (though if you are a fan of Phill Dunphy you may love this idea 😉), but it was to learn how we can use these technologies to build packages in a simple and efficient manner.

Technology Used

Typescript for writing the business logic and have used tsup for compiling to javascript files.
ESlint for linting the typescript code
Also have used Github Actions for linting the code whenever a new pull request is being created.

Setting up local environment for creating packages

For setting up a local environment, we can start like a basic node js project.

mkdir my_project
cd my_prject
npm init

After that we need to add the main entry point of our package as well as a bin file.

{
  "name": "phil-s-osophy",
  "version": "1.0.1",
  "description": "Phil Dunphy's amazing life lessons from Mordern Family.",
  "main": "./dist/index.js",
  "module": "./dist/index.mjs",
  "types": "./dist/index.d.ts",
  ...
  "bin": {
    "phil-o-osophy": "./dist/index.js"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/MitraKumar/phil-s-osophy.git"
  },
  "author": "MitraKumar",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/MitraKumar/phil-s-osophy/issues"
  },
  "homepage": "https://github.com/MitraKumar/phil-s-osophy#readme",
  ...
}

In my scenario since it I am compiling the javascript with tsup I've added the files in here.

And in the typescript file we need to add shebang in front of the file

#! /usr/bin/env node

After updating all this we can simply run npm install -g . from the project directory to use the package.

Project Setup with Typescript

The main business logic for the package is written in typescript and the logic is very simple, it's just accessing a random element from a list of quotes and printing it out. Again the project was not to create anything unique, it is just fun enough for me to learn these things.

For compiling typescript file I have used tsup as a dev dependency, which is very useful and intuitive for compiling to javascript files. To make this process seamless I've added a npm script to build the project.

For the configuration of tsup we need to create a tsup.config.ts file.

import { defineConfig } from 'tsup'

export default defineConfig({
  target: 'es2020',
  format: ['cjs', 'esm'],
  splitting: false,
  sourcemap: true,
  clean: true,
  dts: true
})

Then after adding this I added the build command in npm scripts and voila it all worked seamlessly.

{
  "name": "phil-s-osophy",
  ...
  "scripts": {
    ...
    "build": "tsup ./src"
  },
  ...
}

This is really helpful as we get the power of types and the seamless process of compiling to javascript files.

Linting with ESLint

Linting is must in a project, this is a small simple enough project but for a live project with many contributors linting is must otherwise without following a proper coding standard it will be difficult over time to maintain a project.

I have used ESlint for checking the linting of the project. Setting up ESLint is simple enough but we have to add few dependencies to help us out here...

in the package.json we need to add few of the dev dependencies such as

{
  ...
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^6.6.0",
    "@typescript-eslint/parser": "^6.6.0",
    "eslint": "^8.48.0",
    ...
  }
}

We can install this dependencies by running

npm install -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

After that we need to add a .eslintrc file, with some basic rulesets.

{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "plugins": [
    "@typescript-eslint"
  ],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "rules": {
    "@typescript-eslint/no-explicit-any": "error",
    "indent": ["error", 2],
    "linebreak-style": ["error", "unix"],
    "quotes": ["error", "double"],
    "semi": ["error", "always"]
  }
}

And all the configurations are done, now we can simply add a npm script eslint ./src --ext .ts to lint our files.

But this will cause an issue as ESLint will not trigger any typescript error, for that we can simply check it with tsc --noEmit ./src/index.ts. So for linting we can simply add a script like this tsc --noEmit ./src/index.ts; eslint ./src --ext .ts to run both of them sequentially.

Also we can add a script to fix the linting errors with ESlint.

{
  ...
  "scripts": {
    "lint": "tsc --noEmit ./src/index.ts; eslint ./src --ext .ts",
    "fix": "eslint ./src --ext .ts --fix",
    ...
  },
  ...
}

And voila, linting is also setup in our project.

Setting up Github Actions for checking coding standards

In a real world we probably cannot expect everyone to properly lint code and the Pushing it. So we need to setup a Github Action to generate a check for linting errors if any whenever a PR is being generated.

Setting up such action is pretty easy, we just need create a yml file in the directory .github/workflows like I've created a file .github/workflows/linter.yml

name: Code Checker

on:
  pull_request:
    branches:
      - main

jobs:
  linting:
    runs-on: ubuntu-latest
    name: Checking coding standards & type checking.
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Setup node environment
        uses: actions/setup-node@v3
        with:
          node-version: 'latest'
      - name: Install dependencies
        run: npm clean-install
      - name: Run linting & type checking
        run: npm run lint

This workflow file is mainly divided into three sections

name - Name of the workflow
Event - On which event the workflow will trigger, like in this scenario it will trigger on creating a Pull request against the branch main
Jobs - What jobs will run in this workflow.

Jobs also have several aspects to understand, the main thing being steps
Steps basically mentions what the a job will do in a sequential order, like here it is mentioned that the job will first checkout the repo, then setup node environment then install all dependencies and then run our lint script from above.

And that's it, now creating a PR will automatically run this jobs and will show a green check mark ✅

Conclusion

So in conclusion I will say, this was a fun simple enough project which helped me learn a lot of things. And if any of you have any idea of improving the project, even if it's a change in README file, you are more than welcome to submit a Pull Request and I will be happy to merge it.

mordern_navbar

Kaushik Mitra — Sun, 05 Jan 2020 00:01:24 +0000

my first post in this community, hope to get some love.

DEV Community: Kaushik Mitra

Creating a GKE Cluster and Deploying a Microservice Application (End-to-End)

Why GKE Autopilot?

Prerequisites

Step 1: Enable the Kubernetes Engine API

Step 2: Provision the GKE Autopilot Cluster

Step 3: Connect kubectl to Your GKE Cluster

Step 4: Important Autopilot Requirement — Resource Requests

Step 5: Install NGINX Ingress Controller on GKE using Helm

What happens on Google Cloud?

Step 6: Deploy the Calculator Microservices

Verify the Deployments

Step 7: Test Your Live Production Application!

1. Test Interactive Swagger UI Documentation:

2. Test Addition API:

3. Test Multiplication API:

3. Test Health Check:

Step 8: Clean Up Resources (Don't Skip This!)

Conclusion & Series Retrospective

Pushing Container Images to Google Cloud Artifact Registry (Step-by-Step)

Prerequisites

Step 1: Authenticate and Set Up Your GCP Project

Enable the Artifact Registry API

Step 2: Create a Docker Repository in Artifact Registry

Step 3: Configure Docker Authentication

Step 4: Understand the Artifact Registry Image Naming Structure

Step 5: Tag Your Local Images

Step 6: Push the Images to Artifact Registry

Step 7: Verify the Uploaded Images

Step 8: Update Your Kubernetes Manifests

Conclusion & Next Step

Installing NGINX Ingress Controller in Docker Desktop: A Step-by-Step Guide

Ingress Resource vs. Ingress Controller

Step 1: Install NGINX Ingress Controller using Helm

1. Add the Ingress-NGINX Helm Repository

2. Install the Helm Chart

What did Helm just create?

Step 2: Verify the Controller is Running

Step 3: Create the Ingress Rules (05-nginx-ingress-controller.yaml)

Breaking Down the Configuration

Step 4: Apply the Ingress and Test on Localhost

Testing the Endpoints!

1. Test Swagger UI Documentation (Root Route /):

2. Test Addition Service:

3. Test Multiplication Service:

4. Test Health Checks:

Troubleshooting Common Gotchas

Conclusion & Next Step

A Hands-On Guide with Microservices

The Application Architecture

1. add-service (add-service/index.js)

2. multiply-service (multiply-service/index.js)

3. docs-service (docs-service/index.js)

4. Dockerizing the Services

Diving into Kubernetes Concepts

Step 1: Isolating with Namespaces (00-namespace.yaml)

Step 2: What is a Pod? (01-add-service-pod.yaml)

Step 3: Why Do We Need Services?

The Secret Sauce: Labels and Selectors

Port vs Target Port

Step 4: Testing Internal Connectivity

Summary & What's Missing?

Setting up a Kubernetes Cluster Locally with Docker Desktop

Why Docker Desktop for Local Kubernetes?

Prerequisites

Step 1: Enable Kubernetes in Docker Desktop

Step 2: Verify kubectl and Cluster Connection

Checking Configured Contexts

Step 3: Inspect Your Local Node and Control Plane

Step 4: Test Driving the Cluster

Useful Tips for Docker Desktop Kubernetes

Conclusion & What's Next

Multi-Agent Interview Coach

What I Built

Cloud Run Embed

Your Agents

Profiler

Interviewer

Key Learnings

Magic behind DDEV & Lando Routing

Step 3: Connect `kubectl` to Your GKE Cluster

Step 3: Create the Ingress Rules (`05-nginx-ingress-controller.yaml`)

1. Test Swagger UI Documentation (Root Route `/`):

1. `add-service` (`add-service/index.js`)

2. `multiply-service` (`multiply-service/index.js`)

3. `docs-service` (`docs-service/index.js`)

Step 1: Isolating with Namespaces (`00-namespace.yaml`)

Step 2: What is a Pod? (`01-add-service-pod.yaml`)

Step 2: Verify `kubectl` and Cluster Connection

So what is `mailcow`?

Why `next-mdx-remote`...

Integrating `next-mdx-remote` to React Server components in NextJS.