Forem: Miracle Olorunsola

How I Took a Broken Microservices App to Production with Docker & CI/CD

Miracle Olorunsola — Thu, 30 Apr 2026 13:00:00 +0000

The Challenge

I was given a multi-service application with:

A Node.js frontend
A FastAPI backend
A Python worker
Redis as a queue

The catch?

It was intentionally broken.

My task wasn’t to build it was to:

Fix it
Containerize it
Ship it with a full CI/CD pipeline

Step 1: Debugging the System
Before touching Docker, I read the entire codebase.

Issues I found:
Hardcoded localhost breaking container networking
Missing environment variables
Redis connection failures
API crashing on startup
Frontend calling wrong endpoints

Fix approach:

Replaced hardcoded values with env variables
Standardized service communication (api, redis)
Added proper error handling

Step 2: Containerization

Each service got its own Dockerfile.

Key decisions:

Used python:3.11-alpine for minimal size
Created non-root users (appuser)
Added HEALTHCHECK to every service
Avoided copying .env files into images

Step 3: Docker Compose Setup

This was where things got interesting.

What I implemented:

Internal bridge network
Redis hidden from host
depends_on with health conditions
Resource limits for all containers

depends_on:
  redis:
    condition: service_healthy

Step 4: CI/CD Pipeline

I built a GitHub Actions pipeline with strict stages:

- Lint
flake8 (Python)
eslint (Node)
hadolint (Docker)
Test
pytest with mocked Redis
coverage report upload

- Build
Tagged images with SHA + latest
Pushed to local registry

- Security Scan
Trivy scan
Fail on CRITICAL vulnerabilities

- Integration Test
Spin up full stack
Submit job → poll → verify completion

- Deploy
Rolling update
Health check gating
Automatic rollback on failure

Challenges I Faced

Docker daemon not running (blocked everything)
ESLint breaking due to Node version mismatch
Trivy failing due to missing images
Race conditions between services
Containers “starting” but not “ready”

Key Takeaways

Health checks > startup order
Containers must be self-sufficient
CI/CD pipelines should fail fast DevOps is about system thinking, not just tools

Repo

How I Built a Real-Time DDoS Detection Engine with Python, Docker, and iptablesTags: devops, python, security, docker

Miracle Olorunsola — Wed, 29 Apr 2026 01:15:42 +0000

How I Built a Real-Time DDoS Detection Engine with Python, Docker, and iptables

Have you ever wondered how websites protect themselves from attackers
who send millions of requests trying to crash the server? That is called
a DDoS attack (Distributed Denial of Service), and in this post I will
show you how I built a system that detects and blocks these attacks
automatically — in real time.

This project was built as part of the HNG DevOps Stage 3 task. We were
asked to protect a Nextcloud cloud storage platform running on Docker
from suspicious traffic — without using any existing security tools like
Fail2Ban. Everything had to be built from scratch.

What the Project Does and Why It Matters

Imagine you run a shop. Normally 10 customers walk in per minute.
Suddenly 5,000 people rush in at the same time — not to buy anything,
but just to block the door so real customers cannot enter. That is
exactly what a DDoS attack does to a web server.

Our detection engine:

Watches every HTTP request coming into the server in real time
Learns what "normal" traffic looks like
Detects when traffic suddenly spikes far above normal
Automatically blocks the attacking IP address
Sends an alert to Slack so you know what happened
Automatically unblocks the IP after a set time

The system runs as a background daemon meaning it runs continuously
24/7 alongside your application, always watching.

The Architecture

Here is how all the pieces fit together:

Internet Traffic
↓
Nginx (reverse proxy)
↓ writes JSON logs
Shared Docker Volume (HNG-nginx-logs)
↓ reads logs
Detection Daemon (Python)
↓ ↓ ↓
iptables Slack Dashboard
(block IP) (alert) (metrics UI)

We use Docker Compose to run everything together:

MariaDB — database for Nextcloud
Nextcloud — the cloud storage application
Nginx — reverse proxy that logs all traffic in JSON format
Detector — our Python daemon that watches the logs

How the Sliding Window Works

This is the heart of the detection system. We need to know how many
requests came from each IP address in the last 60 seconds at any
given moment.

The naive approach would be to count requests per minute. But that has
a problem — if someone sends 1000 requests at 11:59 and 1000 more at
12:00, a per-minute counter would show two separate spikes of 1000
instead of the real burst of 2000.

We solve this with a sliding window using Python's deque
(double-ended queue):

