Forem: Maad Mustafa

Been thinking a lot about self-hosting vs the cloud — not in a “this is better” way, but in a “this changed how I think” way. Wrote a short blog post about what running my own infrastructure taught me, and why it made me respect managed services more, not

Maad Mustafa — Wed, 14 Jan 2026 07:23:33 +0000

Maad Mustafa

Jan 13

Self-Hosting Didn’t Replace the Cloud. It Changed How I See It

#devops #cloud #privacy #automation

Comments

3 min read

Self-Hosting Didn’t Replace the Cloud. It Changed How I See It

Maad Mustafa — Tue, 13 Jan 2026 14:40:48 +0000

I never sat down and decided I was going to self-host.

There was no moment where I went, that’s it, I’m done with the cloud.
No manifesto. No rage about bills. No dramatic exit.

It just… happened.

I wanted more control over my stuff. I wanted to understand what was actually going on underneath. And one thing led to another, like it usually does.

The funny thing is, before self-hosting, I thought I understood the cloud.

I knew how to deploy things. I knew how to click through dashboards. I knew which service did what. I knew how to make things work.

What I didn’t fully appreciate was how much work was being done for me, quietly, all the time.

You only notice that once you start doing it yourself.

Self-hosting has this way of removing the illusion.

There’s no “it just scales”.
There’s no “high availability” unless you build it.
There’s no “automatic backups” unless you actually… set them up.

And test them. And make sure you didn’t delete them because you were cleaning up old stuff and got a bit too confident.

Everything you take for granted in the cloud suddenly becomes very visible.

And honestly? That’s not a bad thing.

One of the biggest shifts for me was cost.

Not because self-hosting is cheaper. It isn’t always.
But because costs become boring.

You know what you paid. You know what you’re paying. You know why.

There’s no mystery line item. No “wait, when did this start?”. No calculator that somehow still gets it wrong once real traffic shows up.

Time becomes the real cost instead.

And you pay it gladly… until you don’t.

Privacy and ownership hit differently too.

Not in a paranoid way. Just in a very practical way.

When everything runs under your control, you stop wondering where your data lives or who technically has access to it. You don’t need to interpret policies. You don’t need to trust that defaults haven’t changed.

You are the default.

That sounds empowering. It is.
It is also responsibility, whether you like it or not.

This is where people online lose me a bit.

There’s this idea floating around that self-hosting is somehow easier, cleaner, or more correct than using the cloud.

It’s not.

If anything, it’s heavier.

You think about backups more. You think about failure more. You think about updates more. You think about what happens when things go wrong — because they will.

And when they do, there’s no one else to blame.

That part is uncomfortable at first.
Then it becomes oddly grounding.

What surprised me most was how much it changed the way I think.

I stopped assuming systems will hold together on their own.
I stopped trusting “small changes”.
I started planning before touching things.

Not because someone told me to, but because I didn’t want to feel that sinking why did I not snapshot this feeling again.

Self-hosting has a way of teaching you consequences very efficiently.

And here’s the thing that doesn’t get said enough:

Once you’ve tried to run things properly yourself, you stop looking down on the cloud.

You actually respect it more.

You realise that what you’re paying for isn’t just compute or storage, it’s the absence of a thousand small decisions you no longer have to make.

The cloud is not lazy. It’s deliberate.

Self-hosting just makes those trade-offs visible.

I wouldn’t recommend self-hosting to everyone.

If you want things to just work, the cloud is the right answer.
If downtime stresses you out, the cloud is the right answer.
If other people rely on your setup and you don’t want to be on call the answer again is, the cloud.

Self-hosting is not about superiority.
It’s about curiosity.

And curiosity has a cost.

I don’t think there’s a final state where this feels “done”.

But I do know this:

Trying to own the whole stack, even imperfectly, made me more careful, more realistic, and more respectful of systems that actually work at scale.

And yeah, I’ll probably break something again too.

But at least I’ll know why.

When CI/CD Starts Feeling Wrong

Maad Mustafa — Mon, 29 Dec 2025 09:10:04 +0000

For a long time, GitHub Actions did exactly what I needed.

Push to main.
YAML runs.
Stuff deploys.

