DEV Community: Duru Juliet Chinenye

AgriAI-Insight

Duru Juliet Chinenye — Tue, 07 Jul 2026 17:21:45 +0000

🌾 Predicting crop yields for Nigerian farmers with AI.
I built AgriAI-Insight, a crop yield prediction platform covering all 36 Nigerian states + FCT, because too many smallholder farmers are making planting decisions without the data tools that farmers in other markets take for granted.

Under the hood: a FastAPI backend deployed on AWS Lambda, paired with a React Native mobile app so it's usable in the field, not just at a desk.
This is part of a bigger goal for me: building practical AI tools for underserved communities across Nigeria and Africa, not just AI for AI's sake but AI that answers a real question a farmer has.
🔗 Try it: https://agriai-insight.netlify.app/
It's open source too. 👇

🔗 https://github.com/JulietChinenyeDuru/agriAI-insights
Feel free to fork it and build on it, and if you find it useful, a star ⭐ on the repo goes a long way in helping others discover it.

JobApp AI

Duru Juliet Chinenye — Tue, 07 Jul 2026 17:11:25 +0000

💼 Job hunting shouldn't cost a fortune or your data.
JobApp AI is a subscription platform helping job seekers streamline their applications, with pricing designed to stay accessible across Africa and other global regions.

Milestones I'm proud of: 🔒 Shipped end-to-end encryption for stored user credentials 💳 Built a self-service billing portal so users can manage their own subscriptions, no support ticket needed 🛡️ Ran a full security audit of the codebase because trust isn't a feature; it's a foundation
Building a SaaS product solo means wearing every hat: engineer, security reviewer, support desk, and product manager. This was a good reminder of why that audit work matters as much as the features people see.
🔗 Try it: https://jobapp.best

It's open source too. 👇
🔗 https://github.com/JulietChinenyeDuru/Job-App-AI
Feel free to fork it and build on it, and if you find it useful, a star ⭐ on the repo goes a long way in helping others discover it.

Naija Learn-AI

Duru Juliet Chinenye — Tue, 07 Jul 2026 17:00:58 +0000

🎓 An AI tutor that speaks different languages.
Most AI tutoring tools are built as if every student learns in English and thinks in English. That's not the reality for a huge number of Nigerian university and STEM students, so I built NaijaLearn-AI to close that gap.
It's a Claude-powered multilingual AI tutor supporting five languages, a combination I haven't seen any other tutoring app fully address. The idea is simple: meet students in the language they think in, and the concepts land faster.

This one comes from a simple observation, and I think simple observations, taken seriously, are where a lot of the best products come from.

🔗 Try it: https://naijalearn-ai.netlify.app

It's open source too. 👇
🔗 https://github.com/JulietChinenyeDuru/NaijaLearn-AI
Feel free to fork it and build on it, and if you find it useful, a star ⭐ on the repo goes a long way in helping others discover it.

AgriAI-Insight

Duru Juliet Chinenye — Tue, 07 Jul 2026 16:57:01 +0000

🔗 Try it: https://agriai-insight.netlify.app/
It's open source too. 👇

🔗 https://github.com/JulietChinenyeDuru/agriAI-insights
Feel free to fork it and build on it.

and if you find it useful, a star⭐ on the repo goes a long way in helping others discover it.

End-to-End Cloud Deployment Using Terraform, Ansible, and Azure Pipelines on AWS

Duru Juliet Chinenye — Wed, 29 Apr 2026 16:28:02 +0000

I deployed a full-stack application using a two-repository CI/CD model, and it completely reshaped how I think about DevOps.

What I Built
A full end-to-end deployment of the Epic Book online bookstore on AWS, split across two repositories and two independent pipelines.
Repo 1: Infrastructure (book-review-infra)
• Terraform code provisioning all my AWS resources
Repo 2: Application (theepicbook)
• Node.js application
• Ansible configuration for automated server setup

Pipeline 1: Infrastructure (Terraform)
• Pulled SSH public key from Azure DevOps Secure Files
• Authenticated to AWS using IAM credentials
• Ran terraform init → plan → apply
• Provisioned VPC, subnets, EC2 instances (frontend + backend), and MySQL RDS
Pipeline 2: Application (Ansible)
• Pulled SSH private key from Secure Files
• Dynamically updated inventory using Terraform outputs
• Configured both servers
• Deployed Epic Book and verified Nginx routing

Everything I built was automated. Not as a nice-to-have, but as the entire point. Having Azure Pipelines and GitHub working together meant I could go from a code push to a live running application without touching a single server manually.
AWS handled my infrastructure. Azure DevOps ran my pipelines. GitHub held my code. Three different platforms, one seamless workflow.