from collections import deque
import time

# One deque per IP address
ip_window = deque()
WINDOW_SECONDS = 60

def record_request(ip_window, timestamp):
    now = timestamp
    cutoff = now - WINDOW_SECONDS

    # Step 1: Add the new request timestamp
    ip_window.append(now)

    # Step 2: Remove requests older than 60 seconds
    # popleft() removes from the left — O(1) operation
    while ip_window and ip_window[0] < cutoff:
        ip_window.popleft()

    # Step 3: Count = requests in last 60 seconds
    current_rate = len(ip_window)
    return current_rate

A deque is like a list but optimized for adding to one end and
removing from the other. This makes the eviction of old entries very
fast — O(1) — no matter how many requests are in the window.

We maintain two windows:

One per IP address — to detect a single aggressive attacker
One global — to detect a coordinated attack from many IPs

How the Baseline Learns from Traffic

We cannot hardcode a threshold like "100 requests per second is too
many." Maybe your server normally gets 500 per second at peak hours,
or just 5 per second at 3 AM. A hardcoded value would cause false
alarms constantly.

Instead we use a rolling baseline — the system learns what normal
looks like from recent traffic history.

Every second we record how many requests arrived:

from collections import deque
import math

# Keep 30 minutes of per-second counts
# 30 minutes × 60 seconds = 1800 slots
per_second_counts = deque(maxlen=1800)

# Every second:
per_second_counts.append(requests_this_second)

# Every 60 seconds, recalculate mean and stddev:
def recalculate_baseline(counts):
    n = len(counts)
    if n < 2:
        return 1.0, 0.5  # floor values

    mean = sum(counts) / n
    variance = sum((c - mean)**2 for c in counts) / (n - 1)
    stddev = math.sqrt(variance)

    # Apply floors to prevent divide-by-zero
    mean = max(mean, 1.0)
    stddev = max(stddev, 0.5)

    return mean, stddev

We also maintain per-hour slots. If the current hour has at least
10 minutes of data, we prefer its statistics over the global 30-minute
window. This means:

At 9 AM (busy hour): baseline reflects busy traffic → higher threshold
At 3 AM (quiet hour): baseline reflects quiet traffic → lower threshold

The system is always comparing current traffic to recent traffic,
not some fixed value set months ago.

How the Detection Logic Makes a Decision

Once we have the current rate and the baseline, we check two conditions.
Whichever fires first triggers an alert:

def check_anomaly(rate, mean, stddev):
    # Condition 1: Rate multiplier
    # Is traffic more than 5x the normal average?
    if rate > 5.0 * mean:
        return f"rate>5x_mean({rate}>{5.0 * mean:.1f})"

    # Condition 2: Z-score
    # How many standard deviations above normal is this?
    z_score = (rate - mean) / stddev
    if z_score > 3.0:
        return f"zscore>3.0(z={z_score:.2f})"

    return None  # Normal traffic

Z-score measures how unusual something is statistically. A z-score
of 3.0 means the current rate is 3 standard deviations above the mean
— this happens by random chance less than 0.3% of the time. In other
words, it is almost certainly an attack.

We also have error surge detection. If an IP generates lots of
4xx/5xx errors (like failed login attempts), we tighten the thresholds
automatically — making the system more sensitive to that specific IP.

How iptables Blocks an IP

iptables is a firewall built into Linux. When we detect an attack from
a specific IP, we add a DROP rule that tells the Linux kernel to silently
discard all packets from that IP before they even reach Nginx:

import subprocess

def ban_ip(ip_address):
    # Insert DROP rule at the TOP of the INPUT chain
    # -I means insert (top priority)
    # -s means source IP
    # -j DROP means silently discard the packet
    cmd = ["iptables", "-I", "INPUT", "-s", ip_address, "-j", "DROP"]
    subprocess.run(cmd)
    print(f"Banned: {ip_address}")

def unban_ip(ip_address):
    # -D means delete the rule
    cmd = ["iptables", "-D", "INPUT", "-s", ip_address, "-j", "DROP"]
    subprocess.run(cmd)
    print(f"Unbanned: {ip_address}")

The ban happens within 10 seconds of detection. The attacker's
connection is simply dropped at the operating system level — they get
no response at all, which is more efficient than sending error messages.

Auto-unban backoff schedule:

1st offence → banned for 10 minutes
2nd offence → banned for 30 minutes
3rd offence → banned for 2 hours
4th offence → permanently banned

Slack Alerts

Every significant event sends a notification to a Slack channel:

import requests

def send_slack_alert(webhook_url, ip, rate, mean, stddev, condition):
    message = {
        "attachments": [{
            "color": "#FF3B30",
            "text": (
                f":rotating_light: *IP BAN TRIGGERED*\n"
                f">*IP:* `{ip}`\n"
                f">*Condition:* `{condition}`\n"
                f">*Current rate:* {rate} req/60s\n"
                f">*Baseline:* mean={mean:.2f} stddev={stddev:.2f}\n"
            )
        }]
    }
    requests.post(webhook_url, json=message)

We get alerts for:

🚨 IP banned (with condition, rate, baseline, duration)
🔓 IP unbanned (with ban history)
⚠️ Global traffic anomaly (when the whole site is under attack)

The Live Dashboard

We built a web dashboard using Flask that refreshes every 3 seconds
showing:

Currently banned IPs and time remaining
Global requests per second
Top 10 source IPs
CPU and memory usage
Current baseline mean and standard deviation
System uptime
Baseline history graph

The Audit Log

What I Learned

Building this from scratch taught me:

Statistics matter in security — z-scores and standard deviation
are not just academic concepts. They are practical tools for anomaly
detection.
Adaptive baselines beat fixed thresholds — a system that learns
is far more accurate than one with hardcoded values.
Docker networking is complex — getting containers to communicate
correctly took more troubleshooting than the detection logic itself.
iptables is powerful — blocking at the kernel level is the most
efficient way to stop an attack. The attacker gets no response,
wasting their resources.
Always whitelist your own IP — learned this the hard way when
I locked myself out of my own server!

The Stack

Python 3.12 — detection daemon
Flask — dashboard web server
Docker + Docker Compose — container orchestration
Nginx — reverse proxy with JSON logging
MariaDB — database for Nextcloud
Nextcloud — the application being protected
iptables — IP blocking at kernel level
Slack — alert notifications

Repository

The full source code is available at:
https://github.com/Techgirli/ddos-detector

Conclusion

Building a security tool from scratch is one of the best ways to
understand how attacks work and how defenses are designed. Every piece
of this system — the sliding window, the adaptive baseline, the
statistical detection, the automatic blocking — solves a real problem
that security engineers face every day.

If you have questions or want to build something similar, drop a comment
below!

From Zero to Production: My HNG DevOps Stage 0 Journey

Miracle Olorunsola — Mon, 20 Apr 2026 12:00:00 +0000

I just completed a hands-on Linux server setup and deployment no Docker, no automation, just raw DevOps fundamentals.

Here’s exactly how I approached it:

Server Provisioning & Access
Spun up a Linux server on the cloud Connected via SSH using key-based authentication Created a secure non-root user: hngdevops Granted sudo privileges
Security Hardening
Disabled root SSH login Disabled password authentication (keys only) Configured Uncomplicated Firewall: Allowed only ports 22 (SSH), 80 (HTTP), 443 (HTTPS) Blocked everything else
Web Server Setup
Installed and started Nginx

Configured routes:
/ → Static HTML page displaying my HNG username
/api → JSON response:
{
"message": "HNGI14 Stage 1",
"track": "DevOps",
"username": "my-username"
}

SSL Configuration Used Certbot to generate a valid SSL certificate Enabled HTTPS on the server Configured HTTP → HTTPS redirect (301)

5.** Validation & Debugging**

Ensured:
/api returns HTTP 200 with Content-Type: application/json
Username matches exactly (case-sensitive)
SSL is valid (no self-signed certificates)
Firewall and Nginx are active and correctly configured

Key Lessons
Most failures aren’t tools they’re mis-configurations (ports, services, permissions) “Connection refused” vs “Timeout” tells you exactly where the issue is Security first: lock down access before exposing your server


Live Demo

* Deployed and accessible over HTTPS 
This project sharpened my troubleshooting, Linux, and networking skills exactly what real-world DevOps demands.
hashtag#DevOps hashtag#Linux hashtag#Nginx hashtag#CyberSecurity hashtag#Cloud hashtag#LetsEncrypt hashtag#HNG hashtag#TechJourney

HNG Stage 1 DevOps Task Completed — From Infrastructure to API Deployment

Miracle Olorunsola — Mon, 20 Apr 2026 12:00:00 +0000

After successfully setting up a Linux server and configuring Nginx in Stage 0, I took things further in Stage 1 by building and deploying a minimal backend API — focusing not just on development, but on how services run in production.

