DEV Community: David Cletus

Dockerizing a Node App & Shipping It to Azure: Build, Break, Fix & Ship (3 Errors, Zero Regrets) 🐳

David Cletus — Sat, 26 Sep 2026 00:33:05 +0000

I wanted a hands-on project to actually cement what I'd been learning in Docker and Azure, build something small, break it, fix it, and ship it for real. So I built Container Vibes: a tiny Express app that hands you a random "vibe" (a color theme + a little quote) every time you click a button. It's deliberately simple. The point was never the app it was everything around it: containerizing it properly, pushing it to a registry, and getting it running live on Azure Container Instances (ACI).

This post walks through the entire build, step by step, in the exact order I actually did it including the three errors I ran into along the way and exactly how I diagnosed and fixed each one.

What we're building

A small Node.js/Express app with three routes: a homepage, a /health check, and a /api/vibe endpoint that returns a random theme
A Docker image for it, tested locally
The image pushed up to Docker Hub as the deployable artifact
The container running live on Azure Container Instances, reachable at a real URL
The source code version-controlled and pushed to GitHub

Step 1 — Laying the groundwork

First thing, I set up a clean folder structure so everything had a home:

mkdir docker-project-1 && cd docker-project-1
code .

That opens the empty folder straight into VS Code. From there:

mkdir hagital && cd hagital
npm init -y
touch Dockerfile

npm init -y scaffolds a package.json with all the defaults accepted automatically no need to answer the usual prompts one by one. This file is what tells both Node and, later, Docker's npm install step exactly which dependencies the project needs, so getting it created early matters. I also touched an empty Dockerfile right away, just as a placeholder for what was coming.

Then the actual app files:

touch server.js .dockerignore

Step 2 — Writing the app

server.js is where all the actual logic lives. It's a small Express server holding a roster of "vibes" each one a name, a pair of gradient colors, and a short quote plus two routes: one that picks a vibe at random, and a health check.

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

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

// A little roster of "container vibes" — color themes + quotes
const VIBES = [
  { name: 'Sunset Deploy', colors: ['#FF6B6B', '#FFD93D'], quote: 'Life is good and could be challenging — ship it anyway.' },
  { name: 'Ocean Rollout', colors: ['#4ECDC4', '#556270'], quote: 'Every container has a bad day. Restart policy: always.' },
  { name: 'Neon Nightshift', colors: ['#8E2DE2', '#4A00E0'], quote: "Logs don't lie. Neither do good tests." },
  { name: 'Forest Uptime', colors: ['#11998e', '#38ef7d'], quote: 'Healthy pods, happy engineers.' },
  { name: 'Candy CI/CD', colors: ['#f857a6', '#ff5858'], quote: 'Green pipeline, good vibes.' },
  { name: 'Golden Hour Git', colors: ['#f7971e', '#ffd200'], quote: 'Commit small, dream big.' },
  { name: 'Cosmic Cluster', colors: ['#0f0c29', '#302b63', '#24243e'], quote: 'Somewhere out there, a pod is scaling for you.' },
];

app.use(express.static(path.join(__dirname, 'public')));
app.use(express.json());

app.get('/api/vibe', (req, res) => {
  const vibe = VIBES[Math.floor(Math.random() * VIBES.length)];
  res.json({
    ...vibe,
    timestamp: new Date().toISOString(),
    uptime: Math.floor(process.uptime()),
  });
});

app.get('/health', (req, res) => {
  res.json({ status: 'ok', message: 'Life is good and could be challenging. But we are up.' });
});

app.listen(PORT, () => {
  console.log(`✨ Server running on port ${PORT} — go visit http://localhost:${PORT}`);
});