Nothing was broken.
But something felt… off.

When “Working” Still Feels Wrong

Every time my pipeline got messy, I did the obvious thing:

I added more YAML.
Because clearly the problem was not enough YAML.
It still worked.

But opening those workflows started feeling uncomfortable.

Not confusing.
Just… heavy.

When CI Quietly Becomes Infrastructure

At some point, my pipelines weren’t just building code anymore.

They were:

SSH’ing into servers
installing things
managing Docker
handling secrets I didn’t want to mess up

CI wasn’t CI anymore.
It was infrastructure — pretending not to be.

That’s when I stopped trusting it.

Nothing Was Broken — And That Was the Problem

The setup worked.
Which meant I didn’t touch it.
Which meant I didn’t fully understand it anymore.

I Wasn’t Looking for Better Tools
I wasn’t trying to “modernize” anything.

I just wanted one thing:

Predictability.

That’s when I started leaning into Ansible.

Why Ansible Felt Calm (In a Suspicious Way)

Instead of scripting steps, I described outcomes.
I ran the same playbook twice.
Nothing broke.

That felt… suspiciously peaceful.

What CI Stopped Needing to Do

Once servers had their own logic, CI got simpler.

It didn’t need to:

manage machines
hold state
be clever

It just needed to run jobs.
Which was a relief.

Why Jenkins Actually Made Sense

I avoided Jenkins for a long time.
Mostly because of the jokes.

But when I needed:

longer jobs
clearer control
less magic

…it fit.
Not pretty.
Just honest.

Where I Am Now

Ansible for servers.
Jenkins for pipelines.
Docker for workloads.

I understand it.
And that matters more than being “advanced”.

If This Sounds Familiar :

If your CI/CD works but feels heavy…
If you’re scared to touch it…
If you don’t fully trust it…

You’re not alone.

Did you stay with GitHub Actions?
Did you move away?
What finally pushed you to change?

I’d love to hear how others ended up here.

Building a NAS: Privacy, Projects, and Practicality

Maad Mustafa — Wed, 11 Jun 2025 12:36:54 +0000

Hey there, fellow tech enthusiast! I recently dove headfirst into building my very own NAS, and it's been quite the adventure. Grab a hot coffee or a cold beer, get comfy, and let me walk you through why this little project might just be your next favorite thing.

We developers juggle countless cloud subscriptions—from storage solutions and streaming services to backups and more. But have you ever thought, "What if I built my own?" Enter the world of Network-Attached Storage (NAS). It's more than just another geeky hobby; it's a practical powerhouse offering privacy, cost savings, and versatility.

What's a NAS Anyway?

Think of a NAS as your personal cloud. It's a centralized storage system connected directly to your home network, allowing seamless access from all your devices. Basically, it’s your cloud—but without monthly fees or surprise terms-of-service changes.

Is a NAS Right for You?

You're gonna love this if you're:

A developer itching for a hands-on, practical project.
Obsessed with privacy and love having complete control over your data.
Fed up with paying recurring monthly fees for cloud storage.

It might not be your cup of tea if you're:

Looking for something that requires zero maintenance (NAS setups need a bit of TLC).
Not excited by the idea of system management.
Deeply integrated into the convenience of big cloud ecosystems.

Why You Should Totally Build a NAS

🛡️ Privacy & Security

Your data, your rules. No more worries about third-party breaches or hidden data harvesting. Encrypt it, secure it, back it up—however you like!

💸 Cost Efficiency

Say goodbye to recurring monthly subscriptions. Yes, there's an upfront investment, but your wallet (and future self) will thank you for the predictable, long-term savings.

🚀 Performance

Imagine silky smooth 4K streaming, lightning-fast backups, and speedy file transfers, all customized exactly for your needs. No throttling, no waiting—just pure performance.

🎛️ Flexibility and Customization

From media servers like Jellyfin and Plex, to backups with Nextcloud, or even running Docker containers for your latest projects—your NAS becomes a tiny, supercharged server tailored to your every whim.

But Let's Get Real: Downsides Exist

Maintenance: Yup, updates and backups? They're all on you. Consider it a digital pet—feed it updates regularly!
Reliability: Power outage? Hardware hiccup? It happens. You'll need a backup plan.
Accessibility: Remote access is possible, but you'll need to spend some extra time setting it up securely.