What I Built
A lightweight API with 3 endpoints:

/ → Confirms the API is running
/health → Health check endpoint
/me → Returns my profile details

All endpoints:
✔ Return JSON (application/json)
✔ Respond with HTTP 200
✔ Optimized for <500ms response time

Deployment Approach

Provisioned a cloud VPS
Ran the app on a non-public port (security best practice)
Configured Nginx as a reverse proxy to handle public traffic
Ensured high availability using a persistent service (systemd)

Key Learning
As a DevOps engineer, deploying isn’t just about infrastructure — it’s about understanding the application lifecycle, performance, and reliability from the inside out.

Live API: http://my-live-domain-or-ip
GitHub Repo: https://github.com/Techgirli

This project strengthened my skills in:

Linux server management
Reverse proxy configuration with Nginx
Service reliability & process management
API structure and performance optimization

On to the next stage

DevOps #HNGInternship #Backend #Nginx #Linux #CloudComputing #APIs

These are some Images from the App.

Miracle Olorunsola — Thu, 09 Apr 2026 12:00:00 +0000

GitHub Repository:

Innovators-UmojaAgri-Org / UmojaAgri-Org

UmojaAgri-Org

UmojaAgri 🌾

AI-Driven Agricultural Logistics Platform

A logistics intelligence platform that helps farmers and transporters monitor produce freshness, predict delivery delays, and reduce post-harvest losses using rule-based AI With the collaboration of the twam we could bring the mobile app to life.

Project Overview

UmojaAgri is an MVP designed to address a major challenge in African agriculture: food spoilage due to unpredictable transportation.

The platform calculates a Freshness Window — a real-time countdown that determines whether produce will arrive at its destination before spoilage risk becomes critical.

It combines logistics tracking, rule-based intelligence, and supply-chain visibility into a single system.

Problem Statement

A significant percentage of agricultural produce in Africa spoils before reaching markets due to:

Poor road conditions
Unpredictable travel times
Lack of real-time freshness tracking
Inefficient logistics coordination

UmojaAgri provides predictive insights so farmers and transporters can make smarter decisions and reduce waste.

Core Features

Produce

…

View on GitHub

Live Demo (Render):
Farmers Dashboard:

umojaagri-org-1.onrender.com

Marketer Dashboard:

umojaagri-org-1.onrender.com

Transporter Dashboard:

umojaagri-org

The Slides on the information UmojaAgri

Miracle Olorunsola — Tue, 07 Apr 2026 12:00:00 +0000

If you’d like to explore UmojaAgri 🌱 in action:
Check out more information

canva.com

You can Explore the app

Miracle Olorunsola — Mon, 06 Apr 2026 13:00:00 +0000

If you’d like to explore UmojaAgri 🌱 in action:
GitHub Repository:

Innovators-UmojaAgri-Org / UmojaAgri-Org

UmojaAgri-Org

UmojaAgri 🌾

AI-Driven Agricultural Logistics Platform

A logistics intelligence platform that helps farmers and transporters monitor produce freshness, predict delivery delays, and reduce post-harvest losses using rule-based AI With the collaboration of the twam we could bring the mobile app to life.

Project Overview

UmojaAgri is an MVP designed to address a major challenge in African agriculture: food spoilage due to unpredictable transportation.

The platform calculates a Freshness Window — a real-time countdown that determines whether produce will arrive at its destination before spoilage risk becomes critical.

It combines logistics tracking, rule-based intelligence, and supply-chain visibility into a single system.

Problem Statement

A significant percentage of agricultural produce in Africa spoils before reaching markets due to:

Poor road conditions
Unpredictable travel times
Lack of real-time freshness tracking
Inefficient logistics coordination

UmojaAgri provides predictive insights so farmers and transporters can make smarter decisions and reduce waste.

Core Features

Produce

…

View on GitHub

Live Demo (Render):
Farmers Dashboard:

umojaagri-org-1.onrender.com

Marketer Dashboard:

umojaagri-org-1.onrender.com

Transporter Dashboard:

umojaagri-org

Project Structure Highlights:
/frontend → Flutter application
/backend → Supabase integration & services
/nginx → Reverse proxy configuration
.github/workflows → CI/CD automation

What this project demonstrates:
Full-stack collaboration (Flutter + Supabase + PostgreSQL)
DevOps pipeline design using GitHub Actions
Cloud deployment and management via Render
Real-world debugging and system optimization

Results:
Faster deployment cycles
Improved reliability through automation
Clean and scalable project structure