A few things worth pointing out: express.static serves everything in the public folder (that's how the HTML page gets delivered), /api/vibe picks a random entry from the VIBES array and tacks on a live timestamp and the server's uptime so every response feels fresh, and /health exists purely as a lightweight endpoint to confirm the server is alive which turned out to be genuinely useful later when checking on the container from Azure's side.

Step 3 — Building the frontend

mkdir public && cd public
touch index.html
cd ..

public/index.html is a single self-contained page: a gradient background that slowly animates through the current vibe's colors, a frosted-glass "card" in the center holding the vibe's name and quote, a small uptime readout, and a "New Vibe" button. Clicking that button calls /api/vibe, gets back a fresh random theme as JSON, and updates the card's colors and text on the page without a reload.

Step 4 — Writing the Dockerfile

# pull the official Node.js image from the Docker Hub
FROM node:20-alpine

# set the working directory in the container
WORKDIR /app

# copy package.json and package-lock.json to the working directory
COPY package*.json ./

# install dependencies
RUN npm install

# copy the rest of the application code to the working directory
COPY . .

# expose the port that the application will run on
EXPOSE 3000

# define the command to run the application
CMD [ "node", "server.js" ]

Walking through it line by line: FROM node:20-alpine grabs a minimal, lightweight Node 20 base image (the Alpine variant strips out everything not strictly needed, keeping the image small). WORKDIR /app sets where all the following commands run inside the container. COPY package*.json ./ copies over just package.json and package-lock.json first — deliberately, before the rest of the code so that RUN npm install becomes its own cached layer. That means if I only change server.js later and rebuild, Docker can reuse the already-installed node_modules layer instead of reinstalling everything from scratch every single time. COPY . . then brings in the rest of the app. EXPOSE 3000 documents which port the app listens on. And CMD [ "node", "server.js" ] is what actually runs when a container starts from this image.

Step 5 — First build, first surprise

With the Dockerfile in place, I moved back up to the project root and kicked off the build:

cd ..
docker build -t 4thman/hagital:v1 .

It built clean — all 11 steps finished, image tagged as 4thman/hagital:v1.

Feeling good, I ran it and checked the images list first:

docker images
docker run -d -p 3000:3000 --name hagital-app 4thman/hagital:v1

Then opened localhost:3000 in the browser, fully expecting my little vibes card to show up. Instead: "This site can't be reached localhost refused to connect."

Debugging: the case of the missing module

A clean docker build doesn't guarantee a working app that's the lesson this error taught me. First move was checking whether the container was even still alive:

docker ps -a

It showed status Exited (1), meaning the container had started and then immediately crashed. Time to check why:

docker logs hagital-app

Error: Cannot find module 'express'

And there it was. I had written require('express') in server.js, but I had never actually run npm install express on my own machine so package.json had zero dependencies listed. When the Dockerfile's RUN npm install step ran during the build, there was simply nothing in package.json for it to install. The image built successfully because Docker didn't know anything was missing it only found out at runtime, the moment Node tried to require() a package that was never there.

The fix:

npm install express

That updates package.json and package-lock.json with the real dependency. Then it was just a matter of rebuilding the image (this time you could see only the WORKDIR layer got reused from cache everything from COPY package*.json onward had to rerun, since the package files had actually changed) and swapping the container:

docker build -t 4thman/hagital:v1 .
docker rm hagital-app
docker run -d -p 3000:3000 --name hagital-app 4thman/hagital:v1

Success — locally, at last

Refreshed the browser and there it was: Container Vibes, running from inside a container, gradient background and all.

I went through all three routes to be thorough the homepage, the health check, and the vibe API directly:

(homepage) ·

(/health returning {"status":"ok",...}) ·

(/api/vibe returning a random theme as JSON)*

Quick concept check: EXPOSE vs -p vs --dns-name-label

These three get mixed up a lot, but they each solve a different problem. EXPOSE in the Dockerfile is really just documentation it tells anyone reading the image which port the app inside expects traffic on, but it doesn't actually open anything to the outside world by itself; that's exactly why the app could build fine and still be unreachable. The -p flag on docker run is the one doing the real work locally: it's the bridge that maps a port on your own machine to a port inside the container (-p 3000:3000 means "traffic hitting port 3000 on my laptop gets forwarded into the container's port 3000"), and without it your app can be running perfectly inside the container and you'd still get "connection refused" on the host. --dns-name-label, which comes in later once we're on Azure, is a different beast entirely since Azure Container Instances hands your container a public IP that's a pain to remember and isn't guaranteed to stay the same, this flag lets you attach a friendly, stable subdomain to it instead (like david-hagital.eastus.azurecontainer.io), so you're never hunting down a raw IP address to share a link.

Step 6 — Cleaning up locally

Before moving on, I ran through the basic container lifecycle commands just to get comfortable with them checking status, reading logs, stopping, and removing:

docker ps
docker logs hagital-app
docker stop hagital-app
docker rm hagital-app
docker ps

That last docker ps came back empty, confirming the container was fully gone.

Step 7 — Logging into Docker Hub

Next was getting the image somewhere Azure could actually reach it. Logged in, and while I was at it, ran git init on the project too (even though I wouldn't actually commit anything until much later) and double-checked my .dockerignore set to keep .git and .env out of the build context entirely, so neither ever ends up baked into the image.

docker login
git init

.dockerignore
.git
.env

Step 8 — Pushing to Docker Hub

docker push 4thman/hagital:v1

Watched each layer push up one by one until it finished with a digest and total size the image was now sitting on Docker Hub, ready to be pulled from anywhere, including Azure.

Step 9 — Logging into Azure

az login

This opens a browser sign-in flow and, once authenticated, lists the subscriptions tied to the account so you can confirm which one the CLI is about to operate on.

Step 10 — Creating the resource group (and hitting error #1)

az group create --name david-docker-rg --location eastus

That part succeeded instantly — a resource group is just a logical folder in Azure to keep everything for this project together. Then I tried to actually create the container:

az container create \
  --resource-group david-docker-rg \
  --name david-app-container \
  --image 4thman/hagital:v1 \
  --port 3000 \
  --dns-name-label david-hagital \
  --cpu 1 \
  --memory 1

And hit the first Azure error:

(MissingSubscriptionRegistration) The subscription is not registered to use namespace 'Microsoft.ContainerInstance'

Fixing error #1: the provider that wasn't switched on

Every Azure subscription has to explicitly "register" the individual resource providers it wants to use before you're allowed to create resources of that type. Mine had simply never touched Container Instances before, so the Microsoft.ContainerInstance namespace wasn't switched on yet. The fix:

az provider register --namespace Microsoft.ContainerInstance
az provider show -n Microsoft.ContainerInstance --query "registrationState"

I ran that last command a couple of times, watching the state move from "Registering" to "Registered" before trying again.

Error #2: pick an OS, any OS

With the provider registered, I ran the exact same az container create command again and hit a second, different error:

(InvalidOsType) The 'osType' for container group '<null>' is invalid. The value must be one of 'Windows,Linux'.

It turns out az container create doesn't assume an operating system for you, you have to say so explicitly, every time. Adding --os-type Linux to the command fixed it immediately.

az container create \
  --resource-group david-docker-rg \
  --name david-app-container \
  --image 4thman/hagital:v1 \
  --port 3000 \
  --dns-name-label david-hagital \
  --os-type Linux \
  --cpu 1 \
  --memory 1

It worked — container created

This time the command ran all the way through, returning the full container group JSON with "provisioningState": "Succeeded".

Step 11 — Grabbing the live URL

az container show \
  --resource-group david-docker-rg \
  --name david-app-container \
  --query ipAddress.fqdn \
  --output tsv

That returned david-hagital.eastus.azurecontainer.io — the friendly subdomain the --dns-name-label flag from earlier had reserved.

It's alive on the internet 🎉

Visited david-hagital.eastus.azurecontainer.io:3000 in the browser, and there it was Container Vibes, live, running the Forest Uptime theme.

Clicked "New Vibe" a few times to make sure the randomization actually worked over a real network call, not just locally and it did, cycling through themes like Golden Hour Git exactly as expected.

Step 12 — Checking logs straight from Azure

az container logs \
  --resource-group david-docker-rg \
  --name david-app-container

This pulled back the exact same startup message the app prints locally, confirming the container had booted cleanly on Azure's side too.

Step 13 — Tearing it down

Azure Container Instances bills for the time a container is actually running, so once I'd confirmed everything worked, I cleaned up:

az container delete \
  --resource-group david-docker-rg \
  --name david-app-container \
  --yes

az group delete \
  --name david-docker-rg \
  --yes \
  --no-wait

--no-wait just means the CLI hands control back to me immediately instead of sitting there until Azure finishes deleting everything in the background.

Step 14 — Finally, version control

With the app built, tested, containerized, pushed to Docker Hub, and successfully deployed and torn down on Azure, I went back and properly set up Git since none of the actual deployment steps above needed GitHub at all (Azure was pulling the image straight from Docker Hub), but I still wanted the source code backed up and version-controlled.

Added a proper .gitignore to keep node_modules and .env out of the repo, then checked status and staged everything:

touch .gitignore
git status
git add .

git commit -m "Hagital Docker App"

Seven files went into that first commit: the .dockerignore, .gitignore, Dockerfile, package.json, package-lock.json, public/index.html, and server.js.

Created a new private repository on GitHub named Hagital-Docker-App, with a short description.

Then connected the local repo to it and pushed:

git branch main
git switch main
git remote add origin https://github.com/4thman/Hagital-Docker-App.git

git push -u origin main

And confirmed everything landed correctly by checking the repo on GitHub, all seven files present, matching exactly what was committed locally.

What I'd tell past-me

None of the three errors here were Docker or Azure being difficult — they were small gaps in my own checklist. Forgetting to run npm install before building meant a "successful" build that shipped a broken app, and the fix was realizing that a clean build log means nothing if the container crashes the moment it actually starts. Forgetting that a fresh Azure subscription needs its resource providers registered cost me a re-run, and forgetting to specify an OS type cost me another. None of it was complicated once I actually read the error message properly — which, honestly, is most of DevOps in a nutshell: read the log, trust what it's telling you, fix that one specific thing, and try again.

I Built a One-Click Azure CI/CD Pipeline with Terraform & GitHub Actions From git push to a Live Website

David Cletus — Sun, 20 Sep 2026 01:33:32 +0000

A few weeks ago I built an Azure VM with Terraform from my laptop. It worked, but I still had to SSH in, install nginx and copy my website over by hand.

This time I wanted all of that to happen on its own. I run git push from Git Bash, and a live website shows up on a brand new VM. The website is a copy of a public GitHub project called Omnifood, and the workflow clones it onto the server for me. No portal clicking, no SSH from me.

It took me a few hours and a lot of red error messages. In this post I'll show you what worked, what broke, and how I destroyed everything at the end so Azure doesn't charge me for a VM I forgot about.

(The name "Hagital" comes from my school, Hagital Tech Institute. Use your own names when you follow along.)

What we're building

git push from my laptop
   -> GitHub Actions wakes up
   -> Terraform builds the VM on Azure
   -> GitHub logs into the VM over SSH
   -> nginx is installed, then the website is cloned from GitHub over nginx's default page
   -> You open the IP address and see a live site

And there's a second path for cleanup: click Run workflow, and a destroy job deletes everything.

Words I'll use

Terraform: a tool where you describe your cloud stuff in files, and it builds it for you.
State file: Terraform's notebook of what it has built so far.
Service principal: a robot account. GitHub uses it to log into Azure.
Secret: a hidden value in GitHub (passwords, keys) that your workflow can use but nobody can read.
Workflow: a YAML file that tells GitHub Actions what to run and when.

What you need

An Azure account and the Azure CLI
Terraform installed
VS Code and Git Bash (I'm on Windows)
A GitHub account
An SSH key pair

My GitHub repo

Part 1: Build the Terraform files on my laptop

Make a folder and open it

mkdir Hagital-Project1
cd Hagital-Project1
code .

Then I made an empty main.tf:

touch main.tf

Give Terraform a safe place for its notebook

If the state file sits on my laptop, GitHub's computer can't see it. Then it wouldn't know what already exists and couldn't delete it later. So the state lives in an Azure storage account. I made three things with the CLI:

az group create \
  --name terraform-state-rg \
  --location eastus

az storage account create \
  --name hagitaldavid2026 \
  --resource-group terraform-state-rg \
  --sku Standard_LRS

az storage container create \
  --name tfstate \
  --account-name hagitaldavid2026 \
  --auth-mode login

Storage account names must be unique across all of Azure, so yours can't be hagitaldavid2026. When you see "created": true, you're good.

Provider and backend

This goes at the top of main.tf. The backend block tells Terraform where the notebook lives.

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 5.4.0"
    }
  }
}

provider "azurerm" {
  features {}
  subscription_id = "YOUR-SUBSCRIPTION-ID"
}

terraform {
  backend "azurerm" {
    resource_group_name  = "terraform-state-rg"
    storage_account_name = "hagitaldavid2026"
    container_name       = "tfstate"
    key                  = "terraform-project.tfstate"
  }
}

The actual resources

Resource group, network, subnet and public IP:

resource "azurerm_resource_group" "hagital_rg" {
  name     = "hagital-rg"
  location = "East US"
}

resource "azurerm_virtual_network" "hagital_vnet" {
  name                = "hagital-vnet"
  resource_group_name = azurerm_resource_group.hagital_rg.name
  location            = azurerm_resource_group.hagital_rg.location
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "hagital_subnet" {
  name                 = "hagital-subnet"
  resource_group_name  = azurerm_resource_group.hagital_rg.name
  virtual_network_name = azurerm_virtual_network.hagital_vnet.name
  address_prefixes     = ["10.0.0.0/24"]
}

resource "azurerm_public_ip" "hagital_ip" {
  name                = "hagital-ip"
  resource_group_name = azurerm_resource_group.hagital_rg.name
  location            = azurerm_resource_group.hagital_rg.location
  allocation_method   = "Static"
  sku                 = "Standard"
}

Network security group. Think of it as a door guard. I opened port 22 for SSH and port 80 for the website:

resource "azurerm_network_security_group" "hagital_nsg" {
  name                = "hagital-nsg"
  resource_group_name = azurerm_resource_group.hagital_rg.name
  location            = azurerm_resource_group.hagital_rg.location

  security_rule {
    name                       = "Allow-SSH"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "22"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }

  security_rule {
    name                       = "Allow-HTTP"
    priority                   = 101
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }
}

Network card, tied to the NSG:

resource "azurerm_network_interface" "hagital_nic" {
  name                = "hagital-nic"
  resource_group_name = azurerm_resource_group.hagital_rg.name
  location            = azurerm_resource_group.hagital_rg.location

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.hagital_subnet.id
    private_ip_address_allocation = "Dynamic"
    public_ip_address_id          = azurerm_public_ip.hagital_ip.id
  }
}

resource "azurerm_network_interface_security_group_association" "hagital_nic_nsg" {
  network_interface_id      = azurerm_network_interface.hagital_nic.id
  network_security_group_id = azurerm_network_security_group.hagital_nsg.id
}

The Linux VM (Ubuntu 22.04, small and cheap):

resource "azurerm_linux_virtual_machine" "hagital_vm" {
  name                = "hagital-vm"
  resource_group_name = azurerm_resource_group.hagital_rg.name
  location            = azurerm_resource_group.hagital_rg.location
  size                = "Standard_B1s"
  admin_username      = "adminuser"
  network_interface_ids = [
    azurerm_network_interface.hagital_nic.id,
  ]

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-LTS"
    version   = "latest"
  }

  admin_ssh_key {
    username   = "adminuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }
}

Look at that last line, file("~/.ssh/id_rsa.pub"). It reads the key from a path on my laptop. Remember it, because it causes trouble later.

Init and plan

terraform init
terraform plan

init set up the Azure backend and downloaded the provider. It also created a .terraform folder and a .terraform.lock.hcl file. The plan said 8 to add, 0 to change, 0 to destroy.

Variables and outputs

Hard-coded names are fine for a first try, but I wanted them in a variables.tf file:

touch variables.tf

Every value got its own variable block, like this:

variable "resource_group_name" {
  description = "hagital-rg"
  type        = string
  default     = "hagital-rg"
}

I did the same for location, network name, subnet name, public IP name, NSG name, NIC name and VM name. Two variables have no default on purpose, so they must be given a value when Terraform runs:

variable "subscription_id" {
  description = "Azure subscription ID"
  type        = string
}

variable "public_key" {
  description = "admin user ssh public key"
  type        = string
}

Then I changed main.tf to use them, for example subscription_id = var.subscription_id and name = var.resource_group_name.

Next, outputs.tf. It prints the VM's public IP and username after the build:

touch outputs.tf

output "hagital_vm_public_ip" {
  description = "Public IP address of the Hagital virtual machine"
  value       = azurerm_public_ip.hagital_ip.ip_address
}

output "hagital_vm_username" {
  description = "Username of the Hagital virtual machine"
  value       = azurerm_linux_virtual_machine.hagital_vm.admin_username
}

I ran terraform fmt to tidy the files. It listed the two files it fixed.

Then I ran terraform plan again. Because subscription_id and public_key have no defaults, Terraform stopped and asked me to type them in.

I typed the subscription ID and got another clean plan: 8 to add, plus my two outputs.

Keep that typing prompt in mind. It comes back later.

Part 2: Let GitHub talk to Azure

GitHub's computer needs permission to build things in my Azure account. I made a service principal (the robot account) with the Contributor role:

az ad sp create-for-rbac `
  --name "hagital-cicd" `
  --role contributor `
  --scopes /subscriptions/YOUR-SUBSCRIPTION-ID `
  --sdk-auth

It printed a JSON block with the login details. Azure warned me that --sdk-auth is deprecated. It still worked for me.

Then I made a private repo on GitHub with a README:

Adding the secrets

In the repo I went to Settings > Secrets and variables > Actions > New repository secret and added four secrets:

Secret name	What I pasted in
`HAGITAL_AZURE_CREDENTIALS`	The whole JSON from the command above
`HAGITAL_SUBSCRIPTION_ID`	My subscription ID
`HAGITAL_SSH_PUBLIC_KEY`	Output of `cat ~/.ssh/id_rsa.pub`
`HAGITAL_SSH_PRIVATE_KEY`	Output of `cat ~/.ssh/id_rsa`, including the BEGIN and END lines

If you don't have a key pair yet, ssh-keygen -t rsa -b 4096 makes one.

Last, I made an environment for the workflow to deploy into:

One small thing I noticed later. I named it "Hagital Production" here, but my YAML says hagital-production. GitHub doesn't complain, it just makes a new environment from the YAML. Keep the names identical so you don't end up with a stray one.

Part 3: Git and GitHub (where the fun started)

Error 1: "not a valid object name: 'master'"

I ran git init, and Git put me on a branch called master. I wanted main, so I typed:

git branch main

Git said no:

fatal: not a valid object name: 'master'

The reason is simple. A branch is a pointer to a commit, and I had zero commits. There was nothing to point at. So I did git status, git add . and git commit first.

After that commit, the same commands worked:

git branch main
git switch main

(Notice what was inside that first commit. It matters in Part 5.)

.gitignore

I made a .gitignore and added the .terraform/ folder to it.

touch .gitignore

Creating the workflow file on GitHub

To make the workflow file, I used the GitHub website. Add file > Create new file. When I typed .github/workflows/deploy.yaml in the name box, GitHub made both folders for me.

Then I copied the repo's HTTPS link:

And connected my laptop folder to it:

git remote add origin https://github.com/4thman/Hagital-project.git
git pull origin main --allow-unrelated-histories

The --allow-unrelated-histories part is there because GitHub already had its own first commit (the README and my new YAML file), and my laptop had a totally separate history. Git refuses to join two histories that don't share a parent unless you say it's okay.

Part 4: Write the workflow

The workflow has two jobs. provision builds the VM. configure waits for provision, then sets up the website.

Job 1: provision

name: Hagital VM Deploy

on:
  push:
    branches: ["main"]
  workflow_dispatch:

jobs:
  provision:
    runs-on: ubuntu-latest
    environment: hagital-production

    outputs:
      vm_ip: ${{ steps.tf_output.outputs.vm_ip }}

    steps:
      - uses: actions/checkout@v4

      - uses: azure/login@v2
        with:
          creds: ${{ secrets.HAGITAL_AZURE_CREDENTIALS }}

      - uses: hashicorp/setup-terraform@v3

      - name: Prepare SSH Public Key for Terraform
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.HAGITAL_SSH_PUBLIC_KEY }}" > ~/.ssh/id_rsa.pub

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: |
          terraform plan \
            -var="subscription_id=${{ secrets.HAGITAL_SUBSCRIPTION_ID }}" \
            -out=hagital.tfplan

      - name: Terraform Apply
        run: terraform apply hagital.tfplan

      - name: Get VM Public IP
        id: tf_output
        run: echo "vm_ip=$(terraform output -raw hagital_vm_public_ip)" >> "$GITHUB_OUTPUT"