That is what modern DevOps looks like. Not one tool. Not one vendor. Just the right tool for each job, connected deliberately and securely.

Still building. Not stopping.

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana , Mobarak Hosen, Onuche Paul and Nkechi Anna Ahanonye

DevOps #AWS #AzureDevOps #Terraform #Ansible #CICD #CloudComputing #MySQL #Nginx #InfrastructureAsCode #LearningInPublic #DevOpsForBeginners #GitHub#TechJourney #WomenInTech #WomenInCloud #BlackInTech #TechCommunity #100DaysOfCode #Upskilling #Automation #Linux #Docker #IaC #DevOpsMicroInternship #DMI #TechEducation

Deployed a Scalable Nginx App on AWS EKS Using Kubernetes

Duru Juliet Chinenye — Wed, 29 Apr 2026 12:21:25 +0000

I've been building as a DevOps engineer for a while now, so I decided to take on this project using Kubernetes. And it changed how I see infrastructure entirely.

I built the Nginx app running behind an AWS Elastic Load Balancer, provisioned automatically by Kubernetes on EKS.

Here's what the journey looked like:

I created my first pod and learned the hard way that pods are immutable; you can't edit a running one; you must delete and recreate it.
I set up replica sets, deleted a pod, and watched Kubernetes replace it in seconds. Auto-healing in action.
I configured deployments with rolling updates, zero downtime, and instant rollbacks. Version control for infrastructure.
I configured HPA for auto-scaling based on CPU. At 5 pm, when traffic spikes, Kubernetes handles it, not me.
I wired up readiness & liveness probes and learned about "running" and "ready." These two probes are what make Kubernetes intelligent.

I worked through Services; this is where it all came together:

ClusterIP: stable internal DNS. No more chasing Pod IPs.
Node Port: external access without a cloud LB.
Load Balancer: one YAML field change → real public AWS ELB provisioned automatically.

The moment my curl hit that public URL, backed by a Kubernetes cluster I built myself, it stopped being theory.

The struggles were real. Memory limits on a 3.8GB machine. Errors I didn't understand at 1 pm. Moments where I wanted to close the laptop and walk away.

But I didn't. And I'm so glad.
I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana, Mobarak Hosen, Onuche Paul and Nkechi Anna Ahanonye

Kubernetes #DevOps #AWS #EKS #CloudComputing #K8s #CloudNative #CloudEngineer #DevOpsEngineer #Infrastructure #LearningInPublic #TechJourney #WomenInTech #WomenInCloud #BlackInTech #TechCommunity #100DaysOfCode #Upskilling #Automation #Linux #Docker #IaC #DevOpsMicroInternship #DMI #TechEducation

Production Grade Deployment of the Epic Book Multi Service Application on AWS EC2 Using Docker & Nginx

Duru Juliet Chinenye — Tue, 28 Apr 2026 00:45:12 +0000

This capstone project represents a major milestone in my DevOps journey. It was a full multi-service application pulled from an unfamiliar GitHub repository, which I deployed end-to-end as a production-ready system on AWS EC2. I architected, containerized, secured, and deployed the entire stack myself.
What I Deployed
EpicBook is an online bookstore with a complete e-commerce flow: Browse books → View details → Add to cart → Checkout → Order confirmed.
It’s built with Node.js, Express, MySQL, Handlebars, and Nginx.
The production architecture: Internet → Nginx (80) → Express Backend (3000) → MySQL (3306) Simple to describe—very different to build correctly.

What I Actually Built
Here’s what went into making this system production-ready:
• I analyzed an unfamiliar codebase and mapped out every service, port, environment variable, and dependency before writing any configuration.
• I wrote a multi-stage Docker file for the backend, keeping only production dependencies in the final runtime image.
• I designed a Docker Compose stack with Nginx, Express, and MySQL, all connected using internal service names (no hardcoded IPs).
• I created two isolated Docker networks, so MySQL is never exposed to the internet.
• I added health checks with dependencies to enforce correct startup order, no race conditions, and no boot failures.
• I configured Nginx as a reverse proxy, routing all traffic through port 80 and adding security headers.
• I managed all secrets using .env files; no credentials in Git, no exceptions.
• I validated data persistence using named volumes; every book, category, and order survived container restarts.
• I designed a backup and restored plan using daily MySQL dumps and tested the restore process.
• I implemented a logging strategy: backend logs to stdout and Nginx logs persisted with rotation.
• I ran reliability tests by restarting services, killing the database, and bouncing the stack, documenting how the system recovered.

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana , Mobarak Hosen, Onuche Paul and Nkechi Anna Ahanonye

