DEV Community: David Cletus

Hands-On AWS: Spin Up IAM, S3 and a Jenkins Server on EC2 (and Fix What Breaks)

David Cletus — Wed, 14 Oct 2026 22:29:26 +0000

A step-by-step AWS lab with lots screenshots: create and delete an IAM user, host a site on S3, launch an EC2 server and run Jenkins on it, including the two errors I hit and how I fixed them.

Almost every AWS learning path starts with the same three moves: decide who is allowed to do what, store a file somewhere, and start a server. That is IAM, S3 and EC2, and nearly everything else on AWS sits on top of those three.

So I did all three for real, took a screenshot of every click, hit two errors along the way, fixed them, and then deleted everything at the end of each part so nothing was left running on my bill.

This post is the full walkthrough. By the end you will have:

Created an IAM user, signed in as that user, forced a password reset, and deleted the user
Created an S3 bucket, uploaded a website into it, made it public, and opened it in a browser
Launched an Ubuntu server on EC2, connected over SSH, installed Java and Jenkins, and unlocked Jenkins in the browser
Seen exactly what two common AWS errors look like, why they happen, and how to fix them
Cleaned up every resource so you do not pay for what you are not using

The plan

Part	Service	What I built	How I cleaned up
1	IAM	A user called `4thman` with console access and a forced password reset	Deleted the user
2	S3	A bucket called `4thman-bucket` serving my CV website	Emptied and deleted the bucket
3	EC2	An Ubuntu server called `4thman-server` running Jenkins	Stopped, then terminated the instance

Before you start

An AWS account. I worked as the root user for this lab (more on why that is not ideal in a moment).
A terminal with SSH. I used Git Bash on Windows. macOS and Linux terminals work the same way.
A small static website if you want to repeat the S3 part. I used my own CV website, a one-page site built from a Tooplate template called StackCraft: one index.html, one CSS file, one JavaScript file and an images folder. Any simple HTML, CSS and JS site will do.
A second browser window in incognito or private mode, for testing the IAM user.

A note on cost: everything here is small, but "small" only stays small if you clean up. That is why every part ends with a teardown. Free tier and credits differ between accounts, so check your own billing page.

Part 1: IAM, deciding who gets to do what

Why I did not just keep using root

Look at the top right corner of the next screenshot. It says root. The root user owns the account and can do absolutely anything, including closing it. You use it to get started, and then you stop using it. Day-to-day work belongs to an IAM user with only the permissions it needs. That principle is called least privilege, and IAM is the service that enforces it.

AWS Console Home, signed in as the root user

Step 1: Open IAM

In the search bar at the top of the console, type iam and pick IAM from the Services list.

Searching for IAM in the console search bar

Step 2: Create the user

In the sidebar, open IAM users. The count says (0), so this account has no IAM users yet. Click Create user.

IAM users page with no users yet and the Create user button

Step 3: Fill in the user details

This screen has four decisions on it:

User name: 4thman
Provide user access to the AWS Management Console: ticked, because I want this user to be able to sign in on the website and not just use the CLI
Console password: I chose Custom password so I could pick my own. The rules are at least 8 characters and a mix of at least three of: uppercase, lowercase, numbers and symbols.
Users must create a new password at next sign-in: ticked. AWS marks this as recommended, and it is a good habit. Whoever receives the temporary password has to replace it with their own on first login.

User details: name, console access, custom password and forced reset

Step 4: Permissions

The next step offers three ways to give permissions: add the user to a group, copy permissions from another user, or attach policies directly. AWS recommends groups, because you manage "the Developers" once instead of managing every developer separately.

For this lab I did not want this user to be able to do anything yet, so I left the defaults alone and clicked Next.

Set permissions step, left on the defaults

Step 5: Review and create

The review page shows the choices I made: custom password, password reset required. The part I want you to notice is Permissions summary. I never attached a policy, but one is listed: IAMUserChangePassword. AWS adds it automatically when you force a password reset, because the user needs permission to change their own password. It lets them do that and nothing else, which is exactly least privilege at work.

Click Create user.

Review page showing IAMUserChangePassword as the only policy

Step 6: Save the sign-in details

The next screen is the only time AWS shows you the console password. It also gives you the sign-in URL, which follows this pattern:

https://<your-account-id>.signin.aws.amazon.com/console

Copy the details or click Download .csv file before leaving this page.

User created, with the console sign-in URL, user name and password

Step 7: Sign in as the new user

I opened an incognito window so I could stay signed in as root in my normal window. On the IAM user sign-in page I entered the account ID, the user name 4thman and the temporary password.

Signing in as the new IAM user in an incognito window

Straight after clicking Sign in, AWS showed this:

Password reset screen shown at first sign-in

That message says the password "has expired or requires a reset", which sounds like a problem. It is not. It is the "must create a new password" option from Step 3 doing its job. I entered the old password once, the new one twice, watched the green Matches appear, and clicked Confirm Password Change.

Password reset successful

Then I signed in again with the new password and landed on the console as 4thman. Notice the account menu at the top right now shows the user name instead of root.

Console Home as the 4thman IAM user

One thing to watch: this console opened in Europe (Stockholm), because the sign-in page had redirected me to a Stockholm sign-in endpoint. IAM users are global, so that does not affect the user. But most other services are regional, so always check the region selector before you create anything.

This user can open the console but cannot do much with it. The only policy attached lets them change their own password. That is the point of starting with nothing and adding permissions deliberately.

Step 8: Delete the user

Back in my root window, the IAM users list now shows 4thman with real activity: last activity and console sign-in a couple of minutes ago, password age of a few minutes. I ticked the box next to the user and clicked Delete user.

Selecting the user and clicking Delete user

AWS makes you type confirm before it deletes anything. It is a small speed bump on purpose. Deleting a user also removes its credentials, so there is no undo.

Typing confirm to delete the user

IAM done. One user created, tested and removed.

Part 2: S3, storing files and serving a website

What S3 actually is

S3 is object storage. You create a bucket (a container), and everything you put in it is an object. Two details are worth knowing before you start:

Bucket names are unique across all AWS accounts in the world, not just yours.
S3 has no real folders. When the console shows an images/ folder, that is just a shared prefix in the file names. You will see this when the folder appears in the object list later.

