Forem: Vakul Keshav

Building My Homelab: The Easiest Way to SSH Remotely

Vakul Keshav — Fri, 19 Sep 2025 10:19:59 +0000

When I first started building my homelab, one of the things I wanted was a way to access it from anywhere. The obvious choice that people talk about is port forwarding. But here’s the catch: I don’t even have a router, I rely on a mobile hotspot for internet. And mobile hotspots don’t give you a real public IP address, so there’s no way to forward ports.

Even if I did have a router, I quickly realized that port forwarding isn’t exactly the safest option. It literally opens up a port on your machine to the whole world, and that means anyone out there could try to knock on it. For a beginner like me, that sounded more like trouble than learning.

That’s when I came across Tailscale. What clicked for me is how simple it makes the whole thing no worrying about public IPs, no messing with routers, and no exposing ports. It just quietly sets up a secure, private connection between my devices, almost like magic. Suddenly, SSH into my homelab from anywhere went from “complicated and risky” to “easy and safe.”

In this blog i will tell how i setup ssh into my homelab using tailscale.

Tailscale setup for the windows laptop.

The first step is to create an account to the tailscale and download it on your windows laotop (this windows laptop is going to be the host through i will access my linux laptop), you can download the tailscale from this link.

When you connect to the tailscale it will open below window.

Click the connect button from the above image and in your admin panel, you will see there is a machine connected, like in below image and it requires approval as i have configured that i will manually approval for a machine to connect, the reason for this is because it provides me flexibility to configure the connection and configure the IP as i want. If you want to apply the manual approval setting then go to the settings -> device management -> enable manual approval.
Coming to the admin panel, click on the three dots and you will see the option to change the IP of the machine there and if you want to configure the IP, you can do it as below, if you want to read more about the IP address and the CGNAT that tailscale uses, you can refer this documentation.

So what i do is, i like to keep the last two octets of my tailnet similar to my machines private ipv4, you can verify both using the image below.

After updating the IP, you need to approve the connection, so approve by clicking on the three dots then approve.

Tailscale setup for the linux homelab

Go to the download page and download the tailscale for the linux, you can refer the above provided link to go to the download page or use the below script

curl -fsSL https://tailscale.com/install.sh | sh

sudo apt install tailscale

To connect the tailscale to your network use sudo tailscale up command and visit the login link that is provided to you.
If above command give error as tailscale.service not found that means you have to start the service and for that you can run sudo systemctl start tailscaled
when you login, it will again show the connect page, you have to connect to the same tailnet as that of your windows (use same email for signin).
In your console, you will see two machines now, you can modify the ip of your new machine and then approve it and you setup will look like below.

To verify if the linux machine is connected, you can do ip a and there will be an entry for the tailscale with ip that you just set.

Enabling ssh to homelab

In a terminal window on the homwlab, run the tailscale set command to advertise SSH for that VM:

sudo tailscale set --ssh

Open the Access Controls page of the Tailscale admin console and add the following lines to your tailnet policy file to allow network connectivity to the VM:

"grants": [
   {
      "src": ["yoursigninemail@gmail.com"],
      "dst": ["100.78.10.1"],
      "ip": ["22"]
   }
]

In the same tab, add the following rules to the SSH section of your tailnet policy file to allow SSH access to the VM:

"ssh": [
           { "action": "accept",
             "src": ["yoursigninemail@gmail.com"],
             "dst": ["autogroup:self"],
             "users": ["root","autogroup:nonroot", "<your-local-username>"]
           }
       ],

To see (in my case local-user) run the following command in the homelab terminal: whoami

Access HomeLab from the windows machine

Now you can access your homelab from you windows terminal using the following command: ssh local-user@100.64.65.66
I am accessing using the git bash in my windows and you can see the final results below.

Kubernetes Basics: A Beginner’s Guide to Container Orchestration

Vakul Keshav — Thu, 14 Aug 2025 14:21:33 +0000

Prerequisite

Docker or any Container service
Basic linux understanding with commands
Networking basics like: IP addresses, ports, protocols, DNS.
Version Control like GIT

Introduction