DevOps #Docker #MultiStageBuild #Nginx #React #AWS #EC2 #Linux #Containers #CI_CD #DMI #CloudEngineer #BuildInPublic #ShipIt

Deployment of a React Application Using Docker Multi Stage Builds on AWS EC2

Duru Juliet Chinenye — Tue, 28 Apr 2026 00:02:00 +0000

I’ve been building every single day, but this one hit differently. I went deep into Docker multi-stage builds, and I finally understand why every production team relies on them.

What I Built
I took a React application and containerized it in two different ways:

Single-Stage Build
Node.js installs everything, builds the app, and serves it from one image.
Final image size: 778 MB
Multi-Stage Build
Stage 1: Node.js builds the app
Stage 2: Nginx serves only the compiled output
Final image size: 94.1 MB

I used to think Docker was just about running apps in containers. Now I see the deeper engineering principles:
• Build environment ≠ runtime environment.
Node.js, npm, and build tools have no place in a production container serving static files.
• Layer caching is a discipline.
Copying package.json before source code means Docker reuses cached npm installs unless dependencies change, saving real time and real money in CI/CD.
• Smaller images matter.
Less storage, fewer CVEs, faster pushes/pulls, quicker startup times—it all compounds in production.
• Nginx config is not optional for React.
Without a proper try_files fallback, client-side routing breaks on refresh. I tested it. I saw it. I fixed it.

What I’ve Built and Deployed So Far
• Launched and configured AWS EC2 instances
• Automated Docker installation using cloud-init User Data
• Deployed a static website inside a Docker container on port 80
• Built and compared single-stage vs multi-stage Docker images
• Configured Nginx to serve a React app with routing and cache headers
• Debugged real-world issues: port conflicts, container name clashes, missing keys, permission errors

Every one of these was built live, broken at least once, fixed, and shipped.

That’s the only way I know how to learn.

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana, Mobarak Hosen, Onuche Paul and Nkechi Anna Ahanonye

DevOps #Docker #MultiStageBuild #Nginx #React #AWS #EC2 #Linux #Containers #CI_CD #DMI #CloudEngineer #BuildInPublic #ShipIt

Deployment of a Static Website on AWS EC2 Using Docker

Duru Juliet Chinenye — Mon, 27 Apr 2026 23:15:31 +0000

This week, I took a major step forward in my DevOps journey. I deployed a fully live static website to the internet using AWS EC2, Docker, and Nginx. Seeing my work accessible at http://35.176.161.171 was a proud moment.

I built the entire setup from scratch:
• Launched an Ubuntu 22.04 EC2 instance
• Configured Security Groups for SSH (22) and HTTP (80)
• Automated server setup using cloud-init (User Data)
• Installed and configured Docker
• Cloned a static website from GitHub
• Wrote a custom Docker file using Nginx, Alpine
• Built the Docker image and ran the container on port 80
• Accessed the live site from the browser fully deployed and running

This project helped me deepen my understanding of real DevOps workflows:
• How cloud-init automates provisioning at boot
• The difference between a Docker image and a container
• How to write a Docker file and serve static files with Nginx
• How to troubleshoot real-world issues like port conflicts and container name clashes
• How Docker, Nginx, and cloud infrastructure integrate in a practical DevOps pipeline

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana, Mobarak Hosen, Onuche Paul and Nkechi Anna Ahanonye

DevOps #AWS #Docker #Nginx #CloudComputing #EC2 #Linux #DMI #LearningInPublic #CloudEngineer #Containers

production-grade deployment of The Epic Book, a Node.js + MySQL web application on AWS

Duru Juliet Chinenye — Thu, 23 Apr 2026 15:45:25 +0000

Just deployed a full-stack web application to AWS using Terraform + Ansible.

As part of my cloud engineering journey, I completed a

Here's what I built from scratch:

Infrastructure (Terraform)
• VPC, public subnet, internet gateway, and route tables
• Security groups with control
• Ubuntu 22.04 EC2 instance with SSH key authentication
• All infrastructure destroyed and recreated in minutes; that’s the power of IaC

Configuration Management (Ansible)
• 3 clean, reusable roles: common → nginx → epicbook
• Nginx configured as a reverse proxy in front of Node.js
• MySQL provisioned and configured automatically
• PM2 process manager keeping the app alive
• Fully idempotent: re-running the playbook shows zero failures