The important parts:

on: says run when I push to main, or when I click the button myself (workflow_dispatch).
azure/login uses my robot account secret.
The last step reads the VM's IP from Terraform and saves it as a job output. That's how the second job learns where the VM is.

Job 2: configure

  configure:
    needs: provision
    runs-on: ubuntu-latest
    steps:
      - name: Prepare SSH Private Key
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.HAGITAL_SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa

      - name: Wait for SSH to become Available
        run: |
          for i in $(seq 1 10); do
            ssh -o StrictHostKeyChecking=no -i ~/.ssh/id_rsa \
              adminuser@${{ needs.provision.outputs.vm_ip }} echo ready && break
            echo "VM not Ready Yet, Waiting 15 Seconds..."
            sleep 15
          done

      - name: Install and configure the website
        run: |
          ssh -o StrictHostKeyChecking=no -i ~/.ssh/id_rsa adminuser@${{ needs.provision.outputs.vm_ip }} '
            sudo apt update && sudo apt upgrade -y
            sudo apt install nginx git -y
            cd /var/www/html
            sudo rm -f index.nginx-debian.html
            sudo git clone https://github.com/MettaSurendhar/omnifood.git .
            sudo chown -R www-data:www-data /var/www/html
            sudo systemctl restart nginx
          '

      - name: Show the live Website URL
        run: |
          echo "Hagital Website is Live and was deployed using CI/CD." >> "$GITHUB_STEP_SUMMARY"
          echo "Visit: http://${{ needs.provision.outputs.vm_ip }}" >> "$GITHUB_STEP_SUMMARY"

In plain words:

needs: provision means "don't start until the VM exists."
A brand new VM isn't ready for SSH right away. So the wait step tries to connect up to 10 times, 15 seconds apart.
Once in, the script installs nginx and git, then swaps nginx's default page for the website. More on that just below.
The last step writes the site's URL into the run summary, so I don't have to dig for the IP.

Where the website comes from

I didn't build the website myself. I used a public GitHub project called Omnifood (https://github.com/MettaSurendhar/omnifood), and the workflow copies it onto the VM. Here's how that works:

nginx is a web server. It shows whatever files sit in /var/www/html. Right after you install it, that folder only holds nginx's default "Welcome to nginx" page (index.nginx-debian.html).
The script deletes that page with sudo rm -f index.nginx-debian.html. Git can only clone into an empty folder, so the default page has to go first.
Then sudo git clone https://github.com/MettaSurendhar/omnifood.git . downloads the Omnifood files straight into that folder. The dot at the end means "put the files here, don't make a new folder."
chown gives nginx permission to read the files, and systemctl restart nginx makes it pick them up.

So when someone opens the VM's IP address, they see Omnifood, not the nginx welcome page. Want to show your own site? Change that one clone URL.

Back in VS Code, I saved the file and committed:

git status
git add .
git commit -m "wrote the Hagital deploy & configure script on the deploy.yaml file"

Part 5: Push day (three errors in a row)

Error 2: GitHub rejected my push

git push -u origin main

remote: error: File .terraform/providers/.../terraform-provider-azurerm_v5.4.0_x5.exe is 219.00 MB;
this exceeds GitHub's file size limit of 100.00 MB
remote: error: GH001: Large files detected.

The provider file that Terraform downloads is 219 MB, and GitHub's limit is 100 MB. I had put .terraform/ in .gitignore, so what happened?

Remember my very first commit in Part 3? I ran git add . before I made the .gitignore. Git had already saved that giant file. A .gitignore only stops Git from picking up new files. It does nothing about files that were already committed.

I added the state files to .gitignore too, then committed:

.terraform/
*.tfstate
*tfstate.*

The push failed again, with the same error. Deleting the file in a new commit doesn't help, because the old commit still carries it. The big file lives in my history.

While I was fixing things, I also changed the VM's key line in main.tf. The path ~/.ssh/id_rsa.pub only exists on my laptop, so I switched to the variable:

public_key = var.public_key

The fix that worked: this repo was brand new and had nothing worth saving, so I deleted Git's history and started over:

rm -rf .git
git init
git add .
git commit -m "removed git and readded git then re staged an commit"

This time .terraform wasn't in the commit. Seven small files went in.

⚠️ Don't do this on a real project. rm -rf .git wipes your whole history. I could do it because I had exactly two commits and both were disposable.

Error 3: the merge conflict

Same trick as before: git branch main failed until after the first commit. Once I had a commit, I made main and tried to join my history with GitHub's:

git merge origin/main --allow-unrelated-histories

Automatic merge failed; fix conflicts and then commit the result.

Both sides had a deploy.yaml, and Git couldn't pick one. My prompt changed to (main|MERGING). I wanted my local version, so:

git checkout --ours .github/workflows/deploy.yaml
git add .github/workflows/deploy.yaml
git commit -m "Merge GitHub main into local main"

The prompt went back to (main).

)

Then the push finally went through:

git push -u origin main

Your turn: look at your own repo's file list right now. Is anything in there that shouldn't be? Check before you push, not after.

Part 6: Watching GitHub Actions do the work

I opened the Actions tab and my workflow was already running.

Error 4: the workflow that waited forever

The provision job sat on Terraform Plan. Two minutes. Five minutes. Twenty minutes.

Quick guess before you scroll: what do you think it was waiting for?

Remember the prompt from Part 1, where Terraform asked me to type the public key? That's what happened. My main.tf now used var.public_key, but my workflow only passed subscription_id. So Terraform asked for the key and waited for someone to type it. Nobody types in GitHub Actions. It just sat there until the run gave up after 19 minutes and 50 seconds.

The fix is one extra line in the plan step:

      - name: Terraform Plan
        run: |
          terraform plan \
            -var="subscription_id=${{ secrets.HAGITAL_SUBSCRIPTION_ID }}" \
            -var="public_key=${{ secrets.HAGITAL_SSH_PUBLIC_KEY }}" \
            -out=hagital.tfplan

I also changed the apply line to terraform apply -auto-approve hagital.tfplan.

Error 5: my commit message broke Bash

When I committed the fix, I wrote a commit message that had ${{ secrets... }} inside double quotes. Bash tried to read it as a command and said:

bash: ... : bad substitution

Nothing got committed. I wrote a normal message instead (Add public key variable to Terraform plan) and it worked. Keep commit messages plain.

Then I pushed:

git push origin main

It works

That git push is the trigger. The on: push lines in the YAML tell GitHub to start the workflow every time new code lands on main.

A new run started. provision finished in 35 seconds. configure began.

The "Install and configure the website" step took a while, because apt was updating a whole Ubuntu machine.

The log gets long and ends with warnings about a pending kernel upgrade and services to restart. That's normal. Ubuntu is saying "a reboot would be nice." The job still finished green.

Here's the run list. Run #4 is green (4 minutes 19 seconds). Run #2 is the stuck one from before.

And here's my favourite part, the summary page, with the link my last step wrote:

I clicked the IP address. No "Welcome to nginx" page. It was the Omnifood website, cloned from GitHub onto a server that didn't exist 5 minutes earlier:

I did nothing by hand except push code.

Part 7: Delete everything with one click

A VM that runs forever keeps costing money. I wanted a way to tear it all down from GitHub, so I added a third job:

  destroy:
    if: github.event_name == 'workflow_dispatch'
    runs-on: ubuntu-latest
    environment: hagital-production

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Azure Login
        uses: azure/login@v2
        with:
          creds: ${{ secrets.HAGITAL_AZURE_CREDENTIALS }}

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Init
        run: terraform init

      - name: Terraform Destroy
        run: |
          terraform destroy \
            -auto-approve \
            -var="subscription_id=${{ secrets.HAGITAL_SUBSCRIPTION_ID }}" \
            -var="public_key=${{ secrets.HAGITAL_SSH_PUBLIC_KEY }}"

The if line is the switch. This job only runs when I click the button (workflow_dispatch), never on a normal push. So my code pushes can't accidentally delete my server.

But then the other two jobs needed the opposite switch. Without it, clicking the button would try to build the VM and delete it in the same run. So I added this line to both provision and configure:

    if: github.event_name == 'push'

Then the usual routine, with commit message "Added Manual Terraform Destroy Workflow":

git status
git add .github/workflows/deploy.yaml
git commit -m "Added Manual Terraform Destroy Workflow"
git push origin main

That push counts as a normal push, so provision and configure ran again and destroy was skipped (the grey circle). The site stayed up.

Proof the site was still alive:

Pulling the plug

Then I went to Actions > Hagital VM Deploy > Run workflow, picked the main branch, and clicked the green button.

This time provision and configure were skipped and only destroy ran. The log ends with the line I wanted to see:

Destroy complete! Resources: 8 destroyed.

Eight things built, eight things gone.

Why does this work on a fresh GitHub computer that has never seen my VM? Because of the remote state from Part 1. Terraform reads its notebook from Azure storage, sees what it built, and deletes exactly that.

One thing is still there. The state storage account (terraform-state-rg) was made by hand with the CLI, not by this Terraform code. If you want a zero bill, delete it yourself when you're done.

Every mistake in one place

#	What went wrong	Why	Fix
1	`git branch main` said "not a valid object name"	No commits yet, so the branch had nothing to point at	Make a commit first
2	GitHub rejected my push (219 MB file)	I ran `git add .` before making `.gitignore`, so the provider file was already in history	Create `.gitignore` first; I restarted the repo with `rm -rf .git`
3	Merge failed on `deploy.yaml`	GitHub and my laptop each had a different `deploy.yaml`	`git checkout --ours`, then add and commit
4	Terraform plan hung for 19+ minutes	`public_key` had no value and nobody can type in CI	Pass it with `-var` from a secret
5	`bad substitution` on commit	`${{ }}` inside a double-quoted commit message	Use a plain message

Things I'd do differently

Make .gitignore before the first git add . and list .terraform/ in it.
Don't leave SSH open to the world. My NSG allows port 22 from anywhere. I tried limiting SSH to GitHub's IP ranges at one point and backed it out, so this lab stays open. That's okay for something I destroy in a day.

Wrap up

And that’s it from a simple git push to a live website running on Azure, with Terraform and GitHub Actions handling the heavy lifting.

The biggest lesson for me wasn’t just learning Terraform or GitHub Actions. It was learning how to troubleshoot, fix mistakes, and keep going when things don’t work the first time.

git push → GitHub Actions → Terraform → Azure VM → Live Website
                                                          ↓
                                                One-click Destroy

📦 Full source code at my github repo: github.com/4thman/Hagital-project

Now I want to hear from you:

Where should the journey go next Docker containers, secure HTTPS, custom domains, OIDC authentication, or a fully automated production CI/CD pipeline?

And most importantly, what’s the biggest DevOps mistake you’ve ever made? 😄

Drop it in the comments. Let’s learn from each other!

One git push at a time. 🚀

Three Days, Four Errors, One Working Azure VM: Deploying with Terraform and Remote State

David Cletus — Wed, 09 Sep 2026 12:31:36 +0000

This was my first real hands-on Terraform assignment: deploy a working Azure VM, wire up a remote backend for the state file, and document the whole process. On paper it looked like a weekend task. It took me close to three days, mostly because I kept running into errors I'd never seen before and had to actually understand each one instead of working around it.

This post walks through what I built, the order I built it in, the four errors that stopped me at different points, how I got past each one, and the proof that it all worked in the end.

Repo: github.com/4thman/cloud-cohort

What I built

At a glance, the stack looks like this:

Internet
   │
   ▼
Public IP (cohort-pip)
   │
   ▼
NIC (cohort-nic)  ──secured by──  NSG (cohort-nsg: allow 22, allow 80)
   │
   ▼
VM: cohort-vm (Ubuntu 18.04 LTS, Standard_B1s)
   │
   ▼
Subnet (cohort-subnet, 10.0.0.0/24)
   │
   ▼
VNet (cohort-vnet, 10.0.0.0/16)
   │
   ▼
Resource Group: cohort-rg (East US)

Everything above lives in Terraform. The state file for all of it lives in an Azure Storage Account, not on my laptop. That was the part of the brief I hadn't done before, and it ended up being the most useful thing I learned.

Setting the stage

Nothing complicated here, just a folder and an editor.

cd Downloads
mkdir cloud-cohort
cd cloud-cohort
code .

First file: main.tf, empty.

Wiring up the provider

