Today, we wrap up our series with The Guard, a final checklist of best practices to harden your Docker environment.

1. Security First: Trust No One

Security in Docker starts at the image level. If your container is compromised, you want to ensure the damage is contained.

• Run as Non-Root: By default, containers run as root. You should always configure your Dockerfile to use a non-privileged user to limit what an attacker can do if they gain access.
• Use Official Images: Whenever possible, start your Dockerfile with an official, verified image from Docker Hub.
• Scan for Vulnerabilities: Use tools to scan your images for known security holes before you deploy them.
• Keep Images Updated: Security patches are released constantly; regularly rebuilding your images ensures you have the latest fixes.

2. Resource Management: Don’t Let One Container Crash the Server

In a production environment, you cannot allow a single container to go rogue and eat up all your host's memory or CPU.

• Set Resource Limits: Always define maximum memory and CPU limits for your containers. This ensures that even if a service has a memory leak, it won't crash your entire Proxmox node or production server.
• Avoid the :latest Tag: Never use the :latest tag in production. Use specific version tags (like node:18.1.0) so you know exactly what code is running and can roll back easily if something breaks.

3. Reliability and Health

Production systems need to be self-healing. If a service hangs, Docker needs to know how to handle it.

• Implement Health Checks: Use health checks to let Docker monitor the actual status of your application, not just whether the process is running.
• Production Environment Variables: Ensure your NODE_ENV or equivalent variables are explicitly set to production. This often triggers optimizations in frameworks that improve performance and disable verbose debugging logs.
• Data Persistence: Use named volumes for your production data to ensure portability and easier backup management.

Conclusion: You Are Ready

Docker has revolutionized how we develop, ship, and run applications. By understanding these core pillars—Architecture, Networking, Volumes, Multi-stage builds, and Orchestration—you are no longer just "running containers". You are building scalable, professional infrastructure.

Whether you are hosting a personal project in your home lab or managing a massive cluster for a client, these principles remain the same.

Happy Dockerizing!

A modern web app usually looks like this:

• A Frontend (React or Vue)
• A Backend API (Node.js, Laravel, or Python)
• A Database (PostgreSQL or MySQL)
• A Cache (Redis)

Starting these one by one with docker run is tedious and error prone. This is where Docker Compose steps in as your conductor.

What is Docker Compose?

Docker Compose is a tool that allows you to define and run multi-container applications. Instead of typing long commands in your terminal, you define your entire infrastructure in a single file called docker-compose.yml.

With one command, you can start every service your app needs, pre-configured to talk to each other.

Breaking Down the YAML File

The docker-compose.yml file is organized into three main sections:

1. Services: This is where you define your containers (the frontend, the backend, etc.).
2. Networks: This automatically sets up the "plumbing" we discussed in post one so your services can communicate.
3. Volumes: This handles the "memory" from post two so your database stays persistent.

A Full-Stack Example

Here is a simplified look at how a typical stack is defined:

version: "3.8"
services:
  frontend:
    build: ./frontend
    ports:
      - "3000:3000"
    networks:
      - app-network

  backend:
    build: ./backend
    environment:
      - DB_HOST=database
    networks:
      - app-network

  database:
    image: postgres:15
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - app-network

volumes:
  db-data:

networks:
  app-network:
    driver: bridge

Essential Compose Commands

Once your file is ready, these are the commands you will use every day:

• Start everything: docker-compose up -d (The -d runs it in the background).
• Stop and remove everything: docker-compose down.
• View running services: docker-compose ps.
• View live logs: docker-compose logs -f.
• Run a command inside a service: docker-compose exec backend npm run migrate.

Why This is a Game Changer

Using Compose means your entire environment is documented in your code. If a new developer joins your team, or if you want to move your app to a new server in your home lab, they don't need to ask you for the setup instructions. They just run docker-compose up and everything works.

In tools like Portainer, these files are often referred to as "Stacks." It is the most efficient way to manage complex applications without losing track of your configuration.

Wrapping Up

Docker Compose takes the manual labor out of container management. It ensures that your frontend, backend, and database always start in the right order with the right settings.

In our final post of this series, we will look at The Guard. We will cover the essential checklist for moving these containers out of development and into a secure production environment.