Step 1: Find S3 and create a bucket

Search for s3 buckets and open S3. If you have no buckets yet, the landing page shows a big Create bucket button.

Searching for S3 in the console

The S3 landing page and its Create bucket button

Step 2: Name the bucket

I confirmed the region was US East (N. Virginia) us-east-1, kept the type as General purpose, kept the default global namespace, and named the bucket 4thman-bucket. Bucket names must be 3 to 63 characters and can only contain lowercase letters, numbers, periods and hyphens.

Region, bucket type and the bucket name 4thman-bucket

Step 3: Leave the safe defaults alone

Scroll down and you will see two settings I deliberately did not change:

Object Ownership: ACLs disabled (recommended). Access is controlled through policies only.
Block all public access: ticked. All four sub-settings are on.

AWS builds buckets private by default, and that is a good thing. These two defaults are also the reason I hit an error in a few minutes, so keep them in mind.

Object Ownership with ACLs disabled and Block all public access ticked

At the bottom, default encryption is already on (SSE-S3, with a bucket key enabled). I left it and clicked Create bucket.

Default encryption settings and the final Create bucket button

Step 4: Upload the CV website

The bucket now exists and says Objects (0). Click Upload.

Bucket created and empty, with the Upload button

I added the four files that make up my CV website: index.html, tooplate-stackcraft-script.js, tooplate-stackcraft-style.css, and about.jpg inside an images/ folder. The upload summary reports 4 files totalling 229.1 KB with 0 failures. Notice the destination, s3://4thman-bucket, and that about.jpg shows images/ in the Folder column.

Upload succeeded: 4 files, 229.1 KB, 0 failed

The files are in, but because the bucket is private, nobody on the internet can open them yet. Time to change that.

Error 1: "Access denied" when making the files public

I went back to the object list, ticked every file and folder, and opened the Actions menu to choose Make public using ACL.

)

Selecting all objects and opening the Actions menu

The next page shows two banners, and both matter:

A green one: Successfully enabled ACLs (Bucket owner preferred). Because I created the bucket with ACLs disabled, and "Make public" works by setting an object ACL, the console switched the ownership setting for me.
A blue one: Public access is blocked because Block Public Access settings are turned on for this bucket.

I read the green one, ignored the blue one, and clicked Make public.

First Make public attempt, with the ACL banner and the Block Public Access warning

The result, for all four objects:

Failed to edit public access: Access denied on all four objects

Failed to edit public access: Access denied.

Reading the error properly

My first instinct with "Access denied" was to check my permissions. But I was the root user, so permissions were not the problem. The blue banner had already told me the cause.

There are two separate gates on public access in S3:

Object ACLs and ownership, which decide how an individual object can be made public. The console fixed this one for me.
Block Public Access, a bucket-level safety switch that overrides ACLs and bucket policies. It was still on, and it wins every time.

Even if the object says "public", Block Public Access says "no".

The fix

Open the bucket and go to the Permissions tab.

Opening the Permissions tab of the bucket

Under Block public access (bucket settings) it says Block all public access: On. Click Edit.

)

Block all public access is On, with the Edit button

Untick Block all public access. That clears all four boxes underneath it. Click Save changes and confirm the warning S3 shows you.

)

Block all public access unticked, then Save changes

Now repeat the original action. Back on the Objects tab I selected everything again and opened Actions.

Selecting all objects again and opening Actions

On the Make public page, I clicked Make public again. This time there was no blue warning.

Second Make public attempt, with no blocking warning

The summary now reads: Successfully edited public access, 4 objects, 229.1 KB, 0 failed.

Successfully edited public access: 4 objects, 0 failed

See it live

I ticked index.html only and clicked Copy URL. The console confirmed with Object URL Copied.

Copying the object URL of index.html

Pasting it into a new tab loaded my full CV website straight from S3, with my name, role, skills, work and experience sections all in place. The URL has this shape:

https://<bucket-name>.s3.<region>.amazonaws.com/index.html

The CSS, JavaScript and image all loaded as well, because I made every object public, not just the HTML file.

My CV website loading straight from S3

A word of caution. Opening a whole bucket to the internet is fine for a throwaway demo. For a real site, keep the bucket private and put CloudFront in front of it, or at least use a bucket policy that only allows reading the specific objects you want public.

Cleanup: empty the bucket, then delete it

S3 will not delete a bucket that still has objects in it. I selected everything and clicked Delete.

Selecting all objects and clicking Delete

S3 asks you to type permanently delete to confirm. This cannot be undone. (The Empty button on the bucket list does the same job in one step.)

Typing permanently delete to confirm

With the bucket empty, I went back to the bucket list, selected 4thman-bucket and clicked Delete.

Selecting the empty bucket and clicking Delete

To confirm, I typed the bucket name. Read the warnings on this page: once a bucket is deleted, its name is released and another AWS user can claim it.

Typing the bucket name to confirm deletion

S3 done. A bucket created, a website served from it, one error fixed, everything removed.

Part 3: EC2, a server in the cloud, running Jenkins

The vocabulary you need first

Term	What it means
EC2 instance	A virtual server running in AWS
AMI	The image the server starts from: operating system plus preinstalled software. I used an Ubuntu image
Instance type	The size of the machine. I used `t3.micro` (2 vCPU, 1 GiB memory)
Key pair	A public and private key used to log in over SSH. AWS keeps the public half. You keep the private `.pem` file
Security group	A virtual firewall around the instance that decides which ports accept traffic
Jenkins	An open source automation server, widely used to build, test and deploy code (CI/CD)

Step 1: Launch the wizard

Search for ec2 and open EC2. (The green banner partly visible behind the search box is the bucket deletion confirming.)

Searching for EC2 in the console

On the EC2 landing page, click Launch instance.

The EC2 landing page and its Launch instance button

AWS then offered a choice of walkthroughs. I picked Learn about EC2 and launch test instances. That is why a Tutorial panel appears on the right side of the next screenshots: it lists the steps and, handily, ends with a reminder to terminate your instance.

Choosing the Learn about EC2 walkthrough

Step 2: Name it and pick an image