Future Improvements:
Container orchestration using Kubernetes
Monitoring & observability with Prometheus + Grafana
Centralized logging and alerting
Scaling into microservices architecture
I’m actively seeking DevOps / Cloud Engineering roles where I can contribute to building scalable, production-ready systems.
Let’s connect
hashtag#DevOpsEngineer hashtag#CloudEngineering hashtag#Kubernetes hashtag#Prometheus hashtag#Grafana hashtag#GitHub hashtag#Portfolio hashtag#OpenToWork
umoja_agri
umojaagri-org-1.onrender.com

Here’s how we structured and deployed UmojaAgri 🌱 from a DevOps perspective. Architecture Overview:

Miracle Olorunsola — Fri, 03 Apr 2026 12:00:00 +0000

Here’s how we structured and deployed UmojaAgri 🌱 from a DevOps perspective.
Architecture Overview:
Flutter (Frontend) → API layer (Supabase) → PostgreSQL database
Nginx acting as a reverse proxy (where applicable)
Application services deployed via Render
CI/CD handled with GitHub Actions

Infrastructure Stack:
Hosting: Render
Backend Services: Supabase
Database: PostgreSQL
CI/CD: GitHub Actions
Containerization: Docker
Server Config: Nginx
CI/CD Workflow:
Code pushed to GitHub
GitHub Actions triggers build & checks
Updates deployed to Render
Backend services sync via Supabase

System Improvements:
Faster and consistent deployments
Simplified rollback via version control
Reduced human error through automation
DevOps Principles Applied:
Automation-first workflows
Service separation (frontend, backend, database)
Scalable and maintainable architecture

Next: GitHub repo + live demo + future upgrades 👇
hashtag#DevOps hashtag#SystemDesign hashtag#Cloud hashtag#Supabase hashtag#PostgreSQL hashtag#Render hashtag#Infrastructure

Back
Dialog content end.
Miracle OlorunsolaStatus is online
MessagingYou are on the messaging overlay. Press enter to open the list of conversations.

Compose message
You are on the messaging overlay. Press enter to open the list of conversations.

Created and Deployed an Agri-Tech

Miracle Olorunsola — Thu, 02 Apr 2026 12:00:00 +0000

I recently joined a team of amazing women to build a mobile app called UmojaAgri Santana Jepchumba Blen Redwan Michelle Fayeun Blessing Omonye Abanonkhua Nkechika Collins Akpe Rotimi Amusa

I deployed UmojaAgri 🌱 an AgriTech platform focused on improving how farmers access tools, insights, and resources.

But beyond development, I approached this project with a DevOps and production-first mindset.

What I implemented:

Containerization using Docker

Automated CI/CD pipelines with GitHub Actions

Reverse proxy configuration using Nginx

Cloud deployment using Render

Debugging real-world deployment issues (including “Cannot GET /”)

Performance & Impact:

Deployment time reduced by ~60% using CI/CD automation

Average response time improved through optimized server routing

Achieved stable uptime during testing and deployment phases

Key takeaway:

This wasn’t just about building features it was about shipping reliable, scalable systems.

I’ve included an architecture breakdown in the next post

DevOps #CloudEngineering #Render #Docker #CI_CD #Nginx #AgriTech #OpenToWork

FAILURE ANALYSIS & DEBUGGING

Miracle Olorunsola — Sun, 01 Mar 2026 12:00:00 +0000

What Pipeline Failures Taught Me

Failures included:

Missing tools
Incorrect build paths
Credential scope issues

Each failure improved:

Pipeline resilience
Observability
System understanding

DevSecOps is about controlled failure.
This project demonstrates hands-on experience with:

Jenkins CI/CD
Docker & Kubernetes
Terraform & AWS
Container security

Secure infrastructure design

I’m actively growing as a DevSecOps / Cloud Engineer and open to opportunities.

Secure Secrets Injection in Terraform & Jenkins

Miracle Olorunsola — Sat, 28 Feb 2026 12:00:00 +0000

Secrets are injected at runtime using:

Jenkins credentials

TF_VAR_db_username
TF_VAR_db_password

They are:

Not committed
Not logged
Not baked into images

This limits blast radius.

Provisioning AWS Infrastructure with Terraform

Miracle Olorunsola — Wed, 25 Feb 2026 12:30:00 +0000

Infrastructure is code — and should be treated that way.

Terraform manages:

VPC networking

EKS cluster

IAM permissions

Benefits:

Version control

Repeatability

Reduced misconfiguration risk