Every Terraform project starts with telling it which provider to talk to and which version to pin. I went with azurerm version ~> 5.4.0 since am working on Azure Platform.

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 5.4.0"
    }
  }
}

provider "azurerm" {
  features {}
  subscription_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Then the command that downloads the provider plugin and sets everything up:

terraform init

Building the network layer

I built this resource by resource, running terraform plan after almost every block just to see what was about to happen.

# Create a resource group
resource "azurerm_resource_group" "cohort-rg" {
  name     = "cohort-rg"
  location = "East US"
}

# Create a virtual network
resource "azurerm_virtual_network" "cohort-vnet" {
  name                = "cohort-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.cohort-rg.location
  resource_group_name = azurerm_resource_group.cohort-rg.name
}

# Create a subnet
resource "azurerm_subnet" "cohort-subnet" {
  name                 = "cohort-subnet"
  resource_group_name  = azurerm_resource_group.cohort-rg.name
  virtual_network_name = azurerm_virtual_network.cohort-vnet.name
  address_prefixes     = ["10.0.0.0/24"]
}

Locking it down with an NSG

I configured a Network Security Group (NSG) to control inbound traffic. I added two essential rules: SSH (port 22) to allow secure remote administration and HTTP (port 80) to enable web-server access for testing and demonstration purposes.

# Create a network security group & NSG rules
resource "azurerm_network_security_group" "cohort-nsg" {
  name                = "cohort-nsg"
  location            = azurerm_resource_group.cohort-rg.location
  resource_group_name = azurerm_resource_group.cohort-rg.name

  security_rule {
    name                       = "AllowSSH"
    priority                   = 1000
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "22"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }

  security_rule {
    name                       = "AllowHTTP"
    priority                   = 1001
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }
}

The NIC and a formatting habit

The network interface is what actually connects the VM to the subnet and, through the public IP, to the internet. I also started running terraform fmt before every plan around here. It costs nothing, and it catches the indentation mess before it becomes a diff you have to think about.

# Create a network interface
resource "azurerm_network_interface" "cohort-nic" {
  name                = "cohort-nic"
  location            = azurerm_resource_group.cohort-rg.location
  resource_group_name = azurerm_resource_group.cohort-rg.name

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.cohort-subnet.id
    private_ip_address_allocation = "Dynamic"
    public_ip_address_id          = azurerm_public_ip.cohort-pip.id
  }
}

# Associate the NIC with the NSG
resource "azurerm_network_interface_security_group_association" "cohort-nic-nsg" {
  network_interface_id     = azurerm_network_interface.cohort-nic.id
  network_security_group_id = azurerm_network_security_group.cohort-nsg.id
}

The actual VM

This is the main resource that everything else is built around: an Ubuntu 18.04 LTS virtual machine using the Standard_B1s size and authenticated with an SSH key instead of a password. I chose Ubuntu rather than a Microsoft Windows Server VM because Ubuntu is lightweight, open-source, and commonly used for hosting web servers and working with Linux-based cloud environments. It also provides a straightforward environment for installing and managing web-server software through the command line, making it a suitable choice for this learning project.

# Create a virtual machine
resource "azurerm_linux_virtual_machine" "cohort-vm" {
  name                = "cohort-vm"
  resource_group_name = azurerm_resource_group.cohort-rg.name
  location            = azurerm_resource_group.cohort-rg.location
  size                = "Standard_B1s"
  admin_username      = "cohortuser1"

  network_interface_ids = [
    azurerm_network_interface.cohort-nic.id,
  ]

  admin_ssh_key {
    username   = "cohortuser1"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "UbuntuServer"
    sku       = "18.04-LTS"
    version   = "latest"
  }
}

And two outputs so I don't have to go hunting through the Azure portal every time I need the IP or the username:

Cleaning up: variables and outputs

At this point, everything was hardcoded directly into main.tf. While this works, it makes the configuration harder to maintain, reuse, and modify for different environments. To improve the structure, I moved the repeated and changeable values into variables.tf and placed the two outputs into a separate outputs.tf file.

I created variables.tf to make the Terraform configuration more flexible and reusable. Instead of changing values directly inside main.tf, I can define them as variables and provide different values when needed. This makes it easier to reuse the same configuration for another environment without modifying the main infrastructure code.

I created outputs.tf to keep the information Terraform needs to display after deployment separate from the resource configuration. This makes the project more organised and allows important details, such as the VM's public IP address, to be easily accessed after the infrastructure has been created.

main.tf then got rewritten to reference var.* instead of literal strings:

Before	After
`location = "East US"`	`location = var.location`
`name = "cohort-rg"`	`name = var.resource_group_name`
`address_prefixes = ["10.0.0.0/24"]`	still literal (left this one alone on purpose)

One small mistake I made was in my variables.tf file. I used the description field to store the default value instead of explaining what the variable is for. For example, I used description = "cohort-rg" instead of description = "Name of the resource group".

This did not cause any problems because Terraform still works with it, but it makes the file less clear and harder to understand later. It is a small mistake, but it is something I would correct to keep the code clean and easy to maintain.

A duplicate-output gotcha

Ran terraform fmt and terraform plan right after the refactor, expecting a clean run. Instead, Terraform stopped me with this:

Error: Duplicate output definition
An output named "vm_username" was already defined at main.tf:134,1-21. Output names must be unique within a module.

Once I looked closer it made sense: I'd created outputs.tf with the two outputs, but never went back and deleted the original output blocks still sitting at the bottom of main.tf. Terraform was looking at two files both trying to define vm_username, and correctly refused to guess which one I meant. Deleted the leftover blocks from main.tf, re-ran plan, and got a clean 8-to-add.

Running terraform apply

ssh_Public_key and subscription_id don't have defaults in variables.tf on purpose. They're marked sensitive, and I didn't want them sitting in a file that might end up on GitHub. Terraform prompts for them at apply time instead.

terraform apply

Configuring the remote backend

This was the part of the brief I'd never actually done before, so it got its own careful pass.

The idea: instead of terraform.tfstate sitting on my machine, where it can get lost, overwritten, or just never seen by anyone else on a team, it lives in an Azure Storage Account, and Terraform reads and writes it there on every command.

First, log in and create the storage account and a container inside it:

az login

az storage account create `
  --name cohorttfstate `
  --resource-group cohort-rg `
  --location eastus `
  --sku Standard_LRS

