Forem: Bayo Ogundele

Building a Production-Grade DevOps Homelab on 4GB Ram HP Stream PC

Bayo Ogundele — Fri, 20 Feb 2026 18:38:43 +0000

After months of procrastination, I finally started building my home lab. Day 1 was all about establishing the foundation: organizing the project structure, setting up Docker Compose, and deploying a complete monitoring stack with Prometheus, Node Exporter, and Grafana.

The Hardware Reality Check

I started with an HP Stream (4GB RAM), but quickly realized it wasn't going to cut it. Container operations were painfully slow—startup times exceeded 2-3 minutes, and the system was constantly swapping memory. After struggling for a bit, I switched to my main PC with 8GB RAM and a stronger processor. The difference was immediate and dramatic. What took minutes now took seconds.

Lesson learned: Hardware constraints directly impact your development velocity. Don't underestimate the importance of adequate resources when building infrastructure.

Day 1 Project Structure

Before jumping into Docker, I organized the project directory to ensure scalability and maintainability. Here's what I created:

My organized homelab directory structure - separation of concerns from day one

The directory structure separates concerns into distinct layers:

monitoring/ - Prometheus and Grafana configurations with provisioning
cicd/ - Git server (Gitea) and CI/CD automation (Drone) for future deployment
apps/ - Application deployments including the sample-app
docs/ - Documentation and screenshots
scripts/ - Utility scripts for setup and maintenance

This structure makes it easy to:

Add new services without cluttering the root directory
Version control configurations separately from code
Scale the project as it grows
Onboard new team members quickly

Understanding the Monitoring Stack

My Day 1 setup consists of three core components working together:

Prometheus is the time-series database that collects metrics. It scrapes endpoints at regular intervals (I set mine to 15 seconds) and stores the data. Think of it as the "data collector" of the stack.

Node Exporter is a lightweight agent that runs on the system and exposes hardware and OS metrics—CPU usage, memory consumption, disk I/O, network traffic, and more. It exposes these metrics on port 9100 in a format that Prometheus understands.

Grafana is the visualization layer. It connects to Prometheus as a data source and allows you to create beautiful dashboards, set up alerts, and explore metrics interactively. It's the "pretty face" of your monitoring system.

Together, they form a complete monitoring pipeline: Node Exporter collects metrics → Prometheus stores them → Grafana visualizes them.

Docker Compose Architecture

I used Docker Compose to orchestrate all three services. Here's what each service does:

Prometheus Service:

Runs the official Prometheus image
Exposes port 9090 for the web UI
Mounts the prometheus.yml configuration file to define scrape targets
Uses a named volume to persist time-series data across container restarts
Joins a custom "monitoring" network for service-to-service communication

Node Exporter Service:

Runs the official Node Exporter image
Exposes port 9100 where metrics are available
Mounts the host's /proc and /sys directories to access system metrics
Also joins the monitoring network so Prometheus can scrape it

Grafana Service:

Runs the official Grafana image
Exposes port 3000 for the web UI
Uses environment variables to set the admin password
Mounts a volume for persistent dashboard and configuration data
Depends on Prometheus being available before it starts
Joins the monitoring network

The services communicate through a custom Docker bridge network called "monitoring." This means Prometheus can reach Node Exporter at http://node-exporter:9100 and Grafana can reach Prometheus at http://prometheus:9090—all without exposing these services to the host network unless necessary.

All 7 containers running smoothly - monitoring, Git server, and CI/CD infrastructure

Prometheus Configuration

The prometheus.yml file defines what metrics to collect and from where. I configured two scrape jobs:

The first job targets Prometheus itself on port 9090, allowing it to collect its own internal metrics. This is useful for monitoring the health of Prometheus itself.

The second job targets Node Exporter on port 9100. This is where all the system metrics come from—CPU, memory, disk, network, and more. Prometheus scrapes this endpoint every 15 seconds and stores the data.

The global configuration sets the scrape interval (how often to collect metrics) and evaluation interval (how often to evaluate alert rules). I kept both at 15 seconds for a good balance between data granularity and resource usage.

Prometheus successfully scraping metrics from both itself and Node Exporter - all targets UP and healthy