NAS as a Cool Developer Project

Building a NAS isn't just fun; it's a resume booster showcasing serious skills:

Linux System Administration: Perfect for honing your Linux chops, networking skills, and security knowledge.
Docker & Containerization: Great way to level-up your container game and try out scalable setups.
Automation & Scripting: Automate all the boring stuff with bash or Python and watch your NAS practically run itself!

This project says loud and clear: you understand systems thinking, security, networking, and automation. Employers love this stuff!

Getting Started: Your NAS Shopping List

Recommended Hardware:

CPU: Intel i3 or AMD Ryzen 3 (entry-level does the trick)

RAM: Minimum 8GB—your future-proof friend

HDD: Go NAS-specific (WD Red is popular and reliable)

A sturdy case with decent airflow (your hardware appreciates good cooling!)

Software to Consider:

TrueNAS for rock-solid reliability

OpenMediaVault for beginner-friendly ease-of-use

Ubuntu Server for ultimate flexibility and familiarity (developers rejoice!)

Extra Tips:

Always keep backups offsite or in the cloud as a safety blanket.
RAID configurations are your best friend—keep your data safe and sound.
Secure remote access via VPN or SSL—because friends don't let friends skip security.

Building a NAS is rewarding, practical, and downright fun. Whether your goal is privacy, saving cash, or sharpening your developer skills, this project is a winner.

Have you tried self-hosted storage solutions? Got cool NAS stories or hilarious fails? Let’s chat in the comments—grab a virtual coffee, and let's geek out!

Docker vs Traditional Hosting

Maad Mustafa — Fri, 16 May 2025 14:36:21 +0000

Deciding how to deploy your web applications often sparks a debate hotter than tabs versus spaces—Docker or traditional hosting? Both methods have their merits, but understanding their unique strengths can help developers avoid deployment headaches.

Let's unpack why Docker might be your next best friend—or when sticking to good old traditional hosting still does the job.

Traditional Hosting: Old School but Not Obsolete

Traditional hosting usually involves renting a VPS, installing dependencies manually, and transferring files via FTP or SCP. While this method may feel straightforward, it can quickly escalate from easy-breezy to hair-pulling frustration.

Sure, traditional setups let you deploy fast and debug directly, especially if you enjoy logging into your server at 2 AM to track down a missing package. However, maintaining dependency versions and configurations by hand can lead to server drift—making "works on my machine" the most annoying phrase in tech.

And let's not even start about scaling; unless manually configuring servers is your hobby, you're probably better off exploring other options.

Docker Hosting: Containers to the Rescue!

Docker streamlines your deployments by packaging applications with all their dependencies into portable containers. Think of containers as neatly packed lunchboxes: everything you need is already inside, no surprises.

With Docker, your environments are consistent, easily portable, and scaling becomes as straightforward as duplicating containers. Docker turns the infamous "but it works on my machine" into "it works everywhere."

Here's a practical Docker example using a Flask app with Redis and Celery:

Dockerfile

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:5000"]

docker-compose.yml

version: '3.9'

services:
  web:
    build: .
    ports:
      - "5000:5000"
    env_file:
      - .env
    depends_on:
      - redis
      - worker

  redis:
    image: redis:alpine

  worker:
    build: .
    command: celery -A app.celery worker --loglevel=info
    env_file:
      - .env
    depends_on:
      - redis

.env file

FLASK_ENV=production
REDIS_URL=redis://redis:6379/0

Launching your full stack app becomes as easy as running docker-compose up. No more manual juggling—Docker has you covered.

When Docker Makes Sense

Docker is perfect when your app is more than a glorified "Hello World." Complex setups with multiple services, team projects, or anything requiring consistency across environments will significantly benefit from containerization.

When Traditional Hosting Still Holds Up

Traditional hosting remains viable for straightforward static websites or projects that don't require complex setups. If your biggest dependency is caffeine and your stack is simple, Docker might be overkill.

Quick Decision Guide

Wrap-Up Thoughts