az storage container create `
  --name tfstate `
  --account-name cohorttfstate `
  --auth-mode login

Then tell Terraform where to find it, right inside the terraform {} block:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 5.4.0"
    }
  }

  # Backend configuration for storing the Terraform state in Azure Blob Storage
  backend "azurerm" {
    resource_group_name  = "cohort-rg"
    storage_account_name = "cohorttfstate"
    container_name       = "tfstate"
    key                  = "terraform.tfstate"
  }
}

Running terraform init again picks up the new backend and asks whether to migrate the state that's currently sitting locally:

From this point forward, every terraform plan reads the state from Azure Blob Storage instead of a local file. This also means the Terraform state file, which contains information such as my resource IDs, is no longer stored on my laptop.

"No changes" here is the whole point: it means the remote state and the real infrastructure agree with each other, from somewhere that isn't tied to my one laptop.

Getting onto the box

Time to prove there's an actual, usable server behind all this config.

ssh cohortuser1@4.157.245.198

Then I tried to update and upgrade in one line and typed & where I meant &&:

sudo apt upgrade & update -y

& backgrounds the first command and immediately tries to run update as its own program, which doesn't exist as a standalone command, hence Command 'update' not found. && chains two commands so the second only runs after the first succeeds: one character, very different behaviour. Ran it properly afterward:

Then installed the two things I actually needed: nginx to prove a web server can be reached from outside, and git to push the code.

sudo apt install nginx && git -y
git --version

And in a browser, hitting the VM's public IP directly:

Proof in the portal

Terraform reported that it successfully created eight resources, and I verified this in the Azure portal, which also shows the same resources. This confirmed that the Terraform configuration was applied successfully and that the infrastructure was created as expected.

Tearing it down

Once everything was verified and screenshotted, I destroyed the whole stack. It's a learning VM, not a production workload, and there's no reason to let a Standard_B1s keep billing for the rest of the month for something I've already proven works.

terraform destroy

Because the state lived remotely, destroying it was as clean as creating it. Terraform read the real state from Blob Storage, worked out exactly what it had made, and took it all back down in one pass.

Getting this into GitHub

This is the section where I learned more about Git than about Terraform.

git init

I tried git branch main before making a single commit, which fails because there's no commit yet for a branch to point at (fatal: not a valid object name 'master'). Staged everything instead:

git commit -m "first commit on terraform cloud cohort from master branch"

Renamed the default branch from master to main to match what GitHub expects by default:

git branch main
git switch main

Created the repo on GitHub, private, with a README ticked on (a decision that comes back to bite me two steps from now):

git remote add origin https://github.com/4thman/cloud-cohort.git
git push -u origin main

The first push got rejected:

remote: error: File .terraform/providers/registry.terraform.io/hashicorp/azurerm/5.4.0/windows_amd64/terraform-provider-azurerm_v5.4.0_x5.exe is 219.00 MB; this exceeds GitHub's file size limit of 100.00 MB

Honestly, I didn't know GitHub even had a 100MB file size limit until this error told me. I'd just run git add . and pushed everything in the folder without thinking about what was actually sitting inside .terraform/. That folder is a local cache of provider plugins, genuinely huge (that one provider binary alone was 219MB), and it's something nobody needs in version control anyway since terraform init rebuilds it from scratch on any machine. So it needed to go in .gitignore instead of getting committed:

.terraform/

Staged it, committed it, and pushed again:

git add .
git commit -m "added .terraform folder to .gitignore due to push error"
git push -u origin main

Rejected a second time, this time with [rejected] main -> main (fetch first), because the README GitHub generated when I created the repo existed as a commit on the remote that my local history knew nothing about. Two histories, no shared ancestor Git could reconcile on its own.

Pulled the remote's history in, merged it with mine, and pushed one more time:

And the repo, live, with all three commits and the actual project files:

Repo: github.com/4thman/cloud-cohort

What I'd do differently

Add .gitignore before the first commit, rather than after the push. When I created the GitHub repository, I left the ADD README option enabled, which meant the local and remote repositories had different histories. I fixed this by running git pull to bring the README into my local repository and merge the changes before pushing my files.

Write proper descriptions in** variables.tf** instead of putting the default value in the description field. I should also add the .tfstate files to .gitignore, not just .terraform/. My state file ended up in the first commit, and although there was nothing sensitive in this particular file, Terraform state files can contain sensitive information and should not normally be committed to GitHub.

None of these broke the deployment. All of them are the kind of thing you only really learn by hitting them once.

If you made it this far, thanks for reading! 🙌 I’d love to hear from you what’s one Terraform, Azure, or Git mistake you’ve made while learning, and what did it teach you? Drop it in the comments; your experience might save someone else a few hours of frustration. If you found this walkthrough useful, like ❤️, comment 💬, and share 🔄 it with someone else learning Terraform or Azure. Let’s learn from the mistakes, not hide them!

From Zero to Auto-Scaling Hero: Deploying a VMSS on Azure 🚀

David Cletus — Wed, 08 Jul 2026 00:03:12 +0000

From Zero to Auto-Scaling Hero: Deploying a VMSS on Azure 🚀

Ever wondered how big websites survive a sudden rush of visitors without crashing? The secret is auto-scaling — the server army quietly grows when traffic spikes, and shrinks back down when things calm down, so nobody pays for computers they don't need.

In this post, I'm walking you through exactly how I built that on Microsoft Azure — from a completely empty subscription to a live webpage served by 5 auto-scaling virtual machines sitting behind a load balancer.

By the end, you'll have your own mini traffic-proof web app running in the cloud, and you'll know how to tear it all down without leaving a single unpaid bill behind.

📚 This is part of a series! I've already covered the foundational pieces in earlier posts:

🔗 https://dev.to/4thman/inside-azure-networking-how-i-created-a-virtual-network-with-custom-subnets-35g4 — The "land and street" this project is built on

🔗 https://dev.to/4thman/i-built-my-first-azure-vm-from-scratch-and-hosted-a-live-website-1ob0 — The basics of a single server, before we multiply it into a scale set

If any of the early steps below feel unfamiliar, those posts break them down in full detail. Here, I'll recap them quickly and then dive deep into the part that's new: auto-scaling with VMSS.

🧩 What We're Actually Building

Think of it like building a house, street by street:

Resource Group – an empty folder that holds everything we create (so we can delete it all in one click later)
Virtual Network (VNet) + Subnet – the private street our servers will live on
Virtual Machine Scale Set (VMSS) – a group of identical servers that can grow or shrink automatically
Load Balancer – the traffic cop that spreads visitors evenly across all the servers
A tiny Apache web page – so we have something to actually see working in the browser

Here's the flow in one picture (in your head, for now): Resource Group → Network → Subnet → Scale Set → Load Balancer → 🌍 Live Website

✅ Before You Start

An active Azure subscription (Pay-As-You-Go or free trial both work)
Nothing else! Azure gives you everything else through the portal — no local software needed for this tutorial
(Optional but helpful) A quick read of my earlier posts on https://dev.to/4thman/inside-azure-networking-how-i-created-a-virtual-network-with-custom-subnets-35g4 — This post builds directly on top of those concepts

Step 1: Say Hello to the Azure Portal 👋

Everything starts here — portal.azure.com. This is mission control for every Azure resource you'll ever create.

The Azure homepage — our home base for the whole build.

Step 2: Quick Recap — Resource Group, VNet & Subnet 📁🛣️🏘️

I've already walked through this part step-by-step in an earlier post, so here's the short version — check out Setting up a Resource Group, Virtual Network & Subnet on Azure for the full click-by-click guide.

Here's what happened, in a nutshell:

Created a Resource Group called Smyles-RG — the folder that holds everything in this project, so it can all be deleted in one click later.

Built a Virtual Network called Smyles-VN inside that resource group — a private, isolated network, like a gated estate for our resources.

Carved out a Subnet called Smyles-Subnet inside the VNet — a smaller slice of that estate where our servers will actually live.

💡 Simple English tip: Resource Group = the folder. VNet = the private estate. Subnet = the specific street inside it. Our servers move in next.

With the land prepped, we're ready for the main event.

Step 3: Create the Virtual Machine Scale Set (VMSS) 🖥️🖥️🖥️

This is the star of the show. A VMSS doesn't create just one server — it creates a template for identical servers that Azure can multiply or shrink automatically based on demand.

3.1 — Find and open VMSS

Search "vmss" in the top search bar and select Virtual machine scale sets.

Click Create.

3.2 — Basics: name, region, and zones

Fill in the resource group (Smyles-RG), give the scale set a name (Smyles-vmms), pick your region, and choose Zones 1, 2, 3 for high availability (this spreads your servers across different physical data centers, so one outage doesn't take everything down).

3.3 — Orchestration and scaling mode

Choose:

Orchestration mode: Flexible — the modern, more flexible way Azure manages your servers
Scaling mode: Autoscaling — this is the whole point! Let Azure decide how many servers we need based on CPU usage

3.4 — Configure the scaling rules

Click Configure to fine-tune exactly how the auto-scaling should behave.

Click Add a scaling condition, name it (Smyles-scaling-condition), and set the instance limits — I chose a minimum of 2 and a maximum of 5 servers.

Then define the actual trigger rules:

Scale out (add a server) when CPU usage goes above 80%
Scale in (remove a server) when CPU usage drops below 20%

Save it, and you'll see both the Default condition and our new Smyles-scaling-condition sitting side by side.

💡 In plain English: "If the servers are working too hard (above 80% CPU), add a helper. If they're bored (below 20% CPU), send a helper home. Never go below 2 or above 5 helpers."

3.5 — Instance details: OS, size, and count

Set the instance count to 5, choose the image — I picked Ubuntu Server 24.04 LTS — and select a size. I went with the budget-friendly Standard B1ms.

3.6 — Admin account

Create a login for the servers. I used the username smyles with a password (SSH keys work too, if you prefer).

3.7 — Networking: plug into our VNet

Head to the Networking tab. Select Smyles-VN and Smyles-Subnet. Click Create new nic to set up the network card for our servers.

Name the NIC (Smyles-Networkinterface), keep the network security group on Basic, and allow HTTP (port 80) so the outside world can actually reach our website.

3.8 — Add a Load Balancer

Still on the Networking tab, choose Azure load balancer, then click Create a load balancer.

Name it Smyles-loadbalancer, set the type to Public (so it has an internet-facing address), and the protocol to TCP. Click Create.

💡 Simple English tip: A load balancer is like a receptionist. Visitors don't talk to individual servers — they talk to the receptionist, who quietly sends them to whichever server is free.

3.9 — Health monitoring

Switch to the Health tab and enable Application health monitoring. This lets Azure automatically detect and replace any server that stops responding.

Click Configure and set:

Protocol: HTTP
Port: 80
Request path: /

Then Save.

3.10 — Custom Data (the magic script)

This is where the servers get their personality. In the Advanced tab, under Custom data and cloud-init, I pasted a small Bash script that automatically installs a web server and creates a webpage — the moment each server boots up, it's already ready to greet visitors.

Here's the exact script I used:

#!/bin/bash
sudo apt-get update -y
sudo apt-get install apache2 -y
sudo systemctl enable apache2
sudo systemctl start apache2
HOSTNAME=$(hostname)
cat <<EOF | sudo tee /var/www/html/index.html
<!DOCTYPE html>
<html>
<body style="font-family:Arial;text-align:center;padding-top:100px;background:#f4f4f4">
<h1 style="color:#0078D4">Hello from $HOSTNAME</h1>
<p>Azure VMSS Instance</p>
</body>
</html>
EOF
sudo systemctl restart apache2

What this script does, in plain English:

Line	What it means
`apt-get update`	Refreshes the list of available software
`apt-get install apache2`	Installs Apache — a popular web server
`systemctl enable/start apache2`	Turns the web server on, and keeps it on after reboots
`HOSTNAME=$(hostname)`	Grabs the unique name of this particular server
`cat <<EOF ... EOF`	Writes a simple HTML webpage that greets visitors with the server's own name
`systemctl restart apache2`	Restarts the web server so the new page shows up

The cool part? Because this script runs on every single instance in the scale set, each server will proudly display its own unique name — so when we later refresh the load balancer's page, we can literally watch traffic bounce between different servers!

3.11 — Review and create

With everything configured, click Review + create. Wait for the green "Validation passed" banner, then click Create.

Sit back and relax while Azure spins up 5 identical virtual machines for you. ☕

Step 4: See It Come Alive 🌍

4.1 — Grab the load balancer's address

Open your new scale set (Smyles-vmss) and go to Networking → Load balancing.

Copy the Frontend IP address — this is the single public address that represents all five of your servers.

4.2 — Paste it in your browser

Paste that IP address into a new browser tab and hit enter...

"Hello from smyles-vmR4TV8G" — a real, working, auto-scaling web app, built entirely from the ground up! Refresh the page a few times and watch the hostname change as the load balancer sends you to different servers behind the scenes. That's auto-scaling infrastructure in action. 🎉

Step 5: Clean Up — Don't Leave the Lights On! 💡

Cloud resources cost money for every hour they exist, even if nobody's visiting your website. Once you're done experimenting, tear it all down — and thanks to our Resource Group trick from Step 2 (or see the full explanation in my earlier Resource Group post), this takes seconds.

Go back to Resource groups and open Smyles-RG.

Click Delete resource group.

Type the resource group name to confirm (Azure double-checks so you don't delete anything by accident), then click Delete.

And just like that — the VMs, load balancer, network, subnet, and everything else vanish, and your billing stops. One folder in, one folder out. Also do the same for NetworkWatcherRG 🧹

🎯 What We Actually Learned

Resource Groups keep your projects tidy and easy to delete
Virtual Networks & Subnets give your servers a private, controlled space to live in
VMSS with Autoscaling means your infrastructure grows and shrinks with real demand — you stop paying for idle servers
Load Balancers spread traffic so no single server gets overwhelmed
Custom Data / cloud-init lets you automate server setup completely — no manual SSH-ing into five different machines
Health monitoring keeps your app resilient by auto-replacing unhealthy instances

That's the entire journey — from an empty Azure subscription to a self-healing, self-scaling website, torn down responsibly at the end. If you followed along, you didn't just read about cloud infrastructure — you built it. 🙌

Got questions or stuck somewhere? Drop a comment below — happy to help troubleshoot!

Follow me for more hands-on Azure and cloud engineering walkthroughs, straight from my own learning journey. ☁️

I Built My First Azure Virtual Machine From Scratch and Hosted a Website Using Apache2 🌐

David Cletus — Sat, 20 Jun 2026 15:15:00 +0000

Building My First Azure Virtual Machine From the Ground Up 🚀

In this post, I'll walk you through exactly how I went from an empty Azure subscription to a live Ubuntu VM running Apache, complete with every screen I clicked through. No skipped steps, no "and then magic happens."

By the end, you'll be able to do this yourself in under 20 minutes. Let's go! 👇

💬 Heads up: This is a follow-along tutorial. Grab a coffee, open a second tab with your Azure portal, and build alongside me.

✅ What You'll Build

[x] A Resource Group to hold everything together
[x] A Virtual Network (VNet) with a custom address space
[x] A Subnet inside that VNet
[x] A Virtual Machine (Ubuntu 24.04 LTS) deployed into that subnet
[x] SSH access into the VM from VS Code's terminal
[x] A live Apache2 web server you can visit in your browser
[x] A clean teardown so you don't get billed for forgetting it 💸

🧰 Prerequisites

An Azure account (free tier works fine)
A terminal — I used VS Code's integrated terminal (bash/Git Bash)
15–20 minutes and a bit of curiosity

🗺️ The Architecture (in plain English)

Resource Group  (the folder that holds everything)
   └── Virtual Network   (10.0.0.0/16)
         └── Subnet      (10.0.0.0/24)
               └── Virtual Machine  (Ubuntu 24.04, public IP, SSH + HTTP open)

Resource Group first, then network, then subnet, then the actual VM goes into that subnet. Let's build it top-down.

Step 1: Create a Resource Group 📁

A Resource Group is basically a folder in Azure — it keeps every resource for this project (network, VM, disks, IP) organized together so you can manage or delete them as one unit.

Firstly I login into the Azure Homepage via https://portal.azure.com/

From the Azure homepage, I searched for Resource Groups and hit Create.

I named mine VM-RG-Test and picked France Central as my region — pick whatever region is closest to you.

While on the Review + Create page, I clicked Create after reviewing the details of the Resource Group.

A few seconds later — done! ✅

💡 Tip: Whatever region you pick here is the one you should use for every resource in this tutorial. Mixing regions adds latency and (sometimes) extra cost.

Step 2: Create a Virtual Network (VNet) 🌐

Next, your VM needs a network to live in. I searched for Virtual networks

and clicked Create.

I assigned it to my VM-RG-Test resource group and named it VM-Virtual-Network, same region as before.

On the Address space tab, Azure gives you a default 10.0.0.0/16 range with a default subnet already attached. I deleted that default subnet — I want to create my own with a name that actually makes sense — then hit Review + create.

Validation passed, so I clicked Create.

Once the deployment finished, I clicked Go to resource.

Step 3: Add a Subnet 🧩

A VNet without a subnet is just an empty container — the subnet is where your VM's network card actually attaches.

Inside the VNet, I went to Settings → Subnets.

And clicked Create on the subnet page.

I named it VM-Sub-Net, left the default 10.0.0.0/24 range (251 usable IPs — plenty for one VM), and clicked Add.

And there it is — one ready-to-use subnet.

Step 4: Create the Virtual Machine 🖥️

This is the main event. I searched for Virtual machines

And clicked Create, then selected the first option, which is Virtual Machine.

4.1 — Basics: name, region, resource group

I dropped this VM into my existing VM-RG-Test resource group and named it VM-Test.

4.2 — Image, size, and authentication

For the image, I went with Ubuntu Server 24.04 LTS - x64 Gen2, kept the size small (Standard_B1ls) to keep costs minimal, and chose SSH public key as the authentication method instead of a password — much safer.

4.3 — Username, SSH key, and inbound ports

I set my username to VM-David, let Azure generate a new SSH key pair for me, named the key VM-Test_key, and allowed inbound traffic on HTTP (80) and SSH (22) — HTTP so I can later view my website, SSH so I can connect and manage the server.

⚠️ Allowing SSH from "any IP" is fine for a quick test like this, but for production you'd lock it down to your own IP address using the Advanced networking controls.

4.4 — Disks

I kept the default Standard SSD for the OS disk — good enough for a test server, no need for Premium SSD here.

4.5 — Networking: plugging it into our VNet/Subnet

This is where everything we built earlier comes together — I selected my VM-Virtual-Network and VM-Sub-Net, let Azure create a new public IP, and chose HTTP (80), SSH (22) as the allowed inbound ports.

I also checked "Delete public IP and NIC when VM is deleted" — a small checkbox that saves you from leaving orphaned (and billable!) resources behind later.

4.6 — Review + Create

Validation passed (estimated cost: under $8/month for this tiny config 🙌), so I hit Create.

Azure immediately prompted me to download the private key — this is your only chance to grab it, since Azure never stores the private half of the key pair.

And there's my .pem key, safely sitting in my Downloads folder.

🔐 Don't lose this file. Without it, you can't SSH into your VM. Treat it like a password.

A minute or two later, the deployment finished.

Step 5: Confirm the VM Is Alive ✅

On the VM's overview page, I could see its public IP, private IP, region, and size — and the status read Running.

Step 6: SSH In and Install Apache 🔧

Time to actually log into the server. I opened VS Code's terminal then swicthed to Bash from Powershell(you can use Git-bash also), navigated to my Downloads folder (where the key lives), locked down the key's permissions, and connected.

# 1. Go to where the key was downloaded
cd Downloads

# 2. Restrict permissions on the key (required by SSH)
chmod 400 VM-Test_key.pem
# (chmod 600 also works on most systems)

# 3. Connect to the VM using the key, username, and public IP
ssh -i VM-Test_key.pem VM-David@98.66.137.84

# 4. Update package lists
sudo apt update

# 5. Install Apache2 web server
sudo apt install apache2

The first time you connect, SSH will ask if you trust the host's fingerprint — type yes to continue. Running whoami afterward confirmed I was logged in successfully.

After updating, I installed Apache2:

Step 7: See It Live in the Browser 🌍

With Apache installed and running, I opened a browser and typed in the VM's public IP address. And there it was — the Apache2 default "It works!" page, served straight from my own Azure VM.

This was honestly the most satisfying part — seeing a page load from infrastructure I built myself, end to end. 🎉

Step 8: Clean Up — Delete the Resource Group 🧹

Azure bills you for running resources, so once I was done testing, I deleted the whole resource group. Because everything (VM, disk, NIC, public IP, SSH key, VNet) was inside VM-RG-Test, one deletion removes it all.

👀 Spot the extra one? There's also a NetworkWatcherRG sitting in that list. Azure creates this automatically the first time you use any network diagnostics feature in a region — I didn't make it on purpose. It doesn't cost anything by itself, but since I was cleaning house, I deleted it too.

Azure shows you exactly what's about to be deleted — 7 resources in my case — and makes you type the resource group's name to confirm. No accidental deletions here.

A couple minutes later, it was gone — clean slate, zero ongoing cost.

🎯 Recap

Step	What Happened
1	Created a Resource Group (`VM-RG-Test`)
2	Created a Virtual Network (`VM-Virtual-Network`, `10.0.0.0/16`)
3	Added a Subnet (`VM-Sub-Net`, `10.0.0.0/24`)
4	Deployed an Ubuntu VM into that subnet with an SSH key
5	Connected via SSH from VS Code's terminal
6	Installed and ran Apache2
7	Visited the live page in a browser
8	Deleted everything to avoid surprise charges

🗣️ Over to you

Drop a comment below 👇 — and if this helped you, a like/follow goes a long way! 🙌

Inside Azure Networking: How I Created a Virtual Network with Custom Subnets

David Cletus — Thu, 04 Jun 2026 23:54:09 +0000

If you've ever stared at the Azure portal wondering where to even begin with networking, you're not alone. I was right there a few weeks ago. In this post, I'm walking you through exactly what I did — from creating a resource group to building a virtual network with three custom subnets. No fluff, just real steps with real screenshots.
Let's get into it.

Head over to portal.azure.com
Once logged in,

Step 1 — Search for Resource Groups

The first thing you want to do is head to the Azure portal and use the search bar at the top to look up "resource group". You'll see it pop up under Services — click on Resource groups.

💡 Quick note: I covered resource group creation in a previous blog too, but I'm including the steps here again so this post is fully self-contained. No jumping around needed.

Step 2 — Create a New Resource Group

Once you're on the Resource Groups page, you'll see a list of any existing groups or an empty list with a create button visible on the page. To create a new one, click the + Create button at the top left.

Step 3 — Fill in the Resource Group Details

On the creation form, you need to fill in three things:

Subscription — select your active subscription (mine is Azure subscription 1)
Resource group name — I named mine Netaccess
Region — I chose (Africa) South Africa North since that's closest to me

Once filled in, click Review + create.

Step 4 — Review and Create the Resource Group

You'll be taken to a summary screen. Confirm the details look right — subscription, name, and region. Then hit the Create button at the bottom.

Step 5 — Resource Group Created!

Once Azure finishes provisioning (it's pretty fast — usually a few seconds), you'll see a notification on the right confirming that the resource group was created successfully. Your new Netaccess group will now appear in the list.

Step 6 — Search for Virtual Networks

Now that our resource group is ready, it's time to create a Virtual Network inside it. Use the top search bar again and type "virtual networks". Click on Virtual networks from the Services dropdown.

Step 7 — Create a Virtual Network

You'll land on the Virtual Networks overview page. Since we don't have any yet, it'll say "No virtual networks to display." Click the + Create button (either at the top or the one in the centre of the page).

Step 8 — Fill in the Virtual Network Basics

On the Basics tab of the creation wizard, configure the following:

Subscription — Azure subscription 1
Resource group — Select the Netaccess group we just created
Virtual network name — I named it Netaccess-VM
Region — (Africa) South Africa North

Then click Next to move to the next tab.

Step 9 — Configure Address Space and Delete the Default Subnet

Skip past the Security tab (leave everything as default) and head to the Address space tab. Here Azure has already set up a default address space of 10.0.0.0/16 — that gives us 65,536 IP addresses, which is way more than enough.
Now here's the important part: Azure also pre-creates a default subnet with the range 10.0.0.0 - 10.0.0.255 (/24). We're going to delete this because we want to create our own subnets with custom names and IP ranges.
Click the trash/delete icon on the right side of the default subnet row to remove it.

Why delete the default subnet? Because accepting defaults means Azure names and organises things on your behalf. When you create your own subnets from scratch, you control the naming convention, IP ranges, and how traffic is logically segmented. Clean slate = cleaner architecture.

Step 10 — Review and Create the Virtual Network

Click through to the Review + create tab. You'll see a green "Validation passed" banner at the top — Azure confirming everything looks good. Take a moment to review the summary:

Subscription: Azure subscription 1 ✅
Resource Group: Netaccess ✅
Name: Netaccess-VM ✅
Region: South Africa North ✅
Security (Bastion, Firewall, DDoS): all Disabled ✅

Hit the Create button at the bottom.

Step 11 — Deployment Complete — Click "Go to Resource"

Azure will now provision your virtual network. It usually takes just a minute or less. Once done, you'll land on the deployment overview showing "Your deployment is complete" with a green checkmark.
Click Go to resource to open your newly created Netaccess-VM virtual network.

Step 12 — Explore the VNet Overview and Navigate to Subnets

You're now inside the Netaccess-VM virtual network overview page. You can see all the essentials — resource group, location, address space (10.0.0.0/16), and notice it currently shows 0 subnets (because we deleted the default one earlier).
In the left sidebar under Settings, click on Subnets. This is where we'll build all three of our custom subnets.

Step 13 — Click "+ Subnet" to Start Adding Subnets

Once you're on the Subnets page, you'll see "No items found" — exactly as expected. Click the + Subnet button at the top of the page to open the "Add a subnet" panel on the right side.

Step 14 — Add Subnet 1 (Netaccess-subnet1)

The "Add a subnet" panel slides in from the right. Fill in the following:

Subnet purpose — Default
Name — Netaccess-subnet1
IPv4 address range — 10.0.0.0/16 (this is auto-populated from your VNet address space)
Starting address — 10.0.0.0
Size — /24 (256 addresses)

This creates a subnet range of 10.0.0.0 - 10.0.0.255. Leave IPv6 unchecked and scroll down to click Add.

Step 15 — Add Subnet 2 (Netaccess-subnet2)

Click + Subnet again to add the second subnet. You'll notice the panel now shows the existing subnet1 listed on the left — that's just confirmation it was saved. Fill in the new details:

Name — Netaccess-subnet2
Starting address — 10.0.1.0
Size — /24 (256 addresses)

Subnet range: 10.0.1.0 - 10.0.1.255. Click Save.

Notice how we moved the third octet from .0.0 to .1.0 for the second subnet — that's how we keep each subnet in its own separate IP block within the same /16 space. No overlap, no conflict, no headaches so we do the same to create Netaccess-subnet3.

Step 16 — All Three Subnets Created Successfully

Repeat the same process one final time for the third subnet:

Name — Netaccess-subnet3
Starting address — 10.0.2.0
Size — /24

After saving, your Subnets page will now show all three subnets neatly listed with their IPv4 ranges highlighted:
NameIPv4 RangeAvailable IPsNetaccess-subnet110.0.0.0/24251Netaccess-subnet210.0.1.0/24251Netaccess-subnet310.0.2.0/24251

Each subnet has 251 usable IP addresses — When a resource is created, it uses one IP address from its subnet, and that IP is no longer available in the virtual network's address range. However, IP usage is managed at the subnet level, so a subnet can run out of addresses while the virtual network still has many unused IPs available in other subnets.

Cleanup — Deleting the Resources

Once I was done with the lab, I cleaned everything up to avoid unnecessary charges. Here's how:
Delete the Netaccess Resource Group
Go back to Resource groups, select Netaccess, click Delete resource group, type the name to confirm, and hit Delete.

Delete the NetworkWatcherRG

Azure automatically creates a NetworkWatcherRG resource group when you deploy networking resources. Delete this one too — same process: select it, click Delete resource group, type the name, confirm.

All Resource Groups Deleted

Once both are gone, your resource groups list is clean again — back to just the ones you had before (in my case, only Je-mega-soft remains).

Summary

Here's the full recap of what we did:

✅ Searched for and opened Resource Groups
✅ Created the Netaccess resource group in South Africa North
✅ Searched for and navigated to Virtual Networks
✅ Filled in VNet Basics — name Netaccess-VM, resource group Netaccess
✅ On the Address space tab, deleted the auto-generated default subnet
✅ Reviewed and created the Virtual Network (validation passed)
✅ Deployment completed — clicked Go to resource
✅ Navigated to the Subnets section inside the VNet
✅ Clicked + Subnet to start adding custom subnets
✅ Created Netaccess-subnet1 → 10.0.0.0/24
✅ Created Netaccess-subnet2 → 10.0.1.0/24
✅ Created Netaccess-subnet3 → 10.0.2.0/24
✅ Cleaned up both Netaccess and NetworkWatcherRG resource groups

Why This Matters
Understanding how to manually structure your subnets gives you real control over how traffic flows in your cloud environment. Instead of accepting defaults, you're deliberately choosing IP ranges — which becomes crucial when you start doing things like:

Separating frontend and backend application tiers
Connecting on-premises networks via VPN Gateway or ExpressRoute
Setting up Network Security Groups (NSGs) with rules per subnet
Deploying services that require dedicated subnets (like Azure Bastion or App Gateway)

This is foundational Azure networking.

If this helped you, drop a ❤️ or leave a comment — especially if you ran into something different in your own setup. I'd love to hear about it.
Until next time — keep building! 🚀

How I Hosted a Free Website on Azure Blob Storage (No Server Needed!)

David Cletus — Wed, 03 Jun 2026 07:33:07 +0000

Introduction

So I wanted to host a website without paying for a web server or dealing with complex configurations. Turns out, Azure Blob Storage has a brilliant feature called Static Website Hosting that lets you serve HTML, CSS, and JavaScript files directly from a storage container — kind of like having a mini web host built into your cloud storage.
In this post, I'll walk you through exactly what I did, step by step, with screenshots. The website template I used is called Nexus Brew — a cyberpunk-themed cafe website from Tooplate.com, which offers free HTML templates.
By the end of this guide, your site will be live at a URL like this:

https://jewebs.blob.core.windows.net/$web/index.html

Let's get into it!

Step 1 — Download the Nexus Brew Template from Tooplate
Before jumping into Azure, the first thing I did was grab the website template.
I went to tooplate.com — a site that offers clean, modern, free HTML templates built with Bootstrap and CSS. They have over 80 templates for startups, small businesses, and portfolios.

I searched for and found the Nexus Brew template.

It's a dark, cyberpunk-style cafe website template with features like:

A hero banner section
A tabbed menu showcase
An about section with content and images
A contact form
Social media links
Smooth scroll navigation and hover effects

It looks super cool — very futuristic and modern. Perfect for learning!
I clicked the Download button on the template page to grab the zip file.

The downloaded file was named 2146_nexus_brew.zip and it landed in my Downloads folder.

Step 2 — Extract the Zip File
After downloading,

I extracted the zip file. Inside the 2146_nexus_brew folder, you'll find these files:

index.html — the main HTML page
tooplate-nexus-brew.css — the stylesheet
tooplate-nexus-scripts.js — the JavaScript file
ABOUT THIS TEMPLATE.txt — info about the template
images/ — a folder containing all the images used on the site

These are all the files I'll need to upload to Azure later.

Step 3 — Find Resource Groups in the Azure Portal
Now it's time to head over to portal.azure.com.
Once logged in,

I used the search bar at the top and typed "resource group". In the dropdown that appeared, I clicked on Resource groups (the one listed under Services).

What is a Resource Group?
Think of a Resource Group as a folder in Azure where you keep related things together. It helps you manage, organize, and delete resources (like storage accounts) as a unit.

Step 4 — View the Existing Resource Group Created in the Last Blog

After clicking Resource groups, I could see my existing resource group named Je-mega-soft which was created in our last blog, located in South Africa North under Azure subscription 1.
I clicked on it to open it.

Step 5 — Search for Storage Accounts
Inside the Resource Manager section, I used the search bar again and typed "storage account". From the suggestions, I clicked on Storage accounts (the one listed under Services — not the classic version).

This took me to the Storage center where I could see existing storage accounts and create new ones.

Step 6 — Create a New Storage Account
On the Storage center page, I clicked the + Create button at the top to start creating a new storage account.

On the Basics tab of the creation form, I filled in these details:

Resource group: Je-mega-soft (selected from the dropdown)
Storage account name: jewebs (this has to be globally unique — all lowercase, no special characters)
Region: (Africa) South Africa North (I chose the region closest to me)
Preferred storage type: Azure Blob Storage or Azure Data Lake Storage
Performance: Standard (recommended for most use cases)
Redundancy: Locally Redundant Storage (LRS) (the most affordable option — stores 3 copies of your data within one data center)

Why LRS? For a static website that's just for learning or low-traffic use, LRS is more than enough and the cheapest option.

Step 7 — Enable Anonymous Access in the Security Tab
After filling in the Basics, I clicked Next to navigate through the tabs until I reached the Security tab.
Here, the most important setting to enable is:
✅ Allow enabling anonymous access on individual containers
I made sure this checkbox was ticked.

The red arrow in my screenshot points directly to this option — don't miss it!

Why is this important? Without enabling anonymous access, your static website files would be private by default. No one on the internet would be able to open your website. Enabling this allows the $web container (which Azure creates for static websites) to serve files publicly.

Once done, I clicked Review + create, reviewed the settings, and clicked Create.

Step 8 — Deployment Complete! Go to Resource
After a few seconds, the deployment finished and I saw the "Your deployment is complete" message.
The notification bell at the top right also showed a green checkmark saying "Deployment succeeded" — the deployment was to resource group Je-mega-soft.

I clicked the Go to resource button (there's one in the main panel and one in the notification panel — either works) to open the newly created storage account.

Step 9 — Navigate to Static Website Settings
Now I was inside the jewebs storage account dashboard.
On the left sidebar, I scrolled down and expanded the Data management section. Inside it, I clicked on Static website.

If you don't see Data management, look for it in the left panel — it's usually collapsed. The red arrow in my screenshot points directly to it.

Step 10 — Enable the Static Website Feature
On the Static website page, by default the feature is set to Disabled.
I clicked on Enabled to turn it on.

As soon as I enabled it, two input fields appeared:

Index document name: nexus_brew.html
Error document path: ERROR-404.html

This is the page that shows when someone visits a URL that doesn't exist. You can create a simple 404 page or just use the default.

After filling these in, I clicked Save.

Step 11 — Settings Saved Successfully
A green notification appeared in the top right corner saying "Successfully updated static website settings".
On the same page, I could now see:

The static website is Enabled
A message saying: "An Azure Storage container has been created to host your static website."
A link to the container: $web
The Primary endpoint URL: https://jewebs.z1.web.core.windows.net/

What is $web? This is a special Azure container that's automatically created when you enable static website hosting. It's where you'll upload all your website files.

I clicked on $web to open that container.

Step 12 — Upload Files to the $web Container
Inside the $web container, it was empty — showing "No items found".
I clicked the Upload button at the top to open the Upload blob panel on the right side.

I then selected all the files from the extracted Nexus Brew folder:

index.html
tooplate-nexus-brew.css
tooplate-nexus-scripts.js
ABOUT THIS TEMPLATE.txt
The images folder

The upload panel showed "7 file(s) selected" (the images folder contains multiple image files, so the total count goes up).

I clicked the Upload button in the panel to start the upload.

Important tip: Make sure to upload the contents of the folder, not the folder itself. Azure Blob Storage needs the files at the root level of $web for the static website to work correctly. If you upload a folder as a subfolder, your index page won't load properly.

Step 13 — Files Successfully Uploaded
After the upload completed, the $web container now showed all my files:
NameTypeSizeimagesFolder—ABOUT THIS TEMPLATE.txtBlock blob557 Bindex.htmlBlock blob16.8 KiBtooplate-nexus-brew.cssBlock blob24.78 KiBtooplate-nexus-scripts.jsBlock blob3.52 KiB
All 5 items were now visible and available in the container — uploaded on 6/2/2026 at 10:38 PM.

Step 14 — Copy the URL of the Index File
To get the direct URL of the uploaded index.html file, I:

Clicked the three-dot menu (...) next to index.html
Selected Copy URL from the context menu

The URL I got was:
https://jewebs.blob.core.windows.net/$web/index.html

Note: There are actually two URLs you can use:

Blob URL (direct file): https://jewebs.blob.core.windows.net/$web/index.html

Static website URL (cleaner): https://jewebs.z1.web.core.windows.net/

The Website Is Live! 🎉

That's it! The Nexus Brew template is now hosted live on Azure Blob Storage as a static website.
You can visit it at:
👉 https://jewebs.blob.core.windows.net/$web/index.html

           Quick Summary of All Steps

Here's a quick recap of everything we did:

Downloaded the Nexus Brew free HTML template from tooplate.com
Extracted the zip file and noted the files inside
Open the Azure Portal and search for Resource groups in the Azure portal
Opened the existing Je-mega-soft resource group which was previously showed on our last blog how to create.
Searched for Storage accounts and clicked Create
Configured the storage account with name jewebs, region South Africa North, Standard performance, and LRS redundancy
In the Security tab, enabled Allow anonymous access on containers
Deployed and clicked Go to resource
Navigated to Data management → Static website
Enabled static website hosting and set the index document name
Saved settings and noted the $web container and primary endpoint URL
Opened the $web container and uploaded all website files
Confirmed all files were uploaded successfully
Copied the URL and opened the live websit e

Why I Loved This Approach

Honestly, this whole setup took less than 15 minutes and didn't require me to set up a web server, configure Nginx or Apache, deal with SSL certificates manually, or pay for a VM. Azure handles everything for you and even gives you HTTPS for free through the static website endpoint.
For simple websites — portfolios, landing pages, documentation sites, or just practice — this is one of the easiest and cheapest ways to get something live on the internet.

Resources Used:

Tooplate.com — Free HTML templates
Azure Static Website Hosting Docs
Azure Account.

Step-by-Step Guide to Azure Blob Storage: Uploading Files, Enabling Public Access, and Secure SAS Link Generation

David Cletus — Thu, 28 May 2026 22:09:47 +0000

In this article, I will walk through how I created an Azure Storage account, configured Blob Storage, uploaded a file, made it publicly accessible, and finally generated a Shared Access Signature (SAS) link for secure access.

This is part of my hands-on learning journey in Cloud Computing and DevOps using Microsoft Azure.

Creating the Azure Storage Account

The first step was to create a Storage Account in Microsoft Azure. This is the core service that provides a scalable location for storing files such as images, videos, documents, and backups.

Configuration used:
Resource Group: je-mega-soft
Storage Account Name: prodjemegastorage1
Region: Africa (South Africa North)
Primary Service: Azure Blob Storage
Performance: Standard
Redundancy: Locally Redundant Storage (LRS)
Access Tier: Hot
Allow Blob Public Access: Enabled (on container level)
Explanation of each choice:

Resource Group (je-mega-soft):
A resource group is simply a logical container in Azure that holds related resources. I used this to group everything related to my project for easy management and cleanup.

Storage Account Name (prodjemegastorage1):
This must be globally unique across Azure. I used a structured name to represent a production-style storage setup.

Region (Africa – South Africa North):
I selected this region because it is geographically closer to my location, which reduces latency and improves performance when accessing resources.

Primary Service (Blob Storage):
Blob Storage is designed for storing unstructured data like images, videos, logs, and backups. It is the best choice for this type of project.

Performance (Standard):
Standard performance was chosen because this is a learning/demo project. It is cost-effective and suitable for general-purpose storage. Premium would only be needed for high-speed enterprise workloads.

Redundancy (Locally Redundant Storage - LRS):
LRS stores data in a single data center but keeps multiple copies within that facility. I chose this because it is the cheapest option and perfect for testing and learning purposes.

Access Tier (Hot):
The Hot tier is used for data that is accessed frequently. Since I planned to upload and access the file during testing and sharing, this was the best fit.

Public Access Enabled:
I enabled public access at the container level because I wanted the uploaded file to be accessible via a URL without authentication.

After reviewing all settings, I clicked Create and waited for deployment to complete.

Creating a Blob Container

After the storage account was successfully created, I moved to the next step which is creating a container.

Path:
Storage Account → Data Storage → Containers → + Add Container

Container configuration:
Name: jemega-img-vid
Public Access Level: Container (anonymous read access for containers and blobs)
Why I used this container name:

I chose jemega-img-vid because:

“jemega” represents my personal/project brand name
“img-vid” clearly indicates the container is meant for images and videos
It is short, readable, and meaningful for future scaling
Public Access Level explanation:

Setting the access level to Container means:

Files inside the container can be publicly accessed
Anyone with the link can view blobs without authentication
This is useful for demos, static file hosting, and learning scenarios
About the $logs container:

During setup, Azure automatically created a container called $logs.

This container is used for system-generated logs such as:

Storage analytics logs
Request tracking logs
Diagnostic monitoring data

It is not meant for user files, so I did not modify or use it.

Uploading the File to Blob Storage

Next, I uploaded a file into the container.

File uploaded:
just me.png

Steps:

Opened the container (jemega-img-vid)
Clicked on Upload
Selected the file from my local system
Clicked Upload to store it in Azure Blob Storage

Once uploaded, Azure automatically generated a unique URL for the file.

Blob URL generated:

https://prodjemegastorage1.blob.core.windows.net/jemega-img-vid/just%20me.png

Explanation:

This URL directly points to the file inside the container. Because public access was enabled, the file can be accessed in a browser without authentication.

Generating a Shared Access Signature (SAS)

To improve security while still allowing temporary access, I generated a Shared Access Signature (SAS).

What is SAS?

A SAS token is a secure way to grant limited access to storage resources without exposing your account keys. It allows you to define:

What can be accessed
How long access is valid
What permissions are allowed
Why I used Key 1:

I used Key 1 from the storage account because it is one of the primary access keys used to generate SAS tokens. These keys should be protected because they grant full control over the storage account.

SAS configuration used:
Start Time: Today at 10:30 PM
Expiry Time: 31st of this month at 12:03 PM
Permissions: Read (sp=r)
Protocol: HTTPS only

Why SAS is important:

SAS provides:

Temporary access instead of permanent public exposure
Better security control over shared files
Ability to revoke access by changing keys or expiry
Fine-grained permissions (read, write, delete, etc.)

*Final SAS URL (Secure Access Link)
*
Here is the final link generated using SAS:

https://prodjemegastorage1.blob.core.windows.net/jemega-img-vid/just%20me.png?sp=r&st=2026-05-28T21:12:08Z&se=2026-05-31T11:03:08Z&spr=https&sv=2026-02-06&sr=b&sig=SseErml92AKi5t60kVuYCN8DNP%2BBkKm4CaXtHwhTqwo%3D

Conclusion

This walkthrough helped me understand the basics of Azure Blob Storage, from creating a storage account and container to uploading a file and generating a SAS link for controlled access. I also learned how key settings like redundancy, access tier, and public access affect cost, performance, and security. Overall, it made cloud storage concepts clearer and gave me a solid foundation for working with Azure storage services going forward.

I Created an Azure User, Gave It Global Admin Access, Revoked It, and Tested Azure IAM — Here’s What I Learned

David Cletus — Fri, 22 May 2026 01:20:29 +0000

As part of my Cloud Engineering and DevOps learning journey, I recently decided to go beyond theory and start practicing Identity and Access Management (IAM) directly inside Microsoft Azure.

I wanted to understand how organizations manage users, permissions, administrative access, and security in real cloud environments. Instead of just reading about Microsoft Entra ID and RBAC, I performed a complete hands-on lab from start to finish.

In this lab, I:

created a new Azure user
configured Microsoft Authenticator
assigned administrative roles
logged into the new account using an incognito browser
created another user using delegated access
revoked the permissions
tested whether the account could still perform administrative actions

This exercise gave me a much deeper understanding of how cloud identity management works in enterprise environments.

The screenshots attached throughout this post document the entire process step by step.

Starting From the Default Directory

I began by logging into the Azure Portal using my main administrator account inside the default directory.

From there, I navigated to:

Microsoft Entra ID → Users → All Users

This section contains every identity managed inside the Azure environment, including:

users
groups
applications
permissions

At this point, I already had administrative privileges, which allowed me to create and manage other users.

One thing I’m beginning to understand about cloud platforms is that structure and organization are extremely important. Without proper identity management, large organizations would struggle to control access securely.

Creating the “Immortel” User

The next step was creating a new user account named “Immortel.”

During the setup process, I configured:

display name
username
password settings
account information

After creating the account successfully, the new user appeared immediately inside the Azure users list.

This helped me understand how organizations onboard employees into Microsoft Entra ID environments.

At this stage, the account existed but had limited permissions.

Logging Into the Immortel Account Using Incognito Mode

Instead of signing out from my main administrator account, I opened a new incognito browser window and logged into the Immortel account separately.

This allowed me to:

remain logged into my administrator account
test the Immortel account independently
simulate how multiple administrators may work simultaneously

Using incognito mode was actually very useful because it helped me manage both accounts side by side without interrupting my existing Azure session.

At this stage, the Immortel account still had very limited access because no elevated administrative roles had been assigned yet.

This demonstrated an important cloud security principle known as:

Least Privilege Access

This means users should only receive the minimum permissions necessary for their tasks.

Setting Up Microsoft Authenticator (MFA)

While logging into the Immortel account, Azure required Multi-Factor Authentication (MFA) setup using Microsoft Authenticator.

This process involved:

scanning a QR code
linking the account to the Authenticator app
approving sign-in requests

This was one of the most practical parts of the exercise because it showed me how organizations secure user accounts beyond just passwords.

I now understand why MFA is considered one of the most important security practices in cloud computing. Even if a password gets compromised, unauthorized users still cannot access the account without the additional verification step.

Assigning Global Administrator and Global Reader Roles

After setting up the Immortel account successfully, I returned to my original administrator session inside the default directory and assigned two important roles:

Global Administrator
Global Reader

This introduced me to Azure Role-Based Access Control (RBAC).

Before this exercise, RBAC sounded theoretical while reading documentation. But seeing it work practically made everything much clearer.

Understanding the Global Administrator Role

Global Administrator is one of the highest privileged roles inside Microsoft Entra ID.

A user with this role can:

create and manage users
assign permissions
manage identity settings
configure security
reset passwords
control administrative settings

In simple terms, this role has broad control over the Azure identity environment.

Understanding the Global Reader Role

Global Reader works differently.

Users with this role can:

view configurations
monitor environments
review settings

but they cannot make administrative changes.

This role is useful for:

auditors
compliance teams
monitoring personnel

who need visibility without modification access.

Logging Back Into the Immortel Session

After assigning the roles, I refreshed and continued working inside the incognito browser session already logged into the Immortel account.

The difference was immediately noticeable.

The account now had elevated privileges and could access administrative capabilities that were unavailable earlier.

This demonstrated how permissions in Azure are controlled dynamically through assigned roles.

It also showed me how powerful RBAC is in enterprise cloud environments.

Creating Another User Named “Dare”

To confirm the permissions were working correctly, I used the Immortel account to create another user named “Dare.”

The creation process was successful.

This confirmed that the Global Administrator privileges assigned earlier were active and functioning properly.

At this point, I fully understood how delegated administration works in Azure environments.

Organizations can temporarily assign elevated permissions to specific users without permanently granting full administrative control to everyone.

Revoking the Administrative Access

After completing the delegated administration test, I returned to my original administrator session inside the default directory.

I then removed:

Global Administrator access
Global Reader access

from the Immortel account.

This part of the exercise taught me another important IAM concept:

Permissions can be granted and revoked at any time.

This is critical in real-world environments for situations such as:

employee resignation
temporary contractors
security incidents
role changes
access reviews

Testing the Revoked Account

To confirm the permissions were truly removed, I returned to the incognito browser session using the Immortel account and attempted to create another user named “John.”

This time, the operation failed.

The account no longer had sufficient privileges to perform administrative tasks.

This final test clearly demonstrated how Azure immediately enforces permission changes once access is revoked.

It was satisfying seeing the entire IAM workflow function exactly as expected.

What This Lab Taught Me

This hands-on exercise helped me better understand:

Microsoft Entra ID
Identity and Access Management (IAM)
RBAC
Multi-Factor Authentication (MFA)
delegated administration
access control
permission revocation
cloud security principles

More importantly, it helped me realize that identity management is one of the most critical aspects of cloud security.

Without proper IAM controls:

unauthorized access becomes easier
security risks increase
governance becomes difficult
compliance becomes harder to maintain

Final Thoughts

This was one of the most valuable Azure labs I’ve completed so far because it moved beyond theory into practical identity administration and security management.

As I continue learning Cloud Engineering and DevOps, I’m beginning to appreciate how important hands-on practice is. Reading documentation is useful, but actually performing these tasks inside a real cloud environment creates a completely different level of understanding.

I still have a long way to go, but each lab continues to build my confidence and understanding step by step.

I’ll continue documenting my learning journey, projects, and hands-on experiences as I grow in cloud engineering and DevOps.

[Boost]

David Cletus — Thu, 14 May 2026 20:23:27 +0000

David Cletus

May 14

Creating My First Azure Resource Group as I Begin My Journey Into Cloud Engineering and DevOps

#azure #beginners #cloud #devops

2 min read

Creating My First Azure Resource Group as I Begin My Journey Into Cloud Engineering and DevOps

David Cletus — Thu, 14 May 2026 20:18:29 +0000

Today I took another practical step in my Cloud Engineering and DevOps learning journey by creating my first Resource Group on Microsoft Azure.

As someone currently learning cloud computing and DevOps from scratch, this may seem like a small task, but it actually helped me understand how cloud infrastructure is organized in real-world environments.

In the screenshot above, I was working inside the Azure Portal while creating a Resource Group called “Hagital-Resource-Group” and selecting the “South Africa North” region.

This simple setup exposed me to important cloud concepts such as subscriptions, regions, resource organization, and infrastructure management.

What is a Resource Group?

A Resource Group in Azure acts like a container that holds related cloud resources together.

For example, a company can keep:

virtual machines
databases
storage accounts
applications
virtual networks

inside one Resource Group instead of managing them separately.

This makes resources easier to organize, monitor, secure, and manage.

A simple way to think about it is like creating a folder on your computer for a particular project where all related files are stored together.

What I Learned During This Setup

While creating this Resource Group, I learned a few important things about how cloud platforms work.

Subscriptions

Azure uses subscriptions to manage billing and cloud services. Every resource created inside Azure belongs to a subscription.

Regions

Cloud providers do not keep all their infrastructure in one location. They build data centers across different countries and locations around the world called regions.

I selected the “South Africa North” region because it is geographically closer to Africa and can help improve performance and reduce latency for users in this region.

Resource Organization

I also learned how organizations group cloud resources based on projects, departments, or applications. This becomes very important in large environments where thousands of resources may exist.

Why I Started Learning Cloud Engineering and DevOps

Technology is moving heavily toward cloud infrastructure and automation. Many organizations now rely on cloud providers like Microsoft Azure, AWS, and Google Cloud to run their systems and applications.

I decided to start learning cloud engineering and DevOps because I want to understand modern infrastructure, automation, and how scalable systems are built and managed.

Right now, I’m learning:

cloud fundamentals
Microsoft Azure
Linux
networking
DevOps concepts
virtual machines
resource management

I also plan to learn tools like Docker, Git, Kubernetes, Terraform, and CI/CD pipelines as I continue growing in this field.

What I Learned Today

Some of the key things I learned from this exercise include:

how Azure Resource Groups work
how subscriptions are used in Azure
the importance of regions in cloud computing
how cloud infrastructure is organized globally
the value of hands-on practice while learning technology
Final Thoughts

This is still the beginning of my journey, but I’ve realized that small practical steps are important when learning cloud technologies.

I plan to continue documenting my progress, sharing what I learn, and building projects along the way.

There is still a lot to learn, but I’m excited about the process and looking forward to improving consistently over time.

cloudcomputing #azure #devops #cloudengineering #learninginpublic

DEV Community: David Cletus

Dockerizing a Node App & Shipping It to Azure: Build, Break, Fix & Ship (3 Errors, Zero Regrets) 🐳

What we're building

Step 1 — Laying the groundwork

Step 2 — Writing the app

Step 3 — Building the frontend

Step 4 — Writing the Dockerfile

Step 5 — First build, first surprise

Debugging: the case of the missing module

Success — locally, at last

Quick concept check: EXPOSE vs -p vs --dns-name-label

Step 6 — Cleaning up locally

Step 7 — Logging into Docker Hub

Step 8 — Pushing to Docker Hub

Step 9 — Logging into Azure

Step 10 — Creating the resource group (and hitting error #1)

Fixing error #1: the provider that wasn't switched on

Error #2: pick an OS, any OS

It worked — container created

Step 11 — Grabbing the live URL

It's alive on the internet 🎉

Step 12 — Checking logs straight from Azure

Step 13 — Tearing it down

Step 14 — Finally, version control

What I'd tell past-me

Links

I Built a One-Click Azure CI/CD Pipeline with Terraform & GitHub Actions From git push to a Live Website

What we're building

Words I'll use

What you need

Part 1: Build the Terraform files on my laptop

Make a folder and open it

Give Terraform a safe place for its notebook

Provider and backend

The actual resources

Init and plan

Variables and outputs

Part 2: Let GitHub talk to Azure

Adding the secrets

Part 3: Git and GitHub (where the fun started)

Error 1: "not a valid object name: 'master'"

.gitignore

Creating the workflow file on GitHub

Part 4: Write the workflow

Job 1: provision

Job 2: configure

Where the website comes from

Part 5: Push day (three errors in a row)

Error 2: GitHub rejected my push

Error 3: the merge conflict

Part 6: Watching GitHub Actions do the work

Error 4: the workflow that waited forever

Error 5: my commit message broke Bash

It works

Part 7: Delete everything with one click

Pulling the plug

Every mistake in one place

Things I'd do differently

Wrap up

Three Days, Four Errors, One Working Azure VM: Deploying with Terraform and Remote State

What I built

Setting the stage

Wiring up the provider

Building the network layer

Locking it down with an NSG

The NIC and a formatting habit

The actual VM

Cleaning up: variables and outputs

A duplicate-output gotcha

Running terraform apply

Configuring the remote backend

Getting onto the box

Proof in the portal

Tearing it down

Getting this into GitHub

What I'd do differently

From Zero to Auto-Scaling Hero: Deploying a VMSS on Azure 🚀

From Zero to Auto-Scaling Hero: Deploying a VMSS on Azure 🚀

🧩 What We're Actually Building

✅ Before You Start