Setting Up Grafana

After the containers started, I accessed Grafana on port 3000 and performed the initial setup:

First, I added Prometheus as a data source. The key here is using the service name from Docker Compose—http://prometheus:9090—rather than localhost. This works because all services are on the same Docker network.

Next, I created my first dashboard. I added panels to visualize:

CPU usage over time (using the node_cpu_seconds_total metric)
Available memory (using node_memory_MemAvailable_bytes)
Disk I/O operations (using node_disk_io_time_seconds_total)
Network traffic (using node_network_transmit_bytes_total)

I set the dashboard to auto-refresh every 30 seconds so I could see real-time updates.

Real-time system monitoring with Grafana - CPU at 21%, RAM at 68.8%, and 6.9 days uptime. Beautiful visualization of all critical metrics.

Why This Stack Matters

This monitoring foundation is crucial because:

Visibility - You can't optimize what you don't measure. With Prometheus and Grafana, I have complete visibility into system performance.

Alerting - Grafana allows me to set up alerts that trigger when metrics cross thresholds. This is essential for production systems.

Scalability - This stack is designed to grow. As I add more services to my home lab, I can add new scrape targets to Prometheus without changing the core setup.

Learning - Building this on Day 1 teaches fundamental DevOps concepts: containerization, networking, time-series databases, and visualization.

Current System Status

Looking at my dashboard, I can see:

Resource Usage:

RAM: 5.5GB / 7GB used (68.8%)
SWAP: 2.3GB / 16GB used (14.6%)
CPU: 4 cores averaging 21.3% load
Root FS: 233 GiB total, 81.8% utilized
Uptime: 6.9 days

Running Services:

Grafana (visualization)
Prometheus (metrics database)
Node Exporter (system metrics)
Gitea (self-hosted Git server)
Gitea-DB (PostgreSQL database)
Drone Server (CI/CD orchestrator)
Drone Runner (build executor)

All containers healthy and running smoothly! ✅

Key Takeaways from Day 1

Hardware matters - The jump from 4GB to 8GB made a massive difference
Organization from the start - A clean directory structure saves headaches later
Docker Compose is powerful - Orchestrating multiple services with a single YAML file is incredibly efficient
Monitoring from Day 1 - Having visibility into metrics from the beginning helps identify bottlenecks early
Docker networking - Custom networks simplify service communication and keep things clean

What's Next?

Day 1 is just the foundation. My immediate next steps include:

Day 2 - Git Server & CI/CD:

Configure Gitea webhooks for automated builds
Create complete CI/CD pipelines with Drone
Deploy sample applications through automated pipelines

Week 1 Goals:

Fine-tuning Prometheus scrape intervals and retention policies
Creating more sophisticated Grafana dashboards with custom queries
Setting up alerting rules and notification channels
Adding more exporters (PostgreSQL exporter, etc.)

Future Plans:

Implementing Loki for log aggregation
Moving to Kubernetes on Oracle Cloud Free Tier
Infrastructure as Code with Terraform and Ansible
Service mesh implementation

Lessons Learned

1. Start with Adequate Hardware

Don't try to run production-grade infrastructure on inadequate hardware. The difference between 4GB and 8GB RAM wasn't just performance—it was the difference between frustration and productivity.

2. Monitoring First, Applications Second

By establishing monitoring before deploying applications, I have baseline metrics and can see exactly how each new service impacts system resources.

3. Docker Compose for Local Development

Docker Compose made it trivial to spin up complex multi-container applications. What would have taken hours to configure manually took minutes with docker-compose.yml.

4. Document Everything

I documented every step in my README and took screenshots throughout. Future me will thank present me when I need to recreate this or explain it in interviews.

For Others Starting Out

If you want to build a similar homelab:

You Don't Need Expensive Hardware

8GB RAM is sufficient for a robust local setup
Can start with just monitoring and add services incrementally
Cloud free tiers (Oracle, AWS, GCP) available when you outgrow local resources

Start with Monitoring

Don't jump straight to complex applications
Build observability first
You'll thank yourself when things break

Docker Compose is Your Friend