I named the instance 4thman-server, chose Ubuntu from the Quick Start images, and left the number of instances at 1. The Summary panel on the right tracks everything you choose: image, instance type, firewall and storage.

Naming the instance, choosing Ubuntu and setting the number of instances

Step 3: Instance type and key pair

I picked t3.micro. Scrolling down to Key pair (login), I clicked Create new key pair.

Instance type and the Create new key pair link

I named it 4thman-key, kept RSA as the type and .pem as the format (the format for OpenSSH, which is what Git Bash uses), and clicked Create key pair.

Creating the key pair 4thman-key as RSA and .pem

The browser downloaded 4thman-key.pem immediately.

4thman-key.pem downloaded by the browser

Guard this file. AWS only keeps the public half of the key. This download is the only copy of the private half. Lose it and you cannot SSH into the server. Never commit it to GitHub.

Step 4: Network and security group

In Network settings:

Auto-assign public IP: Enable, so the server is reachable from the internet
Create security group (a new firewall for this instance)
Allow SSH traffic from: Anywhere (0.0.0.0/0), so I can log in
Allow HTTP traffic from the internet: ticked
Allow HTTPS traffic from the internet: left unticked

AWS shows a yellow warning that 0.0.0.0/0 means every IP address. For a short-lived lab that is acceptable. For anything longer, choose My IP instead of Anywhere.

Network settings: public IP, new security group, SSH and HTTP allowed

Step 5: Review and launch

Storage stayed at the default 8 GiB gp3 root volume. The Summary panel showed one instance, the Ubuntu image, t3.micro, a new security group and one 8 GiB volume. I clicked Launch instance.

Summary panel and the Launch instance button

A note on the screenshots in this section. Some of the launch screenshots (the key pair, security group, launch summary, success banner and running view) were captured on an earlier launch of the same setup, so the instance size, instance ID and IP address differ from the server used in the SSH and Jenkins steps. The clicks are identical. When I talk about the server's public IP from here on, use the one on your own instance page.

AWS replied with a green Success banner and the new instance ID. The page also suggests next steps, including Create billing usage alerts. Next time I will set that up before launching anything.

Instance launch initiated successfully

On the Instances page the new server went to Running, and the status checks passed. In the details panel, copy the Public IPv4 address. You need it to connect.

Instance running, with its public IPv4 address

Step 6: Lock down the key file and connect over SSH

While you are here, fix the key's permissions. SSH refuses to use a private key that other users on the machine can read, so restrict it:

cd Downloads
ls -l 4thman-key.pem
chmod 400 4thman-key.pem
ls -l 4thman-key.pem

chmod 400 means read-only for the file owner and nothing for anyone else. In the screenshot the listing goes from -rw-r--r-- to -r--r--r--. Because this is Git Bash on a Windows drive, permission bits do not map exactly like on Linux, but SSH accepted the key anyway.

Restricting the key file with chmod 400

Now connect. The default user on Ubuntu images is ubuntu:

ssh -i "4thman-key.pem" ubuntu@<your-public-ip>

The first time, SSH asks whether you trust this host. Type yes. The Ubuntu welcome banner appears and the prompt changes to ubuntu@ip-172-31-25-206:~$, which means every command from now on runs on the server in AWS and not on my laptop.

Connected to the server over SSH

Step 7: Update the server

sudo apt update
sudo apt upgrade -y

apt update refreshes the list of available packages. apt upgrade -y installs updates without asking for confirmation. On a fresh image there was nothing pending, and apt reported All packages are up to date.

sudo apt update and sudo apt upgrade -y

Step 8: Install Java

Jenkins is a Java application, so Java comes first. fontconfig is a small dependency Jenkins needs for rendering fonts.

sudo apt install fontconfig openjdk-21-jre -y

Installing fontconfig and OpenJDK 21

Check it worked:

java -version

You should see an OpenJDK 21 version string. You can see mine at the top of the screenshot in the next step.

Step 9: Add the Jenkins repository

Ubuntu's default repositories do not include Jenkins. The Jenkins project publishes its own package repository, so we add that and tell apt to trust its signing key:

sudo mkdir -p /etc/apt/keyrings

sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key

echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/" \
  | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null

sudo apt update

What each piece does:

mkdir -p /etc/apt/keyrings makes sure the folder for trusted keys exists
wget downloads the Jenkins signing key into it, so apt can verify the packages really come from the Jenkins project
echo ... | sudo tee writes a new repository entry that points at pkg.jenkins.io and says which key to check it against
apt update reads the new repository. In the output you can see pkg.jenkins.io/debian-stable being fetched

The key file name contains a year. If this step fails, check the official Jenkins installation page for the current key name.

Java version check, Jenkins signing key, repository entry and apt update

Step 10: Install Jenkins

sudo apt install jenkins -y

The output shows Jenkins 2.580.1 (about 53.9 MB) installing along with a small helper package called net-tools. At the very end, Ubuntu prints a message about a pending kernel upgrade and suggests a reboot. That is a notice, not an error. Jenkins installs and runs fine without the reboot.

Installing Jenkins with apt

Step 11: Start Jenkins and check it

sudo systemctl enable --now jenkins
sudo systemctl status jenkins

enable --now does two things at once: it starts Jenkins immediately and makes it start automatically every time the server boots. status shows the result. Look for the green active (running) line, and notice the Java process and the memory use (about 300 MB for me). Press q to leave the status view.

Enabling Jenkins and confirming active (running)

Jenkins is running. Time to open it in the browser.

Error 2: "This site can't be reached"

I took the server's public IP, added Jenkins' default port, and opened http://<your-public-ip>:8080 in Chrome.

Chrome showing ERR_CONNECTION_TIMED_OUT on port 8080

This site can't be reached. The server took too long to respond. ERR_CONNECTION_TIMED_OUT.

Reading the error properly

I had just seen Jenkins report active (running), so the service was fine. The clue is in the wording:

A connection refused error means the machine answered and said "nothing is listening on that port". That points at the service.
A timed out error means the packets never got an answer at all. Something in between silently dropped them. On AWS, that is almost always the security group.

When I created the instance, I only allowed port 22 (SSH) and port 80 (HTTP). Jenkins listens on 8080, and nothing allowed that port in.