Ultimately, choosing between Docker and traditional hosting boils down to your project's complexity, scalability needs, and your tolerance for manual setups. Docker isn’t just trendy tech—it’s a genuine lifesaver for modern app deployments. Meanwhile, traditional hosting keeps things simple for less demanding scenarios.

Knowing when and how to leverage each approach ensures you'll deploy smarter, not harder.

From Localhost to Live

Maad Mustafa — Thu, 08 May 2025 06:39:44 +0000

Congratulations! You've finally built your first real-world project using React, Flask, or Node.js. It looks amazing, it runs flawlessly on your machine, and you're excited to show it off. But wait—how exactly do you get your masterpiece from localhost onto the internet?

If you’re feeling stuck in the localhost bubble, I've got your back. Here’s your friendly guide on:

Hosting your React frontend easily with Vercel
Deploying your Flask or Node.js backend using Render or Railway
Useful tips to keep deployment smooth and hassle-free
Practical code snippets to make your life easier

Step 1: Get Your Code Ready to Shine

First things first—tidy up your project and make sure it's production-ready:

Frontend (React):

Clean out those console logs (yes, we all forget!)
Set up environment variables (REACT_APP_API_URL)
Run npm run build and make sure it passes

Backend (Flask or Node.js):

Include requirements.txt and a Procfile for Flask
Have a proper package.json and a start script for Node.js

Step 2: Easily Hosting Your Frontend with Vercel

Vercel is a lifesaver for beginners—it's free, simple, and quick. Here's the drill:

Push your code to GitHub.
Go to vercel.com and create your account.
Click "New Project" and connect your GitHub repository.
Watch magic happen—Vercel will detect React and deploy it seamlessly.

Pro Tips:

Store your secret environment variables securely in the Vercel dashboard.
Use a personalized custom domain—trust me, it feels great.

Step 3: Backend Deployment Made Simple

Option A: Flask on Render

Your setup should look something like this:

myapp/
├── app.py
├── requirements.txt
├── Procfile

Quick-start requirements.txt:

Flask==2.3.2
gunicorn==20.1.0

Simple Procfile:

web: gunicorn app:a

Deployment steps:

Push your repository to GitHub.
Visit render.com and register.
Create a new "Web Service," connect your repo.
Set the build command (pip install -r requirements.txt).
Set your start command (gunicorn app:app).
Add those essential environment variables (like PORT, FLASK_ENV).

Option B: Node.js on Railway

Easy setup package.json:

{
  "name": "my-api",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "express": "^4.18.2"
  }
}

Steps to deploy smoothly:

Push your project to GitHub.
Log into railway.app.
Click "New Project > Deploy from GitHub repo".
Relax while Railway auto-configures your backend.

Helpful hints:

Solve potential CORS issues quickly (using flask_cors for Flask, cors for Node.js).
Railway neatly manages your environment variables—use it!

Step 4: Connect Your Frontend and Backend Like a Pro

Switch your local URL:

fetch("http://localhost:5000/api/data")

to something shiny and public:

fetch("https://your-backend.onrender.com/api/data")

Make your life easier:

const API_BASE_URL = process.env.REACT_APP_API_URL;

Set this securely in Vercel’s environment settings.

Having CORS headaches?

Flask users:

from flask_cors import CORS
CORS(app)

Node.js fans:

const cors = require('cors');
app.use(cors());

Step 5: Rock Your Custom Domain

Make your project look professional:

Grab a domain.
Link it through Vercel or Render.
Configure DNS using Cloudflare for an extra touch of security and speed.

Step 6: Troubleshooting—We've All Been There

Render says "App crashed"? Check the logs and your PORT variable.
Frontend yelling "CORS error"? CORS setup above fixes it.
HTTPS worries? Good news—Vercel and Render automatically give you HTTPS.

Wrapping Up: Time to Celebrate!

Going from localhost to live feels incredible—it’s a huge step and totally worth celebrating. You just took a giant leap from "I made this on my computer" to "Hey world, check this out!"

Now, share your masterpiece, enjoy the feedback, and keep building amazing things!

How to Create Your Free Landing Page

Maad Mustafa — Thu, 01 May 2025 10:08:24 +0000