Learn it early, use it often
Makes complex setups simple
Infrastructure as code from day one

One Service at a Time

Don't try to deploy everything at once
Get one thing working perfectly
Then add the next piece

Conclusion

Building a home lab teaches you so much about infrastructure, containerization, and monitoring. Day 1 might seem simple—just three services in Docker Compose—but it's the foundation for everything that comes next.

The key takeaway: start simple, measure everything, and iterate. With the right monitoring in place from Day 1, you'll have the visibility needed to make informed decisions about what to build next.

Looking at my Grafana dashboard now, seeing all those metrics flowing in real-time, I know this foundation will serve me well as I continue building out the homelab.

Tomorrow: Adding Git server webhooks and creating my first automated CI/CD pipeline!

Deploying a Containerized E-commerce Application on AWS EC2: A Practical DevOps Walkthrough

Bayo Ogundele — Tue, 10 Feb 2026 18:02:34 +0000

This project started with a simple goal: deploy an e-commerce application the way real systems are deployed — not locally, not manually, and not magically.

I wanted to understand the entire flow: code → version control → containerization → registry → cloud server → running services → observability. So I built the system end to end and deployed it on AWS EC2 using Docker and Docker Compose.

Repository: https://github.com/BayoJohn/Project-2.git

🚀 The Problem I Wanted to Solve

A lot of projects stop at “it works on my machine.” I wanted to go further and deal with the questions that appear the moment you leave localhost:

How does the application get packaged?
How does the server get the application?
How are services started reliably?
How do you observe what’s running?

This project forced me to answer those questions directly.

📦 Version Control as the Starting Point

Setting up the GitHub repository to track infrastructure and application code.

Everything begins with a Git repository. I created a GitHub repo to serve as the single source of truth for the application code and infrastructure configuration. This wasn’t just about backup — it was about traceability. Every change to the system has a history, and that history matters once deployment is involved.

🐳 Containerizing the Application

I containerized the application using Docker because consistency is non-negotiable in deployment. Containers ensure the same environment runs locally and on the server, eliminating the “works here, breaks there” problem.

Docker Compose was used to define how multiple services run together. Instead of starting services manually, Compose allowed me to declare the system: the application, its dependencies, and how they communicate.

⚙️ Automating Builds with GitHub Actions

After containerizing the application, I introduced GitHub Actions to automate the build process. The goal wasn’t complexity — it was consistency.

Defining the CI/CD pipeline in YAML to automate testing and building.

This step mirrors how production teams treat builds: servers don’t compile code, and deployments don’t depend on local machines.

A successful GitHub Actions run: verified, built, and ready to deploy.

📤 Using Docker Hub as an Image Registry

Pushing the final Docker image to Docker Hub for centralized access.

After building the Docker images, I pushed them to Docker Hub. The registry acts as the bridge between development and production. Instead of copying files or rebuilding images on the server, the EC2 instance simply pulls the exact image it needs.

☁️ Provisioning the Server on AWS EC2

For the infrastructure, I used an AWS EC2 instance. EC2 was a deliberate choice because it exposes you to the fundamentals of cloud computing without abstracting too much away.

The AWS EC2 Console: Provisioning the virtual server that hosts the application.

Once the instance was created, I installed Docker and Docker Compose directly on the server.

A quick docker ps on the EC2 instance confirms that all 6 services—from the DB to the monitoring tools—are Up and healthy.

🚀 Deploying the Application on EC2

With Docker installed, the deployment flow was straightforward but intentional. I cloned the repository onto the EC2 instance, pulled the images, and started the services.

The terminal view: Using Docker Compose to spin up the entire multi-container stack.

📊 Monitoring and Observability with Grafana

Deployment isn’t complete if you can’t see what’s happening.

Real-time observability: Monitoring the EC2 instance health via Grafana.

I included Grafana in the stack to introduce observability early. Grafana provides visibility into system metrics like CPU, RAM, and network health.

Configuring the security groups and instance details to allow public access.

🧠 What This Project Changed for Me

This project shifted my mindset from “writing code” to “operating systems.” You stop thinking only about features and start thinking about reliability and repeatability. Breaking things on a real server teaches lessons no tutorial ever will.