Modern applications don’t live on a single server anymore. They run across many environments that could be your laptop, cloud servers, or even multiple clouds. Containers make this possible by packaging apps with everything they need to run.
Problem: when you have hundreds or thousands of containers, how do you start them, keep them running, scale them, and make sure they can talk to each other?
That’s where Kubernetes (K8s) comes in. Think of it as an air traffic controller for containers as it decides where containers should run, monitors their health, and makes sure your applications are always available.

Why Kubernetes?

K8s solves real deployment problems that were headaches. They are below:
- Portability → Run anywhere: local, cloud, or hybrid.
- Self-healing → If a container crashes, Kubernetes restarts it automatically.
- Scalability → Automatically adds more containers when load increases.
- Observability → Built-in monitoring and logging tools
Before Kubernetes, deploying an app meant manually setting up servers, load balancers, and networking. Today, Kubernetes handles all that automatically.

Before vs After Kubernetes

Before:
Imagine you had to deploy an app on three servers. You’d SSH into each, start the app, set up load balancing, and hope nothing crashed. If a server went down, you’d have to fix it manually. So much to do.

After:
You tell Kubernetes how many copies of your app you want, and it does the rest from scheduling pods to handling traffic, and even replacing failed instances automatically.

Kubernetes Architecture

Kubernetes Cluster

In the last part we discussed that before k8 we have to manually setup everything across all the machines. But after k8 those machines comes under k8 and form a group called kubernetes cluster.
These machines, whether physical or virtual, are called nodes.
Kubernetes manages them as one unified system, so you don’t have to think about each server individually.

It has two main parts:

Control Plane: The brain of Kubernetes.
Worker Nodes: The hands that do the actual work of running your applications.

Control Plane (The Brain)

The control plane makes global decisions about the cluster like scheduling, scaling, and responding to failures. Below are the key components of the control plane:
- API Server: Acts as the interface for managing the cluster and communicate with all components.
- Scheduler: Decides which node should run each workload.
- Controller Manager: Handles background tasks such as maintaining node health, scaling and other cluster-wide operations.
- etcd: A key-value store that stores all cluster data, including configuration and state.

Worker Nodes (The Hands)

Worker nodes are where your applications actually run.
Each worker node has:
- kubectl: Communicates with the control plane and ensures that the containers for a pod are running on that node.
- Container Runtime: The engine that runs containers (e.g., containerd, CRI-O). Yes docker is not here.
- kube-proxy: Manages networking rules for communication between pods and services.
If the control plane is the brain, worker nodes are the muscle that executes its instructions.

Pods: The Smallest Deployable Unit

Kubernetes does not run containers directly, it runs pods. A pod is:
- A wrapper around one or more containers. (like in the image)
- Shared environment: network namespace, storage volumes.
- Temporary: If a pod fails, Kubernetes can replace it automatically.

Example:

A pod might have your main application running and there is also another container (very specific use cases) for logging.

kubectl: Kubernetes Command-Line Tool

kubectl is the primary way to interact with a Kubernetes cluster.
It talks to the API Server to create, inspect, and manage resources.

Example:

# See all nodes in your cluster
kubectl get nodes

# Create a pod running Nginx
kubectl run nginx --image=nginx

# See all pods
kubectl get pods

So Whats happening when you run kubectl run nginx --image=nginx:
- kubectl sends the request to the API Server.
- The Scheduler chooses a worker node to run the pod.
- The kubelet on that node pulls the image (nginx) and starts the container.
- The pod runs until it’s stopped, deleted, or replaced.

Installing Kubernetes

For now i am personally using docker desktop to start kubernetes which spins up a single node kubernetes cluster.
- Open docker desktop and go to settings and there you will see kubernetes option, click it.
- Check the "Enable Kubernetes" option and you are good to go.
This is a great way to start practicing k8s.
You can also use minikube which is a single-node kubernetes cluster and great for learning.
- Refer this for installing minikube on windows, linux and mac.

Building Scalable CI/CD Pipelines with Azure DevOps, Docker, and Private NPM Packages

Vakul Keshav — Wed, 06 Aug 2025 16:07:12 +0000

Over the past few days, I designed and implemented a robust CI/CD pipeline from scratch, tackling the challenges of:

Integrating Docker builds with private NPM registries (Azure Artifacts)
Managing secure, token-based authentication inside Docker containers
Automating deployments for a seamless developer experience