Result: A live, browser-accessible web app served over HTTP with nginx proxying to a Node.js backend connected to MySQL, all automated, repeatable, and production-ready.

Challenges I overcame:
• The app wasn't a static site; it had to switch from file serving to a full reverse proxy setup
• MySQL authentication required, matching the app's config exactly
• Port conflicts on re-runs taught me the importance of clean state management in automation

What this taught me: Real deployments are never just "run a script, and it works." They require understanding full-stack networking, web servers, application runtimes, databases, and process management and how they all connect.

This is exactly how production engineering teams operate, and I'm proud to have built it end-to-end.
Tech used: AWS EC2 · Terraform · Ansible · Nginx · Node.js · MySQL · PM2 · Ubuntu 22.04
I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana ,Mobarak Hosen,Onuche Paul and Nkechi Anna Ahanonye

DevOps #AWS #Terraform #Ansible #CloudEngineering #IaC #Linux #Nginx #NodeJS #MySQL #LearningInPublic #CloudComputing #Infrastructure

Deployment of a Mini Finance Dashboard using Terraform and Ansible

Duru Juliet Chinenye — Thu, 23 Apr 2026 15:03:38 +0000

Deployed the Mini Finance Dashboard this week using Terraform and Ansible.

Here is what I built:
Provisioned an AWS EC2 instance using Terraform
Created VPC, Subnet, Internet Gateway and Security Groups as code
Configured passwordless SSH access with ED25519 keys
Used Ansible roles to install Nginx, Node.js, MySQL
Deployed the Mini Finance Dashboard, fully accessible from any browser
Verified the site loads live with HTTP 200 ✓
The best part? The entire infrastructure is code. I can destroy it and rebuild it in minutes. That is the power of doing it right.
Terraform handles the infrastructure. Ansible handles the configuration.
Real problems I hit and pushed through:
Nginx returned 403. The app is Node.js, not static files. Reconfigured as a full reverse proxy and kept moving

MySQL auth was failing; credentials had to match the app config exactly. Fixed native password authentication and moved on

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana ,Mobarak Hosen,Onuche Paul and Nkechi Anna Ahanonye

DevOps #AWS #Cloud #Terraform #Ansible #Linux #Ubuntu #NodeJS #MySQL #Nginx #MiniFinanceDashboard #Infrastructure #ShipIt #CareerGrowth #Tech

Deploying a full, three-tier book review web app on Azure

Duru Juliet Chinenye — Mon, 16 Mar 2026 05:52:00 +0000

I designed and deployed one of my most hands-on cloud engineering projects: deploying a secure, scalable book review application using a full three-tier architecture on Microsoft Azure.
But the real growth came from the challenge I hit along the way and how I solved it.

The Problem I Encountered
After deploying the backend (Node.js/Express) for the book review app in private subnets, the frontend couldn’t reach it.
The internal load balancer was healthy, and the backend was running on port 3001, but every request from the frontend timed out.
Everything looked correct: subnets, routes, health probes, VM status—yet the app simply wouldn’t connect.

How I Solved It
The issue turned out to be a Network Security Group (NSG) misconfiguration.
The App Tier NSG wasn’t allowing inbound traffic from the Web Tier on port 3001, even though the internal load balancer was configured correctly.

I fixed it by:
•Updating the App Tier NSG
•Allowing inbound traffic only from the Web Tier NSG
•Opening port 3001 specifically for internal communication
As soon as that rule was added, the Book Review app connected instantly.
This experience reinforced a key lesson: Azure NSGs don’t assume trust; you must define it explicitly.

What I Built
Here’s the full architecture behind the book review app:
Frontend (Web Tier)
•Next.js served via Nginx on Ubuntu
•Behind a Public Azure Load Balancer
•Lives in public subnets only
Backend (App Tier)
•Node.js/Express API on port 3001
•Deployed in private subnets
•Accessible only through an Internal Load Balancer
Database (Data Tier)
•Azure Database for MySQL Flexible Server
•Multi-AZ high availability
•Read replica for scaling
•NSGs allowing only App Tier traffic on port 3306
Networking
•Custom VNet (10.0.0.0/16)
•6 subnets across 2 zones
•Strict NSGs per tier
•No public exposure for backend or database

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana and Mobarak Hosen

CloudEngineering #Azure #DevOps #Nextjs #Nodejs #MySQL #ThreeTierArchitecture #CloudSecurity #AzureNetworking #LoadBalancing #FullStack #CloudProjects #TechJourney #MicrosoftAzure #CloudArchitect #BookReviewApp #DuruBuildsCloud