Happy Dockerizing!

When you first start building images, it is common to end up with files that are 900MB or larger. These heavy images take longer to upload to your registry, longer to pull onto your Proxmox server, and they often contain security vulnerabilities you do not need.

Today, we are putting our images on a diet using Multi-Stage Builds.

The Problem: The Single-Stage Bloat

Imagine you are building a React or Node.js application. To build the app, you need tools like npm, compilers, and source files. However, once the app is "built" into a production folder, you do not need npm or the source code anymore. You only need the final files and a tiny web server.

In a traditional single-stage Dockerfile, all those build tools stay inside the final image. This is like keeping the construction crane inside the house after you have finished building it.

The Solution: Multi-Stage Builds

Multi-stage builds allow you to use multiple FROM statements in one Dockerfile. You use one "stage" to build your app and a second "stage" to actually run it.

Here is how the logic works:

1. Stage 1 (The Builder): You use a full image with all the tools needed to compile your code.
2. Stage 2 (The Production Image): You start with a tiny, slim image (like Alpine Linux). You copy only the finished files from the first stage and leave everything else behind.

A Practical Example (Node.js)

# Stage 1: Build the app
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Stage 2: Production
FROM node:18-alpine
WORKDIR /app
# We only copy the 'dist' folder from the builder stage
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/app.js"]

Why This Matters

• Smaller Size: An image can drop from 900MB to 50MB just by switching to a multi-stage build with an Alpine base.
• Better Security: Since the final image does not have compilers or package managers, there is a much smaller attack surface for hackers.
• Faster Deployments: In my home lab, pulling a 50MB image is nearly instant compared to waiting for a massive 1GB file.

Best Practices for a Lean Image

• Use .dockerignore: Just like .gitignore, this tells Docker to ignore files like node_modules or local logs during the build.
• Combine RUN Commands: Every RUN command creates a layer in your image. Combining them using && helps keep the layer count low.
• Pick Official Images: Always try to use official images from Docker Hub to ensure they are updated and secure.

Wrapping Up

A lean image is a fast image. By using multi-stage builds, you ensure that your production environment only contains exactly what it needs to run.

In the next post, we are going to look at The Conductor. We will move beyond single containers and learn how to use Docker Compose to run entire stacks with a single command.

Happy Dockerizing!

To solve this, we need to move the data out of the container and onto the host machine. We have three main ways to do this.

The Three Storage Options

1. Bind Mounts: You map a specific path on your host machine (like /home/asif/project) to a path inside the container.
2. Volumes: These are managed entirely by Docker. You do not need to worry about where they live on the host; Docker handles the directory structure for you.
3. tmpfs Mounts: These live only in the host's memory. They are never written to the disk, making them perfect for sensitive data that should disappear when the container stops.

Bind Mounts vs. Volumes: Which One Should You Use?

This is where most people get confused. Here is a simple breakdown:

Practical Examples

For Development (Bind Mount)

If you are working on a Node.js or Laravel project, you want the container to see your code changes immediately.
docker run -d -v $(pwd):/app my-app

For Your Database (Named Volume)

For something like PostgreSQL, you want Docker to manage the storage safely.
docker run -d -v db-data:/var/lib/postgresql/data postgres

Pro-Tip for Home Lab Users

Since I use Portainer, I prefer using Named Volumes for my stacks. It makes it much easier to back up the data and move it between different Proxmox virtual machines without worrying about hardcoded file paths on the host.

Wrapping Up

Managing storage correctly is the difference between a stable app and a total data loss disaster. Always remember: Keep your application in the container, but keep your data in a volume.

In the next post, we are going to look at The Diet. I will show you how to use Multi-Stage builds to make your images smaller, faster, and more secure.

Happy Dockerizing!

When you run a container, it feels like it is on its own island. However, to be useful, it needs to talk to the internet, the host machine, or other containers. Here is how that actually happens.

The Default Bridge (docker0)

By default, Docker creates a virtual bridge on your Linux host called docker0. Think of this as a virtual network switch.

When you start a container, Docker gives it a virtual ethernet pair (called veth). One end of this "cable" stays in the container as eth0, and the other end plugs into the docker0 bridge on your host. This is how the container gets its own IP address, usually something like 172.17.0.2.