💡 Final Thoughts

If you’re learning DevOps or cloud engineering, my advice is simple: deploy something real. Deal with registries, ports, servers, and failures. That’s where the abstractions disappear and understanding begins.

Repo: https://github.com/BayoJohn/Project-2.git

How I Automated My First Node.js App Deployment Using AWS App Runner

Bayo Ogundele — Thu, 15 Jan 2026 18:42:51 +0000

As someone just starting out in DevOps and cloud deployment, I wanted to challenge myself: could I automate the deployment of a Node.js app in a way that’s repeatable, efficient, and doesn’t require managing servers?

After some experimentation, I built a small project that demonstrates exactly that, and I’m sharing my journey, the tools I used, and the lessons I learned along the way.

🎯 The Goal

My goal was simple:

Build a Node.js application
Package it in a container
Push it to a registry
Deploy it automatically using a serverless service

Sounds straightforward in theory—but as a beginner, I had to learn a lot about containers, registries, and deployment services along the way.

🛠️ Tools I Used and Why

Here’s a breakdown of each tool and why I chose it:

1. Node.js

Since I was already familiar with JavaScript, Node.js was an obvious choice for my application. It’s lightweight, easy to set up, and widely supported by cloud platforms.

Why: Fast to develop, easy to containerize, and perfect for small web apps.

2. Docker

Docker allowed me to package my app and its dependencies into a container, ensuring it would run the same way anywhere.

Why: Consistency across environments and seamless integration with AWS App Runner.

3. AWS Elastic Container Registry (ECR)

ECR is AWS’s container registry, similar to Docker Hub but integrated with AWS. I used it to store my Docker images before deploying.

Why: It integrates seamlessly with AWS App Runner and simplifies authentication.

4. AWS App Runner

This was my first real experience with a serverless deployment service. App Runner lets you deploy containerized apps without worrying about servers. It handles scaling, HTTPS, and load balancing automatically.

Why: Removes operational overhead and is perfect for beginners who want to focus on the app rather than infrastructure.

5. Shell Scripting (deploy.sh)

To automate the deployment, I wrote a small script that builds the Docker image, pushes it to ECR, and triggers App Runner to deploy.

Why: Automates repetitive tasks and reduces the chance of human error.

Tip: Even as a beginner, scripting these steps helped me understand the workflow better.

⚙️ How It Works

Here’s a simplified overview of the deployment pipeline I built:

Develop the Node.js app locally
Containerize the app using Docker
Push the Docker image to AWS ECR
Trigger AWS App Runner to deploy the new image
App Runner automatically hosts and scales the app

Even though I’m new to deployment pipelines, having this workflow in place made updating my app as simple as running a single script.

🚧 Challenges I Faced as a Beginner

Docker authentication issues – Learning how AWS ECR login works took some trial and error.
Understanding App Runner concepts – At first, I wasn’t sure how services, images, and deployments connect.
Automation scripting – Writing a script that could handle errors and run in one go was tricky.

Despite these challenges, I learned a lot about containerization, cloud hosting, and deployment pipelines.

📚 What I Learned

Automation saves time: Writing scripts for deployment is much faster than doing everything manually.
Serverless hosting is beginner-friendly: App Runner abstracts complex server management.
Step-by-step learning works best: I started with a small Node.js app and gradually added Docker, ECR, and App Runner.

🚀 Next Steps

Now that I have a working deployment pipeline, my plans for improvement include:

Explore CI/CD integration with GitHub Actions – Automate builds and deployments whenever code is pushed to the repository.
Add environment variables and secrets management – Make the pipeline more secure and flexible for different environments.
Deploy more complex applications – Test the workflow with larger, multi-service apps to gain deeper experience.

💡 Final Thoughts

Even as a beginner, building this project has given me confidence in cloud deployment and DevOps workflows.

If you’re starting out too, I highly recommend experimenting with:

Containerized apps – Learn how to package and run applications consistently across environments.
Serverless deployment – Focus on your app rather than managing infrastructure.

It’s both educational and rewarding, and it gives you a solid foundation to grow in DevOps and cloud engineering.