Why You Should Create a Free Landing Page for Your Portfolio or Resume (and How It Helps!)

Ever thought about having your own landing page but felt it's complicated or expensive? Good news: it doesn't have to be either! Having a personal landing page isn't just cool—it’s practical, professional, and totally doable for free.

Here's why having your own landing page matters:

Makes a Great First Impression: Think of it as your digital handshake. When someone Googles you, your landing page is your first chance to look polished, organized, and professional.
Control Your Own Story: Instead of just sending a boring PDF resume, imagine sharing a personalized link that highlights exactly what you want others to see: your best work, skills, testimonials from people you've worked with, or even your story.
Easy to Share: Forget heavy email attachments. A landing page lets you simply send a neat, clickable link. It's quick and efficient—perfect for busy recruiters, potential clients, or collaborators.
Helps with Visibility: Having a simple landing page can even help you pop up more often in search results. It makes you more discoverable, helping opportunities find you.

Here's a quick rundown of ways people typically use their landing pages:

Showcase creative portfolios (like designers, writers, or photographers)
Present professional resumes (great for job seekers or freelancers)
Build personal branding (highlight your story, values, and achievements)
Create easy-to-use links for social media bios (LinkedIn, Instagram, Twitter)
Host downloadable materials like resumes or case studies

Sounds good, right? And yes—this can all be done for free. Platforms like GitHub Pages, Carrd, Netlify, Google Sites, and Vercel make it super easy and won’t cost you anything.

How to Create Your Free Landing Page (Step-by-Step With Details)

Here’s a simple, beginner-friendly walkthrough to build your landing page from scratch.

Option 1: Using Carrd (Perfect for Beginners)

Step 1. Go to Carrd

Step 2. Click "Choose a Starting Point" and pick a "Profile" or "Landing" template.

Step 3. Click "Select", then "Start Building". It opens an easy drag-and-drop editor.

Step 4. Edit text boxes by clicking on them (e.g., change "Your Name" to your real name).

Step 5. Add a button that links to your resume (upload your PDF to Google Drive, then paste the shareable link).

Step 6. Use the "+" button to add sections like "Projects" or "Contact Info".

Step 7. Once done, click "Publish" > Choose a free .carrd.co URL > Publish.

That’s it! You now have a clean, mobile-friendly landing page.

Option 2: Using Google Sites (Great if you use Gmail)

Step 1. Go to Google Sites

Step 2. Click the "Blank" button or choose a template like "Portfolio".

Step 3. Click on any text to edit. Use the right-side panel to insert sections: Images, Text, Buttons, or Embed.

Step 4. For your resume, go to Google Drive, right-click your PDF, choose "Get link", and paste it as a button on your site.

Step 5. Add pages like "About Me", "Projects", and "Contact" using the menu on the top.

Step 6. Once happy with the layout, click "Publish", choose your URL, and hit Publish again.

Your landing page is live with a Google-hosted link you can share.

Option 3: Using GitHub Pages (For tech-savvy or coding curious folks)

Step 1. Go to GitHub and create an account if you don’t have one.

Step 2. Create a new repository named yourusername.github.io

Step 3. Go to HTML5UP and download any free portfolio template.

Step 4. Extract the files and upload them into your GitHub repo (drag and drop works).

Step 5. Go to Settings > Pages, choose the branch main, and click Save.

After a minute, your site will be live at https://yourusername.github.io

Bonus: You can edit the index.html file to update text, images, and links anytime.

Tips: Add Your Content (For All Platforms)

Regardless of which tool you use, include the following:

Your Name + Tagline (e.g., Full-Stack Developer | Storyteller in Code)
Short About Me section
Projects or Portfolio Links (screenshots + links work great)
Resume Download button
Contact Info or Socials (LinkedIn, Email, GitHub)

Personalization: (Optional) Connect a Free Custom Domain

Visit freenom and register a .tk or .ml domain.

Use DNS records to point your custom domain to your Carrd, Google Site, or GitHub Page.

In short: You don’t need to know code, spend money, or be a web designer to build a personal landing page. Just pick a platform, follow these steps, and boom—you’re online.

Whether you’re applying for a job, sharing your work, or just want a clean professional space online—this is the easiest and most affordable way to do it.