Why the Default Bridge is Not Enough

While the default bridge works, it has a major downside: It does not support automatic DNS resolution.

If you have a "web" container and a "database" container on the default bridge, the web container cannot find the database by its name. You would have to use the specific IP address. Since container IPs change every time they restart, this is a nightmare to manage.

The Solution: User-Defined Networks

This is the "pro" way to do things in your home lab. You can create your own networks to get three main benefits:

1. Automatic DNS Resolution: Containers can talk to each other using their names (e.g., mysql or api-server) instead of shifting IP addresses.
2. Better Isolation: You can keep your database on a private network and only expose your web server to the outside world.
3. Dynamic Attachment: You can connect or disconnect containers from networks while they are still running.

Networking Cheat Sheet

Here are the commands you will use most often to manage your plumbing:

• Create a network: docker network create my-network
• List all networks: docker network ls
• Connect a running container: docker network connect my-network my-container
• Disconnect a container: docker network disconnect my-network my-container
• Remove a network: docker network rm my-network

Wrapping Up

Understanding the plumbing makes debugging much easier. If your app cannot connect to its database, the first thing you should check is if they are on the same network.

In the next post, we are going to talk about The Memory. We will look at Volumes and Storage to make sure your data does not disappear when a container stops.

Happy Dockerizing!

This is where Docker changed everything.

For me, Docker is the backbone of my home lab. Whether I am managing containers on Proxmox or using Portainer to visualize my stacks, Docker is what keeps my development environment consistent and my production deployments stable.

But Docker is more than just a buzzword. It is a toolset that, when used correctly, makes your life as a developer significantly easier. Over the next few weeks, I am going to break down exactly how Docker works, from the basic plumbing to high level orchestration.

What to Expect in This Series

We are going to go deep into the mechanics of containerization. Here is the roadmap for the upcoming posts:

1. The Plumbing (Networking): We will look under the hood at how containers actually talk to each other and the host machine.
2. The Memory (Volumes & Storage): I will show you how to ensure your data stays safe even if your container is deleted.
3. The Diet (Multi-Stage Builds): We will learn how to shrink your image sizes so your deployments are fast and secure.
4. The Conductor (Docker Compose): This is where we stop running single containers and start building full stack environments with one command.
5. The Guard (Production Best Practices): A final checklist to make sure your containers are hardened and ready for the real world.

Docker has revolutionized how we develop, ship, and run applications. By the end of this series, you will be equipped to containerize any application and deploy it consistently across any environment.

Happy Dockerizing!

Before I had a computer or a home lab, I played with old electronics. I looked for broken radios or old Black & White CRT TVs. To most people, a broken TV was just trash. To me, it was a mystery to solve. I loved taking them apart to see what was inside.

I still remember the smell of dust and old metal when I opened a plastic case. The green circuit boards looked like maps of a tiny city. I would move my finger along the lines on the board. I wondered how a signal moved through the wires to show a picture or play sound. I did not know how to fix them yet, but I loved trying to understand the logic. I tried to fix them; most of the time I learned something new, and sometimes I succeeded. Basically, I never had a failure, because I always learned something.

Today, I have a DevOps home lab at my house. It has servers, Docker, and Proxmox. My toys are now virtual machines and code. The feeling is exactly the same when I get a new service to work. I feel the same joy I felt as a young boy in Dhaka. My childhood taught me how to solve problems. Whether it is an old TV or a modern server, I still love to discover how things work.

Looking back, those broken radios or CRT Tvs were just my first servers, and my homelab today is simply a bigger version of the mystery I've been solving since I was a boy in old Dhaka. My journey started with a screwdriver and a dream, and it comtinues today with a keyboard and a container.

I've deployed a lot of things. Kubernetes clusters, Docker Swarms, managed databases, serverless functions. For my own portfolio, I wanted to do the opposite: deploy nothing.

The result is this site: a portfolio, blog, and content management system that runs entirely in the browser, with GitHub as both the host and the database.

Here's how it works.

The constraints I set for myself

Before writing a single line of code, I fixed the rules:

• No build step. No webpack, vite, or bundler of any kind.
• No framework. Vanilla JS only.
• No backend. No server, no API, no database.
• Single-file pages. Each HTML file owns its own <style> and <script>.
• Three CDN libraries maximum: marked.js for markdown, highlight.js for code, DOMPurify for sanitisation.

The goal was a site I could understand entirely, deploy for free, and edit from any browser without pulling in dependencies that would rot in six months.

The architecture

The stack is four HTML files, two JSON files, and a folder of markdown:

index.html          → portfolio homepage
blog.html           → post listing with search + tag filters
post.html           → single post reader
admin.html          → in-browser CMS

data/config.json    → all portfolio content (source of truth)
data/posts-index.json → blog post metadata

posts/*.md          → blog posts with YAML front matter

GitHub Pages serves everything as static files. The browser does all the work.

GitHub as a database

The most interesting part of this setup is the CMS. It authenticates with a GitHub Personal Access Token (stored in localStorage, never logged, never sent anywhere except api.github.com) and uses the GitHub Contents API to read, write, and delete files directly in the repository.

Reading a file:

async function readFile(path) {
  const res = await fetch(`${API}/repos/${OWNER}/${REPO}/contents/${path}`, {
    headers: apiHeaders()
  });
  if (!res.ok) throw new Error(`Read failed: ${res.status}`);
  const { content, sha } = await res.json();
  return { content: atob(content.replace(/\n/g, '')), sha };
}

Writing a file:

async function writeFile(path, content, sha, message) {
  const body = {
    message,
    content: btoa(unescape(encodeURIComponent(content))),
    ...(sha && { sha }),
  };
  const res = await fetch(`${API}/repos/${OWNER}/${REPO}/contents/${path}`, {
    method: 'PUT',
    headers: apiHeaders(),
    body: JSON.stringify(body),
  });
  if (!res.ok) throw new Error(`Write failed: ${res.status}`);
  return res.json();
}

Two things worth noting here:

The SHA requirement. The GitHub API requires the current file SHA when updating an existing file. If you skip it, you get a 409 Conflict. The CMS caches SHAs in a shaCache object after every read and write, so subsequent saves don't fail.

Unicode-safe base64. Plain btoa() breaks on non-ASCII characters. The pattern btoa(unescape(encodeURIComponent(content))) handles any unicode correctly.

The CMS

The admin panel has three tabs:

Portfolio editor: collapsible sections for bio, skills (add/remove categories and items), projects (expandable blocks with tech tags, bullets, GitHub/live links), and DevOps entries. Saves to data/config.json via the GitHub API. The homepage reads this file and renders everything dynamically, no content is hardcoded in the HTML.

Blog posts: a table of all posts pulled from data/posts-index.json. Each row has edit and delete actions. Delete shows a confirmation overlay, removes the .md file, and updates the index in the same operation.

Post editor: a split-pane markdown editor with:

• A toolbar for common formatting (Bold, Italic, H2, H3, Link, Code, Code Block, List, Quote, HR)
• Live preview with syntax highlighting, debounced 300ms
• Front matter fields (title, date, excerpt, tags) with auto-slug generation
• Draft autosave to localStorage every 30 seconds
• An unsaved-changes warning on beforeunload
• Tab key inserts two spaces instead of moving focus

Saving publishes the .md file and updates the index in sequence. If the index write fails after the post write succeeds, the index is stale but the post file is safe; the next save will retry with the correct SHA.

The post reader

post.html fetches the markdown file directly as a static asset, parses the YAML front matter, and renders with marked.js + DOMPurify. Code blocks get highlight.js applied per-element and per-block copy buttons injected on hover.

The reading progress bar is a CSS width animation driven by the scroll position:

window.addEventListener('scroll', () => {
  const scrolled = window.scrollY;
  const total = document.body.scrollHeight - window.innerHeight;
  progressBar.style.width = `${Math.min(100, (scrolled / total) * 100)}%`;
});

The table of contents is built by scanning the rendered HTML for h2 and h3 elements, assigning deterministic IDs, and tracking the active heading with an IntersectionObserver.

One gotcha: Jekyll

GitHub Pages runs Jekyll by default, which intercepts .md files and tries to render them as HTML instead of serving them raw. The post reader fetches posts/{slug}.md directly; if Jekyll is active, that request 404s.

The fix is a single empty file at the repository root:

.nojekyll

That's it. Jekyll disabled. .md files served as-is.

The design system

Every colour, every spacing decision, every font choice is driven by CSS custom properties. No colour is hardcoded anywhere in the HTML files. The palette:

--color-bg:        #0B1220
--color-surface:   #111827
--color-border:    #1E3A5F
--color-accent:    #2563EB
--color-gold:      #F59E0B
--color-text:      #F1F5F9

Fonts are DM Serif Display for headings, DM Sans for body text, and JetBrains Mono for code and slugs, all loaded from Google Fonts with display=swap.

What I'd do differently

Caching. The site uses sessionStorage to cache config.json and posts-index.json on first load. This avoids redundant fetches but means content changes don't propagate until the cache is cleared. A smarter approach would be to version-stamp the cached data and invalidate it after a known write.

Conflict handling. If two browser tabs edit the same file simultaneously, the second write will fail with a 409. The CMS surfaces the error but doesn't auto-resolve it. Good enough for a single-author site.

No markdown in the portfolio editor. The bio field is plain text. Skills, project descriptions, and bullets are all plain strings. This was a deliberate simplification; the complexity of a rich-text or markdown editor in that tab wasn't worth it for fields that rarely change.

The result

A portfolio and blog that loads in under a second, costs nothing to run, requires no deployment pipeline, and can be edited from any browser with a PAT. Every post is a markdown file in a git repository. Every change is a commit.

The whole thing is about 160KB of source code: four HTML files, two JSON files, a handful of markdown posts. No node_modules. No lockfile. No build artefacts.

I think that's the right size for a personal site.

This is the exact workflow I use on every project. No fancy orchestration, just Docker Compose, Nginx, and Let's Encrypt running on a plain Ubuntu VPS.

Prerequisites

• A VPS running Ubuntu 22.04 (I use Linode or DigitalOcean)
• A domain pointed at your server's IP
• Docker and Docker Compose installed

1. Containerise your app

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

Build and test locally:

docker build -t myapp .
docker run -p 3000:3000 myapp

2. Docker Compose setup

version: '3.8'
services:
  app:
    image: myapp:latest
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - DATABASE_URL=${DATABASE_URL}
    networks:
      - web

  nginx:
    image: nginx:alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./certs:/etc/letsencrypt
    depends_on:
      - app
    networks:
      - web

networks:
  web:

3. Nginx configuration

server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://app:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

4. SSL with Let's Encrypt

apt install certbot
certbot certonly --standalone -d yourdomain.com

Set up auto-renewal:

crontab -e
# Add: 0 3 * * * certbot renew --quiet && docker compose restart nginx

5. Zero-downtime deploy script

#!/bin/bash
docker pull myapp:latest
docker compose up -d --no-deps app
echo "Deployed at $(date)"

That's it. Simple, reliable, and you own the whole stack.

Why not Medium or Dev.to?

I've written on both. They're fine platforms, but I kept running into the same friction: I don't own the content, the URL changes when I move, and the reading experience is buried under popups asking me to sign up.

I wanted something different:

• Full ownership. My words, my domain, my git history.
• Zero bloat. No tracking, no paywall prompts, no "upgrade to Medium Partner" banners.
• Built by me. I'm a developer. Building my own tools is how I learn what I actually believe.

What this blog is

This is a technical blog, mostly. I'll write about what I'm building and what I'm learning: Node.js, Docker, PostgreSQL, Next.js, Nginx, VPS setups, SaaS architecture, and the occasional tool I've built that other people might find useful.

I won't write about things I haven't actually done. Every post here will be grounded in something I've shipped, debugged, or deployed in production.

What this blog is not

• It's not a growth hack.
• It's not SEO content written to rank for keywords.
• It won't have a newsletter popup. Ever.

How it's built

The irony is that this blog is itself a project I'll probably write about. It's a fully static GitHub Pages site with no build step, no framework, no backend. Vanilla JS reads markdown files from the repo and renders them in the browser. A lightweight in-browser CMS handles editing via the GitHub API.

Simple. Owned. Fast.

If something I write helps you ship something, that's enough. Welcome.