One key challenge was handling private NPM package authentication during Docker builds without exposing sensitive tokens. After multiple iterations, I designed a scalable approach using Azure DevOps Pipelines, Azure Key Vault for secrets management, and dynamically injecting .npmrc during runtime (I will show this later).

For private npm registry i am using azure artifacts, and if you want to know how to integrate azure artifacts as npm registry then you can refer this official documentation and if you want to know how to publish your first package to azure artifacts then you can refer this.

Dockerfile for securely integrating private npm packages

When working with private NPM registries (like Azure Artifacts), integrating authentication into Docker builds can be tricky. A naive approach of passing tokens through ARG or ENV leads to token leakage in image layers, posing a significant security risk. Here's how I tackled this problem by dynamically generating the .npmrc during build-time without exposing sensitive information in the final image. If you want to know how to generate pat token in azure devops then you can refer this

# Stage 1: Build Stage
FROM node:22-alpine AS builder

WORKDIR /app
ARG NPM_AUTH_TOKEN

# Dynamically create .npmrc to authenticate with private NPM registry
RUN echo "registry=https://pkgs.dev.azure.com/{organization-name}/{project-name}/_packaging/{feed-name}/npm/registry/" > .npmrc && \
    echo "always-auth=true" >> .npmrc && \
    echo "//pkgs.dev.azure.com/{organization-name}/{project-name}/_packaging/{feed-name}/npm/registry/:username={organization-name}" >> .npmrc && \
    echo "//pkgs.dev.azure.com/{organization-name}/{project-name}/_packaging/{feed-name}/npm/registry/:_password=${NPM_AUTH_TOKEN}" >> .npmrc && \
    echo "//pkgs.dev.azure.com/{organization-name}/{project-name}/_packaging/{feed-name}/npm/registry/:email=npm requires email to be set but doesn't use the value" >> .npmrc

# Copy package files
COPY package.json ./

# Install dependencies
RUN npm install

# Copy application source code
COPY . .

# Generate Prisma Client
RUN npx prisma generate

# Clean up sensitive files
RUN rm -rf .npmrc

# Stage 2: Runtime Stage
FROM node:22-alpine

WORKDIR /app

# Copy built application from builder stage
COPY --from=builder /app /app

EXPOSE 3000

CMD ["node", "src/app.js"]

Explanation:

When working with private NPM registries like Azure Artifacts, one common challenge is authenticating the Docker build process without leaking sensitive tokens into the final image. To solve this, I passed the NPM Auth Token as a build argument and generated an .npmrc file on-the-fly during the build stage, I also tried creating a .npmrc.docker file to keep the docker code clean and copy it but for some reason it was not taking the token, so i went with the current approach. After installing the dependencies, I made sure to delete the .npmrc file, ensuring that no secrets get persisted into the final runtime image.
To keep the image clean and secure, I used a multi-stage Docker build the first stage builds the app and installs dependencies, while the second stage only copies the necessary build artifacts. This approach ensures that devDependencies, build caches, and sensitive files never reach production, keeping the image lightweight and secure.

Automating Docker Builds & VM Deployments with Azure DevOps Pipelines (CI/CD Workflow)

After containerizing the application securely, the next step was to automate the entire build → push → deploy workflow using Azure DevOps Pipelines. The CI/CD pipeline I designed builds the Docker image, pushes it to Azure Container Registry (ACR), and then deploys it to an Azure Virtual Machine which also acts like self hosted agent for CD part (discussed it later).
One tricky part was handling environment variables securely during deployment. Instead of hardcoding them, I dynamically created a .env file on the VM during the deployment stage. The pipeline also ensures zero downtime deployments by stopping old containers, cleaning up stale files, pulling the latest image, and running it with updated configurations.
I'll talk about each step in a little bit

trigger:
- none

pool:
  vmImage: ubuntu-latest

variables:
- group: Backend-Auth-Variables  # Azure DevOps Variable Group for secrets

stages:
# Build Stage
- stage: Build
  displayName: Build and Push Docker Image
  jobs:
  - job: BuildAndPushImage
    displayName: Build and Push Docker Image
    steps:
    - task: Bash@3
      inputs:
        targetType: 'inline'
        script: | 
          echo "NPM_AUTH_TOKEN starts with: $(NPM-AUTH-TOKEN:0:4)..."
          docker build --build-arg NPM_AUTH_TOKEN=$(NPM-AUTH-TOKEN) -t <your-acr-name>.azurecr.io/backend-auth:$(Build.BuildId) .

    - task: Docker@2
      inputs:
        containerRegistry: 'ACR-Service-Connection'  # Azure DevOps Service Connection to ACR
        repository: 'backend-auth'
        command: 'push'

