DEV Community: David Cletus

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