The fix: open port 8080 in the security group

In the EC2 console, open Instances, select the server, and click the Security tab. Under Security groups, click the group's link (mine was launch-wizard-2).

Instances, Security tab and the security group link

On the security group page, the Inbound rules tab lists only two rules, HTTP and SSH. Click Edit inbound rules.

Inbound rules showing only HTTP and SSH, with Edit inbound rules

Click Add rule. A new row appears with the type already set to Custom TCP and the port at 0.

Edit inbound rules with the Add rule button

Set the port range to 8080 and the source to Anywhere-IPv4 (0.0.0.0/0). AWS warns again that this opens the port to everyone, which is fine for a lab and something to tighten later. Click Save rules.

Custom TCP rule for port 8080 from Anywhere-IPv4, then Save rules

Security group changes apply instantly. No restart, no reboot. I reloaded the browser tab and the error was gone.

Unlock Jenkins

Jenkins greeted me with Unlock Jenkins. The browser shows Not secure in the address bar because we are on plain HTTP and not HTTPS. That is expected for a quick lab, and I will come back to it at the end.

The Unlock Jenkins page at port 8080

The page says the first admin password lives in a file on the server. Back in the SSH session:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

You need sudo because only root can read that file.

Reading the initial admin password on the server

I copied the long string it printed, pasted it into the Administrator password box and clicked Continue.

Pasting the administrator password and clicking Continue

Next came Customize Jenkins, with two choices: Install suggested plugins (the safe default) or Select plugins to install. Jenkins 2.580.1 is up and answering on my server's public IP.

Customize Jenkins: install suggested plugins or select plugins

That is where I stopped for this post. From here Jenkins would install its plugins and ask you to create your first admin user. The goal of this lab was getting Jenkins running on a server I built myself, and that is done.

Cleanup: stop and terminate the server

This is the part people skip, and it is the part that costs money. In the EC2 dashboard, the Resources box shows exactly what is still alive: 1 running instance, 1 key pair, 3 security groups and 1 volume.

EC2 dashboard Resources box before cleanup

I selected the instance and opened the Instance state menu.

Selecting the instance and opening the Instance state menu

I stopped it first. The status moves to Stopping.

Instance stopping

Then I terminated it. Terminated means deleted for good, so the state ends at Terminated, as in the final screenshot. Both green banners are visible here: stopping and termination were both initiated.

Instance terminated

A difference worth remembering: stopped is not deleted. A stopped instance stops charging for compute, but its storage volume still exists and still bills. Terminate when you are done.

The key pair and security groups stay behind after termination. They are free, but delete them in the EC2 console if you will not reuse them, and delete the .pem from your computer too.

The two errors, side by side

	Where	What I saw	Real cause	Fix
1	S3, Make public	Failed to edit public access: Access denied on all 4 objects	Block Public Access was on, and it overrides ACLs. (ACLs were also disabled by default, which the console fixed for me.)	Permissions tab, Edit Block public access, untick, Save. Then Make public again
2	Jenkins in the browser	ERR_CONNECTION_TIMED_OUT on port 8080	The security group only allowed ports 22 and 80	Add an inbound Custom TCP rule for 8080

And three smaller things that look scarier than they are:

"Password has expired or requires a reset" at first IAM sign-in is the forced reset working as designed
"Pending kernel upgrade" after installing Jenkins is a reboot suggestion, not a failure
chmod 400 showing -r--r--r-- on Git Bash is a Windows quirk, and SSH was fine with it

What to would do differently during production

This lab was about learning the moves, so I took shortcuts that I would not take on anything real:

Stop using root. I worked as root all the way through, which is the exact habit Part 1 is meant to break.
Do not use 0.0.0.0/0 for SSH. Pick My IP so only my own address can reach port 22.
Restrict port 8080 too, and put Jenkins behind HTTPS with a reverse proxy before anyone enters a real password into it.
Keep S3 buckets private and serve public sites through CloudFront.
Set a billing alert first, before launching anything.
Use groups for permissions, not individual users.

Wrap up

Three services, three cleanups, two errors:

IAM taught me that new users start with almost no power, and that is a feature
S3 taught me that "Access denied" does not always mean your permissions, and that public access has more than one gate
EC2 taught me that a timeout and a refusal are different problems, and that the security group is the first place to look when a running service will not answer

Every one of the fixes took less than a minute once I understood the message. The hard part was reading the error properly, not fixing it.

Tried it yourself and ran into a different error? Drop the exact error message in the comments, and let’s troubleshoot it together! If this lab helped you, show some love, hit follow, and join me as I tackle new challenges and share real lessons from my cloud and DevOps journey, one lab at a time.

From “It Works on My Machine” to Azure: Deploying a Dockerized Notes App in 3 Ways, Breaking Things, Fixing Them, and Learning Along the Way

David Cletus — Thu, 01 Oct 2026 23:31:50 +0000

"It works on my machine" is a fine place to start. It's a terrible place to stop.

I built a small Notes app with Node.js, Express and PostgreSQL, put it in Docker, and then deployed that same container image in three different ways:

Localhost with Docker Compose
Azure App Service for Containers with Azure Database for PostgreSQL (managed PaaS)
An Azure Virtual Machine running Docker Compose (IaaS)

I also did a quick detour through Azure Container Instances (ACI) as a warm-up, because it taught me something useful.

Nothing went perfectly on the first try, and I left the errors in this post. They taught me more than the parts that worked.

Source code: GitHub repo
Docker image: 4thman/notes-app on Docker Hub

What we're building

A Notes app where you can add a note (title and content), see all notes sorted newest first, and delete notes. The notes live in PostgreSQL, so they need to survive restarts.

Layer	Technology
Frontend	Plain HTML/CSS/JS served as static files
Backend	Node.js 20 + Express
Database	PostgreSQL 16
Packaging	Docker + Docker Compose
Registry	Docker Hub
Cloud	Azure (ACI, App Service, PostgreSQL Flexible Server, VM)

The three deployments at a glance

	Localhost	App Service + managed Postgres	VM + Compose