Let your landing page speak for you. You’re just a few clicks away!

From Uni to Dev Life: What They Don’t Teach You

Maad Mustafa — Wed, 23 Apr 2025 19:44:36 +0000

I’m in my third year of university, currently in my internship year, and working as a software engineer at a B2B marketing firm that's been transitioning into the tech space. But this wasn’t an overnight leap.

Back in my first year, while studying full-time, I started working part-time from home as a campaign executive — mostly handling data entry and marketing ops between lectures. It wasn’t glamorous, but it was my first exposure to how businesses actually operate.

By the 2nd semester of my 2nd year, I got an opportunity to intern as a software engineer at the same company. A growing B2B marketing firm with a bold push into tech, that meant I didn’t have a strict role. I had to learn — a lot, and fast.

🎓 What University Taught Me

To be fair, uni wasn’t useless. I learned:

Basic programming in Python and Java
Object-oriented programming concepts
Some SQL and DBMS theory
Teamwork through group projects

But looking back, it’s like being handed a pencil and paper and being told, “Okay, go build a skyscraper.”

🧠 What the Job Actually Demanded

From the first week, I realized: writing code is the easy part. Everything else? That’s where the real learning began.

Here’s a breakdown of what I had to figure out on the fly:

🛠️ 1. Being a Full-Stack Problem Solver

There was no "backend team" or "frontend team" — just us. Some days I was helping build UI components or setting up dashboards, other days I was knee-deep in APIs, user session management, and authentication logic.

🔐 2. Becoming a Mini DevOps Engineer

I set up:

Our production server (on a Linux box I’d never seen before)
Nginx for reverse proxying and static asset delivery
Firewalls, DNS configurations, even domain delegation using Cloudflare and GoDaddy

None of this was covered in lectures.

The reason I’m sharing all this isn’t just to list cool things I did — it’s to show the huge gap between what university prepares you for and what working in the real world actually demands.

In uni, group projects are neatly divided. If you're good at frontend, you stick to frontend. Backend people stick to backend. Everyone completes their part and submits on time. It’s predictable. Controlled. Safe.

But in a startup? You don’t have the luxury of staying in your comfort zone. If something breaks, you fix it — even if you’ve never touched it before. There’s no "That’s not my role." You become the role. One day you're writing APIs, the next you're configuring DNS, and by the end of the week, you're explaining app logic to the marketing team like a product manager. It’s chaotic, intense, and overwhelming — especially when you realize that none of your lectures taught you how to actually survive this.

But here’s the thing: that chaos is where you grow. You stop thinking like a student and start thinking like a developer — not someone who just writes code, but someone who solves problems.

🌱 Growth Beyond the Classroom

Looking back, these months at the startup taught me more than two years of lectures. Uni gave me the foundation—logic, syntax, problem-solving—but the real world taught me adaptability. I went from feeling clueless to confidently managing servers and building features. The overwhelmingness faded, replaced by a quiet pride in how far I’d come.

Here’s what stood out:

Practical Skills Trump Theory: Knowing how to code is one thing; knowing how to deploy it is another. The startup forced me to learn the full stack, from ideation to production.
Soft Skills Matter: Talking to teammates, managing my time, figuring out what the business needed—these were as critical as my tech skills.
Failure Is Fuel: Every screw-up (and there were plenty) made me better. Breaking things taught me how to fix them.

🎯 Tips for Fellow Students

Don’t wait for your degree to “make you ready.” You get ready by doing.
Ask for Help: No one expects you to be an expert on day one. Lean on your team—they’ve been there.
Apply for roles even if you don’t feel 100% qualified.
Go Beyond Code: Learn the tools (like Redis or NGINX) and the business side. It’ll set you apart.

If you’ve made it this far, chances are something I said hit close to home — maybe it reminded you of your own panic Googling why your Nginx config broke everything, or that moment when your “small change” took down staging.

Whether you're still studying or just started working, trust me: you’re not behind — you’re just getting started. And every confusing error, unexpected bug, and awkward client demo is leveling you up, one day at a time.

If this post made you nod, laugh, or scream internally, drop a comment below — let’s swap stories, cry about prod bugs, or just connect.