# Deploy Stage
- stage: Deploy
  displayName: Deploy to Azure VM
  dependsOn: Build
  jobs:
  - deployment: DeployApp
    displayName: SSH into VM and Deploy Container
    environment: 
      name: Azure_VM_Environment
      resourceName: backend-vm
    strategy:
      runOnce:
        deploy:
          steps:
          - task: Bash@3
            inputs:
              targetType: 'inline'
              script: |
                  #!/bin/bash
                  TARGET_DIR="$HOME/$(Build.Repository.Name)"

                  ENV_FILE_CONTENT="
                    DATABASE_URL=$(DATABASE-URL)
                    API_KEY_SERVICE_1=$(API-KEY-SERVICE-1)
                    API_KEY_SERVICE_2=$(API-KEY-SERVICE-2)
                    JWT_SECRET=$(JWT-SECRET)
                    EMAIL_USER=$(EMAIL-USER)
                    EMAIL_PASS=$(EMAIL-PASS)
                    OAUTH_CLIENT_ID=$(OAUTH-CLIENT-ID)
                    OAUTH_CLIENT_SECRET=$(OAUTH-CLIENT-SECRET)
                    FRONTEND_URL=http://localhost:3001
                    REDIS_PASSWORD=$(REDIS-PASSWORD)
                    REDIS_HOST=$(REDIS-HOST)
                    REDIS_USERNAME=$(REDIS-USERNAME)
                    REDIS_PORT=$(REDIS-PORT)"

                  DOCKER_IMAGE_NAME="<your-acr-name>.azurecr.io/backend-auth:$(Build.BuildId)"
                  CONTAINER_NAME="backend-auth-container"

                  if [ -d "$TARGET_DIR" ]; then
                      echo "Directory exists. Clearing files..."
                      rm -rf "$TARGET_DIR"/*
                  else
                      echo "Directory does not exist. Creating it..."
                      mkdir -p "$TARGET_DIR"
                  fi

                  echo "Creating .env file..."
                  echo "$ENV_FILE_CONTENT" > "$TARGET_DIR/.env"

                  if [ "$(docker ps -aq -f name=$CONTAINER_NAME)" ]; then
                    echo "Stopping and removing old container..."
                    docker rm -f $CONTAINER_NAME
                  else
                    echo "No old container found."
                  fi

                  echo "Pulling Image from ACR..."
                  docker pull $DOCKER_IMAGE_NAME

                  echo "Running new container..."
                  cd $TARGET_DIR
                  docker run -itd --name $CONTAINER_NAME --env-file .env -p 3000:3000 $DOCKER_IMAGE_NAME

Explanation:

Service Connections: Secure Access to ACR & Azure VM
- I created a Docker Registry Service Connection in Azure DevOps to authenticate and push images to Azure Container Registry (ACR).
- For deployment, I utilized a self-hosted agent running directly on the Azure Virtual Machine, which eliminated the need for any SSH-based service connections or additional setup complexities. The deploy stage in the pipeline simply executes Bash scripts on the same VM post-build, allowing for seamless container deployment and environment configuration without remote access overhead.
- You can refer this for setting up self-hosted agent and docker service connection.

Pipeline Execution Flow:

Build & Push Stage
- A Microsoft-hosted Ubuntu agent performs the Docker build.
- The NPM token (NPM_AUTH_TOKEN) is passed securely as a build argument to handle private package installations.
- The built Docker image is tagged with the current Build ID and pushed to Azure Container Registry (ACR) using a Docker Service Connection.
- I have used two tasks : Bash@3 for custom Docker build steps and Docker@2 for pushing the image to ACR.

Deploy Stage: VM-based Self-Hosted Deployment
- This stage connects to a self-hosted agent (Azure VM) configured as an Azure DevOps Environment Resource.
- It performs the following actions in sequence:
  - Creates a .env file dynamically on the VM with all sensitive configurations using Azure DevOps variables.
  - Stops and removes any existing containers.
  - Pulls the latest image from ACR.
  - Runs the new container with the updated .env configuration.