Who manages the OS?	You	Azure	You
Who manages the database?	A container	Azure	A container on the VM
Public URL	`localhost:3000`	`*.azurewebsites.net` (HTTPS)	`VM-IP:3000`
Effort	Low	Medium (lots of settings)	Medium (lots of setup)
Best for	Development	Production-style apps	Full control, learning

What you need

Docker Desktop (with WSL on Windows)
Node.js and npm
VS Code with Git Bash
Azure CLI and an Azure subscription
A Docker Hub account
A GitHub account

Part 1: Build the app and run it locally

Project structure

I created the project folders from the terminal:

mkdir dockerapp-project
cd dockerapp-project
mkdir david-note
cd david-note
mkdir public
touch public/index.html Dockerfile server.js docker-compose.yaml

Creating the project folder and opening it in VS Code:

Creating the david-note and public folders and the index.html file:

Creating the Dockerfile and server.js:

You end up with this:

david-note/
├── public/
│   └── index.html
├── server.js
├── Dockerfile
└── docker-compose.yaml

The frontend

public/index.html is a single page with a form (title, content, an "Add Note" button) and a list of notes, each with a Delete link. It calls the backend API with fetch.

The backend (`server.js`)

The server does four things:

Connects to PostgreSQL using environment variables
Creates the notes table on startup if it doesn't exist
Exposes a small REST API
Serves the static frontend

The connection pool is the part that matters for deployment:

const { Pool } = require('pg');

const pool = new Pool({
  host: process.env.DB_HOST || 'db',
  port: Number(process.env.DB_PORT) || 5432,
  user: process.env.DB_USER || 'appuser',
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME || 'notesdb',
  ssl: process.env.DB_SSL === 'true' ? { rejectUnauthorized: false } : false,
});

Everything is configurable through environment variables. The same image can talk to a Postgres container on my laptop, a Postgres container on a VM, or Azure's managed Postgres, and I never rebuild it. The DB_SSL flag matters later, because Azure's managed Postgres requires encrypted connections.

On startup the app creates the table:

async function initDb() {
  await pool.query(`
    CREATE TABLE IF NOT EXISTS notes (
      id SERIAL PRIMARY KEY,
      title VARCHAR(255) NOT NULL,
      content TEXT,
      created_at TIMESTAMP DEFAULT NOW()
    );
  `);
}

The API has three routes:

GET /api/notes lists notes, newest first
POST /api/notes creates a note
DELETE /api/notes/:id deletes a note

There's also a health route:

app.get('/health', (req, res) => res.json({ status: 'ok' }));

I made a deliberate decision here. If the database connection fails at startup, the server logs the error and keeps running instead of crashing. A crash loop gives you nothing to debug. A running server that logs "Database initialization failed" and still answers /health tells you exactly where the problem is. That choice paid off during the Azure deployment.

server.js, part 1 (imports, connection pool, table creation, GET route):

server.js, part 2 (POST, DELETE, health check and startup):

The Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

The order matters. Copying package*.json first and running npm install before copying the rest of the code means Docker caches the dependency layer. If you only change server.js, rebuilds take seconds instead of reinstalling everything.

The Compose file

services:
  app:
    build: .
    image: 4thman/notes-app:V1
    ports:
      - "3000:3000"
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: appuser
      DB_PASSWORD: <your-local-password>
      DB_NAME: notesdb
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: <your-local-password>
      POSTGRES_DB: notesdb
    volumes:
      - db_data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  db_data:

Three details worth pointing out:

build: . and image: together. Compose builds the image from the local Dockerfile and tags it 4thman/notes-app:V1. That tag is what I push to Docker Hub later, so the image I tested locally is the image I deploy.
DB_HOST: db. Inside the Compose network, containers reach each other by service name.
The db_data volume. This is what keeps notes alive when containers are removed.

Creating the Compose file:

The Compose script in the editor:

Error #1: `Cannot find module 'pg'`

I ran npm init -y and npm install express to generate package.json:

Then I built and started everything:

docker compose up -d --build

The build succeeded and the containers started. But the app wasn't reachable. docker compose ps showed the app container as Restarting:

docker compose ps
docker compose logs app

The logs gave the reason:

Error: Cannot find module 'pg'
Require stack:
- /app/server.js

Cause: server.js requires the pg PostgreSQL driver, but I had only installed express. package.json didn't list pg, so RUN npm install inside the image never installed it.

Fix:

npm install express pg
docker compose up -d --build

The --build flag forces a rebuild so the image picks up the updated package.json. This time the app came up.

Lesson: the container only knows what's in package.json. If it works on your machine because of a global install, it will break in Docker. Also, docker compose logs <service> should be the first thing you reach for when a container keeps restarting.

Proving the data survives

At http://localhost:3000 the app loaded:

I added a note ("Hello" / "This is David test running the notes-app"), then typed a second one:

Then I tore everything down:

docker compose down

localhost:3000 now showed ERR_CONNECTION_REFUSED:

Then I brought it back:

docker compose up -d

Both notes were still there:

docker compose down removes containers and the network, but not named volumes, so Postgres picked up its data again. If I had run docker compose down -v, the notes would have been wiped.

Quick note: Compose printed a warning that the version attribute is obsolete. It's harmless, since modern Compose ignores it, but you can delete that line.

Part 2: Push the image to Docker Hub

Every cloud deployment below pulls the image from a registry, so this step connects local to cloud.

First, a .dockerignore so junk doesn't end up inside the image:

node_modules
.git
.env

Without it, COPY . . would copy your local node_modules into the image and overwrite the clean ones that npm install just built. It also keeps .env secrets out.

Then I logged in and confirmed the image existed:

docker compose down
docker login
docker image ls

And pushed it:

docker push 4thman/notes-app:V1

You might notice the push output says "Mounted from 4thman/hagital" for several layers. Those layers (the Node base image) were already in my account from a previous project, so Docker Hub didn't need them uploaded again. Only the new layers were pushed.

The repository now shows up at hub.docker.com/r/4thman/notes-app with the V1 tag.

Part 3 (the warm-up): Azure Container Instances

Before App Service, I tried the simplest Azure option: ACI runs containers with no VM or orchestrator to manage.

Register the resource providers

On a fresh subscription, services often fail until their resource provider is registered. I registered the ones I'd need up front:

az provider register --namespace Microsoft.ContainerInstance
az provider register --namespace Microsoft.DBforPostgreSQL
az provider register --namespace Microsoft.Web

az provider show --namespace Microsoft.Web --query registrationState --output tsv

The last command printed Registering and later Registered. Registration takes a minute or two, so check the state before moving on.

Variables and a resource group

To avoid retyping, I set shell variables:

DOCKER_USER="4thman"
SUFFIX="<your-unique-suffix>"
LOCATION="eastus"
DB_PASS="<a-strong-password>"

Checking that they were set:

echo $DOCKER_USER $SUFFIX $LOCATION

Then the resource group:

az group create --name notes-app-rg --location $LOCATION

provisioningState: Succeeded in the output confirmed the group existed.

The YAML deployment file

ACI can run several containers in one container group, and containers in a group share a network. That means the app can reach Postgres on localhost. I described the group in aci-notes.yaml:

apiVersion: 2021-10-01
location: eastus
name: notes-app-group
properties:
  containers:
    - name: app
      properties:
        image: 4thman/notes-app:V1
        command: ["/bin/sh", "-c", "sleep 20 && node server.js"]
        environmentVariables:
          - name: DB_HOST
            value: localhost
          - name: DB_PORT
            value: "5432"
          - name: DB_USER
            value: appuser
          - name: DB_PASSWORD
            secureValue: "<your-password>"
          - name: DB_NAME
            value: notesdb
        ports:
          - port: 3000
        resources:
          requests:
            cpu: 1.0
            memoryInGb: 1.0
    - name: db
      properties:
        image: postgres:16-alpine
        environmentVariables:
          - name: POSTGRES_USER
            value: appuser
          - name: POSTGRES_PASSWORD
            secureValue: "<your-password>"
          - name: POSTGRES_DB
            value: notesdb
        ports:
          - port: 5432
        resources:
          requests:
            cpu: 1.0
            memoryInGb: 1.0
  osType: Linux
  ipAddress:
    type: Public
    dnsNameLabel: notes-app-<your-suffix>
    ports:
      - protocol: tcp
        port: 3000
  restartPolicy: Always
type: Microsoft.ContainerInstance/containerGroups

The first half of the file (the app and db containers):

The second half (public IP, DNS label, port and restart policy):

Two things I want to explain:

sleep 20 && node server.js. ACI has no equivalent of Compose's depends_on. Both containers start at the same time, and Postgres needs a few seconds before it accepts connections. The delay gives the database time to be ready before the app tries to create its table.
secureValue instead of value for passwords, so they aren't shown in the container group's properties.

Deploy it:

az container create --resource-group notes-app-rg --file aci-notes.yaml

provisioningState: Succeeded came back:

Then I grabbed the address:

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

And checked the logs:

az container logs \
  --resource-group notes-app-rg \
  --name notes-app-group \
  --container-name app

The logs showed exactly what I wanted:

Notes app running on port 3000
Database initialized (notes table ready)

I opened http://notes-app-<suffix>.eastus.azurecontainer.io:3000:

Then I added a few notes to test it, and they were saved:

Why I moved on

ACI is great for quick demos, but this setup has no volume for Postgres. If the group restarts, the database starts empty. Also, a database in a container is the wrong model for anything you care about. So I deleted it:

az container delete --resource-group notes-app-rg --name notes-app-group --yes

Reloading the URL now gave DNS_PROBE_FINISHED_NXDOMAIN, which confirms the DNS name went away with the container:

Then I removed the whole resource group and created a fresh one for the next attempt:

az group delete --name notes-app-rg --yes --no-wait
az group create --name notes-prod-rg --location $LOCATION

Part 4: Azure App Service + Azure Database for PostgreSQL

This is the "proper" cloud setup. Azure runs the database and the web hosting, and I only supply the image and the configuration.

Step 1: Create the managed PostgreSQL server

az postgres flexible-server create \
  --resource-group notes-prod-rg \
  --name notes-db-$SUFFIX \
  --location eastus2 \
  --admin-user appuser \
  --admin-password "$DB_PASS" \
  --sku-name Standard_B1ms \
  --tier Burstable \
  --version 16 \
  --public-access 0.0.0.0 \
  --yes

What those flags mean:

Standard_B1ms and Burstable is the cheap tier, fine for a demo.
--public-access 0.0.0.0 creates a firewall rule that allows connections from other Azure services. That's how App Service will reach the database.
--version 16 matches the Postgres version I used locally.

The CLI also warns that the output includes your password in plain text. Treat that output as sensitive and never paste it into a blog post.

Then I created the application database:

az postgres flexible-server db create \
  --resource-group notes-prod-rg \
  --server-name notes-db-$SUFFIX \
  --name notesdb

And captured the server address:

DB_HOST=$(az postgres flexible-server show \
  --resource-group notes-prod-rg \
  --name notes-db-$SUFFIX \
  --query fullyQualifiedDomainName --output tsv)

echo $DB_HOST

The server showed state Ready with a host like notes-db-<suffix>.postgres.database.azure.com.

Step 2: Create the App Service plan

Error #2: free-tier quota in East US

az appservice plan create \
  --name notes-app-plan \
  --resource-group notes-prod-rg \
  --is-linux --sku F1 --location eastus

This failed:

Current Limit (F1 VMs): 0
Amount required for this deployment (F1 VMs): 1

Cause: my subscription had zero free-tier (F1) capacity in East US.

Fix: I tried another region instead of fighting for a quota increase:

az appservice plan create \
  --name notes-app-plan \
  --resource-group notes-prod-rg \
  --is-linux --sku F1 --location centralus

That worked (provisioningState: Succeeded). The trade-off is that my app (Central US) and database (East US 2) are now in different regions, which adds a little latency. For production, you'd want them in the same region.

Step 3: Create the web app from the Docker Hub image

az webapp create \
  --resource-group notes-prod-rg \
  --plan notes-app-plan \
  --name notes-app-$SUFFIX \
  --deployment-container-image-name 4thman/notes-app:V1

The CLI warned me that --deployment-container-image-name is deprecated and will be removed in a future release, so check az webapp create --help for the current flag name.

Step 4: Configure the app

The container reads its database settings from environment variables, so I set them as App Service application settings:

az webapp config appsettings set \
  --resource-group notes-prod-rg \
  --name notes-app-$SUFFIX \
  --settings \
    DB_HOST="$DB_HOST" \
    DB_PORT="5432" \
    DB_USER="appuser" \
    DB_PASSWORD="$DB_PASS" \
    DB_NAME="notesdb" \
    DB_SSL="true" \
    PGSSLMODE="require" \
    WEBSITES_PORT="3000"

Three of these settings matter more than they look:

DB_SSL=true turns on the SSL option in my pg pool. Azure's managed Postgres rejects unencrypted connections.
WEBSITES_PORT=3000 tells App Service which port my container listens on. Without it, App Service assumes port 80 and can't find the app.
DB_HOST is now the managed server's full address instead of db.

)

Then I restarted the app:

az webapp restart --resource-group notes-prod-rg --name notes-app-$SUFFIX

And printed the site URL to open it:

Error #3: 503 Service Unavailable

I opened https://notes-app-<suffix>.azurewebsites.net and got:

503 Service Unavailable

This is where I did some actual debugging.

First suspect: the database firewall. I added an explicit rule allowing Azure services and restarted:

az postgres flexible-server firewall-rule create \
  --resource-group notes-prod-rg \
  --server-name notes-db-$SUFFIX \
  --name AllowAllAzureIPs \
  --start-ip-address 0.0.0.0 \
  --end-ip-address 0.0.0.0

az webapp restart --resource-group notes-prod-rg --name notes-app-$SUFFIX
az webapp start --resource-group notes-prod-rg --name notes-app-$SUFFIX

Looking back, this rule was redundant. The --public-access 0.0.0.0 flag at server creation had already created an equivalent one. Still, ruling out the firewall was worth the minute it took.

Second suspect: the app's actual state. Instead of guessing, I asked Azure:

az webapp show \
  --resource-group notes-prod-rg \
  --name notes-app-$SUFFIX \
  --query "state"

The answer was:

"QuotaExceeded"

Cause: the Free (F1) tier has a daily compute quota. The app had used it up, and Azure stopped it. The 503 was only a symptom.

Fix: move the plan up one tier:

az appservice plan update \
  --name notes-app-plan \
  --resource-group notes-prod-rg \
  --sku B1

B1 is a paid tier with no daily CPU quota. For a free-tier demo, remember that F1 can quietly stop your app.

The firewall rule, the restart and start attempts, the QuotaExceeded state and the plan upgrade:

Along the way the browser showed a different message, because Azure had stopped the app:

Error 403 - This web app is stopped.

Step 5: Re-point the container and restart

With the plan upgraded, I re-applied the container configuration explicitly, pointing at the exact image tag, and restarted:

az webapp config container set \
  --resource-group notes-prod-rg \
  --name notes-app-$SUFFIX \
  --docker-custom-image-name 4thman/notes-app:V1

az webapp restart --resource-group notes-prod-rg --name notes-app-$SUFFIX

Note the tag: V1 with a capital V. Docker tags are case-sensitive, and some of my earlier commands used lowercase v1 while the tag I actually pushed is V1. I corrected these as I went, but it's a classic way to get "image not found" errors, so copy the tag exactly.

This time the site came up on https://notes-app-<suffix>.azurewebsites.net, with HTTPS provided by Azure for free:

I added a note ("my name" / "My name is David"), refreshed, and it persisted in Azure Database for PostgreSQL:

Cleanup

az group delete --name notes-prod-rg --yes --no-wait

Deleting the resource group removes the plan, web app and database together, so nothing keeps billing.

Part 5: Azure Virtual Machine + Docker Compose

The third approach gives you the most control and the most responsibility. It's just a Linux server, and I install everything myself.

Create the VM

az group create --name notes-vm-rg --location eastus

az vm create \
  --resource-group notes-vm-rg \
  --name notes-vm \
  --image Ubuntu2204 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --size Standard_B1s

--generate-ssh-keys creates an SSH key pair, so there's no password login to worry about. The output shows the VM running with a private and public IP.

Open port 3000

A new VM blocks inbound traffic by default. The app listens on 3000, so I opened that port in the network security group:

az vm open-port \
  --resource-group notes-vm-rg \
  --name notes-vm \
  --port 3000

The output lists a new inbound rule called open-port-3000 that allows TCP traffic to port 3000.

Connect with SSH

VM_IP=$(az vm show \
  --resource-group notes-vm-rg \
  --name notes-vm \
  --show-details \
  --query publicIps --output tsv)

ssh azureuser@$VM_IP

The prompt changed to azureuser@notes-vm:~$, which means I was now inside the VM.

Install Docker

I followed Docker's official apt repository instructions. First, update the package index:

sudo apt-get update

Then the prerequisites:

sudo apt-get install -y ca-certificates curl gnupg

Next, Docker's signing key and repository:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

The key lets apt verify that packages are genuine, and the echo adds Docker's repository to apt's sources.

Finally, install the engine, the CLI, containerd and the Compose plugin:

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

Error #4: Docker permission denied (the group problem)

By default only root can talk to the Docker daemon, which means every command needs sudo. The fix is adding your user to the docker group:

sudo usermod -aG docker $USER
newgrp docker

Group changes normally apply on your next login. newgrp docker applies it to the current shell immediately, so you don't have to log out and back in. Then I verified everything:

docker --version          # Docker version 29.8.2
docker compose version    # Docker Compose version v5.5.1
docker ps                 # empty list, no permission errors

Deploy with Compose

On the VM I created a folder and a Compose file that pulls my image from Docker Hub, with no build step needed:

mkdir notes-app && cd notes-app
nano docker-compose.yml

services:
  app:
    image: 4thman/notes-app:V1
    command: sh -c "sleep 15 && node server.js"
    ports:
      - "3000:3000"
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: appuser
      DB_PASSWORD: <your-password>
      DB_NAME: notesdb
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: <your-password>
      POSTGRES_DB: notesdb
    volumes:
      - db_data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  db_data:

Notice the VM runs its own Postgres container, not Azure's managed database. The extra sleep 15 gives Postgres time to initialise on first start, since depends_on only waits for the container to start, not for the database to be ready.

Then:

docker compose up -d
docker compose ps

Compose pulled both images (postgres:16-alpine and 4thman/notes-app:V1), created the network and volume, and started both containers. docker compose ps showed the app mapped to 0.0.0.0:3000->3000/tcp.

I opened http://<VM-IP>:3000 and there was the Notes app, running on a server I had built from scratch. I filled in a note titled "hello from the vm" to try it out.

Cleanup

az group delete --name notes-vm-rg --yes --no-wait
az group list --output table

While the group showed Deleting, I also noticed a NetworkWatcherRG group that Azure creates automatically when you build networks. I deleted that too and re-listed groups until both were gone:

az group delete --name NetworkWatcherRG --yes --no-wait

Pushing the project to GitHub

Finally, I put everything under version control. I created a .gitignore, initialised the repository and made the first commit:

touch .gitignore
git init
git add .
git commit -m "saving the files for the first time"
git branch main
git switch main

Then I created an empty repository on GitHub:

And connected and pushed:

git remote add origin https://github.com/4thman/4thman-dockerised-notes-web-application.git
git push -u origin main

Errors at a glance

#	What I saw	Cause	Fix
1	Container restarting, `Cannot find module 'pg'`	Driver missing from `package.json`	`npm install express pg`, then `docker compose up -d --build`
2	F1 quota limit 0 in East US	No free-tier capacity in that region	Created the plan in Central US
3	`503 Service Unavailable`	App had been stopped (`QuotaExceeded` on the F1 tier)	Upgraded the plan to B1, re-set the container, restarted
4	Docker commands need `sudo`	User not in the `docker` group	`sudo usermod -aG docker $USER` and `newgrp docker`
5	Risk of "image not found"	Tag case mismatch (`v1` vs `V1`)	Used the exact tag `V1` everywhere
6	App crashing before the DB was ready	Containers start at the same time	`sleep` before `node server.js` (ACI and VM)

What learned

Configuration through environment variables is the whole game. One image ran in three environments because nothing environment-specific was baked into it.
Read the logs before you change anything. docker compose logs, az container logs and az webapp show --query state each pointed straight at the problem.
A symptom isn't a cause. The 503 looked like a database or networking issue. It was a billing-tier quota.
Managed services save work but add settings. App Service handled HTTPS and the OS, but I had to learn about WEBSITES_PORT, SSL and plan tiers.
VMs give control and take your time. Docker installation, permissions, firewall rules and updates were all mine to handle.
Clean up after yourself. Deleting resource groups is the easiest way to avoid surprise bills.

Your Turn

That’s where I’ll leave this one.

I started with a Notes app running on my machine and ended up deploying the same Docker image through ACI, Azure App Service with managed PostgreSQL, and an Azure VM. Along the way, I broke things, read the logs, fixed them, and learned something new from every failure.

Try it yourself

Code: github.com/4thman/4thman-dockerised-notes-web-application
Image: docker pull 4thman/notes-app:V1 (Docker Hub)

Hit one of these errors while deploying your own Docker app? Or did you find a smarter fix that I missed? Drop your experience, workaround, or “I’ve been there” story in the comments. I’d love to compare notes and learn from you.

Make sure you kindly, give it a like, share it with someone learning Docker or Azure, and let me know what you’d like to see me build or break next.

Until the next deployment, keep building, keep testing, and don’t be afraid of the errors. They’re often where the real learning happens.

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

DEV Community: David Cletus

Hands-On AWS: Spin Up IAM, S3 and a Jenkins Server on EC2 (and Fix What Breaks)

A step-by-step AWS lab with lots screenshots: create and delete an IAM user, host a site on S3, launch an EC2 server and run Jenkins on it, including the two errors I hit and how I fixed them.

The plan

Before you start

Part 1: IAM, deciding who gets to do what

Why I did not just keep using root

Step 1: Open IAM

Step 2: Create the user

Step 3: Fill in the user details

Step 4: Permissions

Step 5: Review and create

Step 6: Save the sign-in details

Step 7: Sign in as the new user

Step 8: Delete the user

Part 2: S3, storing files and serving a website

What S3 actually is

Step 1: Find S3 and create a bucket

Step 2: Name the bucket

Step 3: Leave the safe defaults alone

Step 4: Upload the CV website

Error 1: "Access denied" when making the files public

Reading the error properly

The fix

See it live

Cleanup: empty the bucket, then delete it

Part 3: EC2, a server in the cloud, running Jenkins

The vocabulary you need first

Step 1: Launch the wizard

Step 2: Name it and pick an image

Step 3: Instance type and key pair

Step 4: Network and security group

Step 5: Review and launch

Step 6: Lock down the key file and connect over SSH

Step 7: Update the server

Step 8: Install Java

Step 9: Add the Jenkins repository

Step 10: Install Jenkins

Step 11: Start Jenkins and check it

Error 2: "This site can't be reached"

Reading the error properly

The fix: open port 8080 in the security group

Unlock Jenkins

Cleanup: stop and terminate the server

The two errors, side by side

What to would do differently during production

Wrap up

From “It Works on My Machine” to Azure: Deploying a Dockerized Notes App in 3 Ways, Breaking Things, Fixing Them, and Learning Along the Way

What we're building

The three deployments at a glance

What you need

Part 1: Build the app and run it locally

Project structure

The frontend

The backend (server.js)

The Dockerfile

The Compose file

Error #1: Cannot find module 'pg'

Proving the data survives

Part 2: Push the image to Docker Hub

Part 3 (the warm-up): Azure Container Instances

Register the resource providers

Variables and a resource group

The YAML deployment file

Why I moved on

Part 4: Azure App Service + Azure Database for PostgreSQL

Step 1: Create the managed PostgreSQL server

Step 2: Create the App Service plan

Error #2: free-tier quota in East US

Step 3: Create the web app from the Docker Hub image

Step 4: Configure the app

Error #3: 503 Service Unavailable

Step 5: Re-point the container and restart

Cleanup

Part 5: Azure Virtual Machine + Docker Compose

Create the VM

Open port 3000

Connect with SSH

Install Docker

Error #4: Docker permission denied (the group problem)

The backend (`server.js`)

Error #1: `Cannot find module 'pg'`