DEV Community: Dowithsudo

Proxmox: Compromised VM vs Hypervisor

Dowithsudo — Fri, 14 Aug 2026 18:41:43 +0000

There is a certain pride and peace of mind when looking at a Proxmox Virtual Environment (PVE) dashboard with all green status indicators. The cluster is healthy, Ceph storage synchronization is smooth, weekly backups run without errors, and most importantly public internet access to management port 8006 has been completely sealed off with a hardware firewall in front of it.

As an admin, I thought that fortress was impenetrable. My logic was simple: "Who can get in and mess up the cluster configuration if all management ports are tightly closed from public access?"

However, the reality in the field often slaps us hard. That morning, the cluster security logs showed an anomaly that made the hair on the back of my neck stand up, there were thousands of failed login attempts to the user root@pam.

The question was: Where were they coming from?

I immediately checked the attacker's source IP. It wasn't an IP from China, Russia, or some other country. It was a local subnet IP 192.168.x.x. My heart raced as I realized the terrifying fact. That IP belonged to one of the client's Virtual Machines (VM) running inside that very Proxmox node.

I realized I had made a fatal mistake common among beginners and careless seniors alike assuming the internal network (LAN) is a safe zone free from threats.

I forgot that the biggest threat to a Hypervisor is often not a genius hacker breaching the perimeter firewall from across the ocean, but a "roommate", a VM that has been compromised by bad actors.

The illusion of internal security

Let's dissect the scenario. This attack scenario is very simple, requires no sophisticated tools, but the impact is deadly.

Entry Point: A VM running a web server (e.g., Ubuntu Server with WordPress) gets hacked. The cause is classic, outdated plugins, weak admin user passwords, or poor upload filters. The hacker gets in and gains shell access on that VM.
Reconnaissance: From inside the compromised VM, the hacker performs simple network scanning using nmap or even a ping sweep of the local subnet.
Discovery: The hacker finds the gateway IP or the Proxmox host IP residing on the same network bridge (vmbr0) subnet.
Attack: Because the default Proxmox installation often leaves management port 8006 open to all interfaces on bridge vmbr0, the hacker can see our Proxmox login page from inside the VM.

From this point, it's just a matter of time. They can run a password brute force against the Proxmox root account without being blocked by external firewalls (since the attack is coming from "inside"), or exploit unpatched PVE vulnerabilities.

If they manage to breach the Hypervisor level, it is Game Over.
They can delete all VMs, steal backups, format storage, or plant ransomware at the host level that will lock the entire company infrastructure.

This reminds me of the basic defense principles I wrote about in Linux Server Hardening Best Practices: never trust default settings, even on internal networks.

Isolating the "bad apples" with vlans

This incident taught me an expensive lesson, we must treat every VM as if it were a potential enemy. Zero Trust Architecture is not just vendor marketing jargon, it is an absolute necessity in the cloud computing era.

After that incident, I completely overhauled my virtualization network architecture. Here are the practical steps I implemented that saved me in subsequent incidents:

Separate management path and guest traffic

Never let user VM traffic mix (same subnet/same bridge) with the Proxmox management interface. Separate them physically or logically using VLANs (Virtual LANs).

VLAN 10 (Management): Strictly for Proxmox Host IP, iDRAC/IPMI. Accessible only from the Admin laptop or a dedicated VPN.
VLAN 20 (VM Public): Strictly for VM internet traffic.
VLAN 30 (VM Private/DB): Strictly for backend database communication.

With this separation, even if a VM in VLAN 20 is hacked, the hacker inside cannot ping or see the Proxmox management IP in VLAN 10. The path is cut off at the switch or router level.

Internal network attack cases like this share a similar pattern with DDoS attacks I discussed in the DDoS Mikrotik Case Study, where traffic separation is the key to mitigation.

Activate firewall at datacenter/node level

Proxmox VE has an incredibly powerful built-in firewall feature (pve-firewall) integrated directly into the Linux kernel. Unfortunately, this feature is often turned off or untouched by admins out of "fear of misconfiguration" that could lead to a lockout (admin locked out of their own server).

Don't be afraid. Turn it on!
The safest strategy is to create "Whitelist" rules at the Datacenter or Node level.

Example safe Proxmox firewall logic:

Drop by Default: Set Input Policy to DROP.
Allow Management IP: Allow ports 8006 (GUI) and 22 (SSH) ONLY from the static source IP of the admin laptop or office VPN IP.
Drop Internal: Ensure DROP rules catch traffic from VM subnets.

# Rule logic illustration (not copy-paste command):
IN ACCEPT -p tcp --dport 8006 -s 192.168.10.5 (Admin Laptop)
IN ACCEPT -p tcp --dport 22 -s 192.168.10.5
IN DROP -p tcp --dport 8006 -s 0.0.0.0/0 (Deny all else)

With these rules, even if a hacker inside a VM can "see" the Proxmox Host IP, their request packets to port 8006 will be immediately discarded by the host kernel firewall.

Important Tip: Before applying DROP rules on management ports, ensure you have physical access (monitor+keyboard) or IPMI access to the server. Just in case you accidentally block yourself.

Never trust "localhost"

Security is layered (Defense in Depth). Securing Proxmox from public internet access is just step 1. Securing it from "backstabbing" attacks by its own VMs is step 2, which is often forgotten due to excessive trust in internal networks.

This case changed my mindset to be more paranoid in a positive way. Client VMs can be compromised at any time. App bugs can appear at any time.
My job as a sysadmin isn't to ensure the system is 100% unbreachable (because that's impossible), but to ensure that even if one hotel room catches fire, the flames won't burn down the whole building, and most importantly won't burn down the main control room.

Detecting internal reconnaissance

How do you know if one of your VMs is actively probing the hypervisor? Look for these telltale signs.

Check hypervisor access logs

Proxmox logs every authentication attempt. If you see repeated failed logins from an unexpected internal IP, investigate immediately.

grep 'proxmox.*authentication failure' /var/log/syslog | awk '{print $NF}' | sort | uniq -c

This command shows the source IPs of failed auth attempts. If you see VM subnet IPs here, you have a compromised guest.

Monitor bridge traffic

Install fail2ban or crowdsec on the Proxmox host, configured to detect port scanning patterns originating from bridge interfaces.

iptables -I INPUT -i vmbr0 -p tcp --dport 8006 -m state --state NEW -j LOG --log-prefix "PVE-ACCESS: "

Audit SSH key trust

A common pivot technique is stealing SSH private keys from a compromised VM and using them to access the host. Regularly rotate keys and enforce passphrase protection.

Once an attacker holds SSH keys, moving between servers is only a matter of technique. I walked through a complete Linux server pivot attack scenario on a real network.

Recreating the attack: a minute by minute timeline

To make the risk concrete, here is how the whole incident played out from the attacker's point of view. It is uncomfortable to read, and that is exactly the point.

Day 0, 14:02. The attacker exploits an outdated WordPress plugin on the client's web VM. It is a known CVE with a published exploit script. No special skills required, just reading.

Day 0, 14:11. Shell access is confirmed. The attacker runs ip a and sees the VM sits on 192.168.1.0/24. Next, a quick ping sweep maps every live host on that subnet, including the Proxmox host at 192.168.1.2.

Day 0, 14:19. curl http://192.168.1.2:8006 returns the Proxmox login page. The management interface is reachable from the guest network because the default install binds to all interfaces.

Day 0, 14:20 to 03:40. A brute force runs against root@pam. Four hours later, one credential from a reused password finally matches. The attacker is now the hypervisor administrator.

Day 1, 09:00. Backups are mounted and exfiltrated. Two production VMs are deleted as a proof of impact. The company does not know until users start complaining.

Every step after the first one was preventable. The exploit happened, but the lateral movement, the brute force, and the final breach were all enabled by network design decisions, not by luck.

Prevention checklist

Before deploying any VM on your Proxmox cluster, run through this. These controls sit on top of the Linux security fundamentals I cover in basic Linux for system administrators.

VM is on a dedicated VLAN, never on the same bridge as management
Host firewall enabled, pve-firewall with DROP default policy
Management access restricted, port 8006 and 22 only from admin IP or VPN
VM cannot reach host IP, test with ping and curl from inside each VM
Backups are network-isolated, separate storage network from management VLAN
IDS/IPS on internal traffic, monitor bridge traffic for anomalies

If you cannot confidently check all six, your hypervisor has a gap.

Control to prevention mapping

Control	What it blocks	Where to configure
VLAN separation	Lateral movement to management network	Switch/router, vmbr bridges
`pve-firewall` DROP default	Any traffic to management ports from guests	Datacenter → Firewall → Options
Source IP allowlist (8006/22)	Brute force from anywhere but admin IP	Node firewall rules
SSH key rotation + passphrase	Pivot using stolen keys	`~/.ssh/authorized_keys`, key management
Network-isolated backups	Ransomware at host level deleting backups	Separate storage VLAN, immutable snapshots
IDS/IPS on bridge traffic	Reconnaissance and port scans	fail2ban, crowdsec, log monitoring

Each row answers three questions at once: what the attacker loses, where you turn it on, and why it matters. If a control is not implemented, write down the risk it is supposed to cover. Unmanaged risk has a way of introducing itself.

Final verification

Check your Proxmox firewall configuration now. Access one of your VMs, open the terminal, and try to ping or curl https://<PROXMOX-Host-IP>:8006.
If the status is "Reply" or the login page appears in that VM's terminal? Congratulations, you have homework tonight before bed.

I hope this guide on Proxmox VM attack helps you make better decisions in real-world situations.

Linux Server Hardening Best Practices

Dowithsudo — Fri, 14 Aug 2026 18:40:11 +0000

I remember clear as day the first time I rented a cheap VPS for my personal projects. With the excitement of many beginners, I installed Linux, set a mediocre root password, and left it running overnight.

The following morning, out of curiosity, I checked the system logs. My eyes widened as I saw thousands of failed SSH login attempts from random IP addresses across the globe. Thousands of bots were hammering away at my server's door every single second. It was a wake-up call. Running a server on the public internet without proper security is like leaving your front door wide open in a crowded city.

Server hardening isn't just a theoretical topic in a cybersecurity textbook. It's the primary line of defense between your data and a world full of bots. These are the steps I actually run in production, refined over years of managing real servers.

Why does server hardening actually matter?

By default, most Linux distributions are configured for ease of access. This is great for learning on local machines, but dangerously porous for servers exposed to the internet.

This guide assumes you're comfortable on the command line. If you're still building your Linux fundamentals, my Basic Linux System Administration guide covers the essentials you'll need before you harden anything.

The core goal of Server Hardening is to reduce the Attack Surface. Imagine your server as a building. A building with 50 unguarded doors is much easier to breach than one with a single heavily guarded entrance.

Hardening is the ongoing process of closing unnecessary doors, replacing weak locks with military-grade ones, and setting up surveillance in every corner. It's about being proactive rather than waiting for an incident to happen.

Step 1: securing the main entrance (SSH hardening)

SSH (Secure Shell) is the gateway to your server. Because it's the main entry point, it's also the first place attackers will try to break into.

The very first task I perform on any new server is tightening the configuration in /etc/ssh/sshd_config.

Stop using passwords: move to key-based auth

Passwords, no matter how complex, can eventually be cracked via brute force. SSH Keys are virtually impossible to guess. If you aren't using keys, you aren't really secure.

Disable root login and password authentication

Once I've verified my SSH key works, I immediately shut down the ability to log in as root and disable password authentication entirely.

My recommended SSH configuration looks like this:

# Edit /etc/ssh/sshd_config
# Find and modify these parameters:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

After saving the changes, remember to restart the service:
sudo systemctl restart ssh

Operator's Perspective: Many recommend changing the default SSH port (22) to something non-standard, like port 2222. While this isn't "impenetrable security," it is remarkably effective at cutting log noise by stopping millions of automated scanners that only target the default port.

Extra SSH hardening people forget

Additional sshd_config parameters that tighten access:

AllowUsers adminops deploy
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no

What they do:

AllowUsers: only specific users can SSH.
LoginGraceTime: limit login time.
ClientAlive*: drop idle connections.
X11Forwarding and AllowTcpForwarding: disable if not needed.

Validate and reload:

sshd -t
sudo systemctl reload ssh

Step 2: the principle of least privilege (user management)

In security, less is more. Users should only have the permissions absolutely necessary to do their jobs.

Never use the root account daily

Always create a standard user account with sudo privileges. This prevents you from accidentally running a destructive command as root and provides an audit trail of who ran what command.

# Add a new user
sudo adduser danu

# Grant sudo privileges
sudo usermod -aG sudo danu

Make it a habit to audit your user list regularly and remove any accounts belonging to people no longer on the project.

Step 2.1: sudoers and access audit

Don't grant blanket sudo. Use visudo and scope privileges:

sudo visudo

Example rules:

%admin  ALL=(ALL) ALL
deploy  ALL=(ALL) NOPASSWD:/bin/systemctl restart nginx

Here, deploy can only restart Nginx, not perform full root access.

Step 3: placing the perimeter fence (firewall)

If your server is a house, the firewall is the perimeter fence. It ensures that only traffic you've explicitly invited can get through.

For Ubuntu or Debian systems, I swear by UFW (Uncomplicated Firewall). It's simple, powerful, and hard to mess up.

# Deny everything by default
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Only open what you need
sudo ufw allow 22/tcp    # SSH
sudo ufw allow 80/tcp    # HTTP
sudo ufw allow 443/tcp   # HTTPS

# Turn it on
sudo ufw enable

You can verify your security posture by checking which services are actually listening for connections:

sudo ss -tulpn

If you see an app listening on a port you didn't know about, that's a red flag you need to investigate immediately.

Firewall advanced: rate limits and default deny

UFW is simple, but underneath it's iptables/nftables. Add rate limiting to slow brute-force attempts:

sudo ufw limit 22/tcp

If you need full control, consider managing rules directly with nftables.

For network-level floods like DDoS, the perimeter defense needs its own playbook. I walked through a real-world MikroTik DDoS case study where traffic separation was the key to keeping services up.

Step 4: automating defense with fail2ban

Even with keys and firewalls, bots will still hammer your server. Fail2ban is the bouncer that kicks them out.

It monitors your authentication logs and, after a few failed attempts, it automatically bans that IP address at the firewall level for a certain period. Simple, yet incredibly effective.

sudo apt install fail2ban

A common configuration I use in jail.local is banning an IP for 24 hours after 3 failed attempts. It makes your server a very unappealing target for automated scripts.

Step 5: kernel hardening with sysctl

Some kernel parameters reduce network attack surface:

sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
sudo sysctl -w net.ipv4.conf.all.rp_filter=1
sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
sudo sysctl -w net.ipv4.conf.all.accept_redirects=0

To persist settings, add them to /etc/sysctl.d/99-hardening.conf and run:

sudo sysctl --system

Step 6: security through maintenance (patching)

Security is not a "set it and forget it" task. New vulnerabilities are discovered daily. An unpatched server is a ticking time bomb.

I highly recommend enabling Unattended Upgrades. This allows your server to automatically download and install security patches the moment they're released.

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

This simple setup ensures that even when you're on vacation, your server is protecting itself against newly discovered exploits.

Step 7: observability and log monitoring

Security is as much about detection as it is about prevention. You need to know when someone is knocking.

Take a peek at your auth logs every now and then:

sudo tail -f /var/log/auth.log

You'll be surprised at how active the "war" is on the internet. Additionally, a solid backup strategy is part of a security mindset. Backup isn't a preventative measure per se, but it's your only lifeline if your security layers fail or data is corrupted.

Extra recommendations:

Auditd for system activity auditing:

  sudo apt install auditd
  sudo systemctl enable --now auditd

AIDE for file integrity monitoring:

  sudo apt install aide
  sudo aideinit

Centralized logging (ELK/Graylog/Cloud logging) so logs survive even if a server dies.

My personal server hardening checklist

Whenever I spin up a new node, I run through this checklist (or use my interactive hardening checklist tool to verify each item):

[ ] Update all system packages.
[ ] Create a non root sudo user.
[ ] Set up SSH keys and disable password auth.
[ ] Disable root login in SSH config.
[ ] Configure firewall rules (allow 22, 80, 443).
[ ] Install and configure Fail2ban.
[ ] Apply baseline sysctl hardening.
[ ] Enable automatic security updates.
[ ] Enable audit/log monitoring (auditd/central logging).
[ ] Disable unused network services.

What hardening does not solve

There's a major trap to avoid: Hardening the server doesn't fix a broken application. If you secure your Linux OS perfectly but your web application has an unsanitized input leading to SQL Injection, or your app password is admin123, an attacker can still pwn your system through the app layer.

Hardening secures the "container." The content of that container (your code) is still your responsibility as a developer.

And if an attacker does breach the app layer, your hardened server becomes a foothold for moving deeper into the network, exactly what I demonstrate in the Linux server pivot attack case study.

Conclusion

Early in my career, I viewed these steps as tedious chores. Now, they are a mandatory ritual my price of admission to the internet. Spending an extra 15 minutes during deployment saves me days of headaches later.

Security is a journey, not a destination. Stay curious, watch your logs, and never stop refining your defense layers.

Hardening is the first step. Make sure you also understand how to troubleshoot production when issues arise, as I discuss in my Docker container crash case study and LVM storage failure case study.

Do you have a specific ritual when you set up a new server? Or a "war story" that changed how you view security? Let's hear about it in the comments below! Happy (and safe) hosting!

I hope this guide on Linux server hardening helps you make better decisions in real-world situations.

Learning Docker: A Beginner Guide

Dowithsudo — Fri, 14 Aug 2026 18:35:22 +0000

Have you ever experienced this classic scenario? You write code on your laptop, and everything runs perfectly. But the moment you hand it over to a colleague or deploy it to a server, everything crashes. And then comes the legendary excuse "But it works on my machine!"

It's frustrating, right? The problem is often not your code, but the environment. Maybe the Node.js version is different, the database config doesn't match, or the OS is a different distro.

Enter Docker. It exists to solve this environment drama once and for all. If you are in IT, whether as a Sysadmin or a Developer, Docker is no longer just a "nice to have" skill. It's a necessity.

So here is what Docker is, why it's everywhere, and how to use it, step by step, with a clear technical focus.

What is Docker, really?

Ideally: Docker is Tupperware for your applications.

Imagine you want to deliver food (your app) to a friend's house (the server). If you carry the food on an open plate while riding a motorcycle, it might spill or get dusty by the time you arrive.

But if you seal that food in a Tupperware container, you can transport it by bike, car, or plane, and it will arrive safe, intact, and tasting exactly the same.

In the tech world, Docker "wraps" your application along with everything it needs (libraries, configs, dependencies) into a neat package called a Container.

Containers vs. virtual machines (vm)

You might be thinking, "Wait, isn't that what VMs (like VirtualBox/VMware) do?"

Similar goal, but very different approach.

Virtual Machine (VM): Heavy. Each VM requires a full OS installation (Guest OS). So if you have 3 apps, you need 3 full copies of Windows/Linux running. This eats up RAM and CPU.
Docker Container: Lightweight. Containers share the host OS kernel. You don't need to install a new OS inside, you just pack the application binaries. Boot time is seconds, not minutes.

How Docker works (short but technical)

Docker relies on two core Linux features:

Namespaces: isolate processes, network, filesystem, and users so containers feel like mini-VMs.
Cgroups: control resource limits (CPU, RAM, I/O) so one container can't hog the host.

Docker images are built from layers. Each Dockerfile instruction creates a new layer, which enables caching and faster rebuilds.

Key components:

Docker Engine: dockerd daemon that manages images, networks, volumes.
Container runtime: executes containers (OCI runtime like runc).
Registry: stores images (Docker Hub, private registry).

Installing Docker

Docker runs everywhere. Linux, Mac, Windows.

Linux (Ubuntu):

  curl -fsSL https://get.docker.com -o get-docker.sh
  sudo sh get-docker.sh

Windows/Mac: Download Docker Desktop from the official website. It's a simple install wizard.

Verify installation:

docker --version

Your first container

Let's try running an Nginx web server. No need to install Nginx on your actual laptop, just summon it with Docker.

docker run -d -p 8080:80 nginx

Deciphering the spell:

docker run: The command to start a container.
-d (detached): Run in the background (don't lock up my terminal).
-p 8080:80: Port mapping. Port 8080 on your laptop connects to port 80 inside the container.
nginx: The name of the image to use.

Now open your browser and go to http://localhost:8080.
Boom! Welcome to nginx!. You just ran a web server without polluting your operating system.

Critical concepts: image vs container

Beginners often get these mixed up.

Image: This is the "blueprint" or raw file. It is Read Only. (Think Windows Installer .iso)
Container: This is the actual running instance created from the Image. It is Read Write (ephemeral). (Think A laptop with Windows installed).

Commands you must memorize:

Download an image: docker pull ubuntu
List images you have: docker images
List running containers: docker ps
Stop a container: docker stop <CONTAINER_ID>

Layers and cache: why dockerfile order matters

Dockerfile is not just a recipe list. Order affects speed and rebuild time.

Efficient pattern:

copy package.json first
install dependencies
then copy application code

That way, when only code changes, Docker reuses cached dependency layers.

Helpful commands:

docker build --no-cache .: rebuild without cache.
docker history <image>: inspect layer sizes.

Building a custom image (dockerfile)

Using someone else's image (Nginx) is easy. But how do you package your own app? You use a file called Dockerfile.

Suppose you have a simple Node.js app (app.js). Create a file named Dockerfile (no extension) in the same folder:

# 1. Start from a base image (OS + Node.js)
FROM node:18-alpine

# 2. Set working directory inside container
WORKDIR /app

# 3. Copy your package.json first
COPY package.json .

# 4. Install dependencies
RUN npm install

# 5. Copy the rest of your app code
COPY . .

# 6. Tell Docker which port this app uses
EXPOSE 3000

# 7. Command to run when container starts
CMD ["node", "app.js"]

Now let's "cook" this recipe into an Image:

docker build -t my-app:v1 .

-t: Tag/Name the image (my-app version 1).
.: Location of the Dockerfile (dot means current directory).

Run your new creation:

docker run -p 3000:3000 my-app:v1

Data persistence (Docker volumes)

By default, if you delete a container, all data inside it is gone forever.
Imagine running a MySQL database in a container. You fill it with data all day. Then you delete the container. When you run it again, the database is empty. Nightmare fuel.

The solution: Volumes.
A Volume is like a USB drive plugged into the container. Even if the container is destroyed, the data in the volume stays safe on your laptop.

Using a volume:

docker run -v mysql_data:/var/lib/mysql mysql

Now MySQL data will be stored in a volume named mysql_data managed by Docker. Safe and sound.

Bind mount vs volume: which one to use?

Two ways to persist data:

Volume: managed by Docker, stable, production-friendly.
Bind mount: map a host folder into a container, great for development.

Example bind mount:

docker run -v $(pwd):/app node:18-alpine

Rule of thumb:

Development: bind mount.
Production: volume or external storage.

Networking: ports, bridges, and debugging connectivity

By default, containers are attached to a bridge network with internal IPs.

Useful commands:

docker network ls: list networks.
docker network inspect <name>: see which containers are attached.
docker port <container>: check port mappings.

Network modes:

bridge: default and safe.
host: container uses host network (fast, less isolation).
none: no networking at all.

Docker compose: orchestrating containers

Modern apps rarely stand alone. You usually have a Web App + Database + Redis.
Running them one by one with docker run is tedious and hard to memorize.

Meet Docker Compose. We can define all containers in a single docker-compose.yml file.

Example docker-compose.yml for WordPress + MySQL:

version: "3.8"

services:
  db:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: super_secret_password
      MYSQL_DATABASE: wordpress

  wordpress:
    image: wordpress:latest
    ports:
      - "8000:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: super_secret_password
    depends_on:
      - db

volumes:
  db_data:

To run everything, you just need one command:

docker-compose up -d

Docker will automatically download images, set up a network so WordPress can talk to MySQL, and start everything up. Simple, elegant.

Debugging containers: a must-have habit

Commands that save you in production:

docker logs <container>: view app logs.
docker exec -it <container> sh: get a shell inside.
docker inspect <container>: full config view.
docker stats: realtime resource usage.

Check exit codes when a container dies:

docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.ExitCode}}"

Common beginner mistakes

Forgetting to Expose Ports: Container running but can't access it? You probably forgot -p 8080:80. Containers are isolated. You must "poke a hole" in the wall to let traffic in. Just be careful which holes you poke. For a safer way to expose services, see my comparison of Cloudflare Tunnel vs port forwarding.
Mounting Code in Production: In dev, we often bind mount code (-v ./code:/app) so we don't have to rebuild on every edit. But for production, don't do this. Copy the code into the image (COPY) so it's immutable and consistent.
Layer Caching: Order matters in Dockerfile. Always copy package.json and run npm install BEFORE copying the app code (COPY . .). This way, if you only change code, Docker doesn't need to reinstall npm packages from scratch (it uses cache).
Running as Root: Create a non-root user in your Dockerfile (USER node for example).
No Resource Limits: In production, set --memory and --cpus so one container doesn't starve the host.

Want to see how these mistakes can cause chaos in production? Check out my real-world Docker troubleshooting case study based on an actual incident.

What's next?

Congratulations! You understand Docker basics. From here, the DevOps world opens up. When you are ready for the full journey from your first container to production hardening, my Docker complete guide is the natural next step after this tutorial.

Your next steps:

Deploy Docker to a VPS (DigitalOcean/AWS). I documented a full production deployment of a MERN application to DigitalOcean in the MERN migration case study.
If the whole cloud/DevOps landscape feels overwhelming, my cloud learning tips for beginners shows how to build skills step by step without burning out.
Learn CI/CD (automate building images when you push to GitHub).
If you have hundreds of containers, look into Kubernetes (but save that for later, don't rush).

When you take Docker to production across both on-premise and cloud infrastructure, the deployment strategy changes. I walked through a real zero-downtime migration using containerized workloads in a hybrid cloud migration case study, including blue-green cutover.

Remember, errors are your friends. If you get stuck, docker logs <container_id> is your best buddy. Happy containerizing!

I hope this guide on Docker basics helps you make better decisions in real-world situations.

Email Deliverability: SPF DKIM DMARC

Dowithsudo — Fri, 14 Aug 2026 18:34:54 +0000

My client called me with a frustration I had heard before but rarely this severe. "Our invoices land in spam. All of them. Customers are missing payments, blaming us, and our finance team is drowning in manual follow-ups."

They were on InMotion Hosting, a shared hosting plan. The client had already done the homework. SPF record was set. DKIM was enabled. DMARC was publishing a p=quarantine policy. On paper, everything looked textbook. But every email sent to Gmail, Outlook, or Yahoo landed squarely in the spam folder.

I asked the client to send a test email and forward me the full headers. This is where the story starts. Not at the DNS zone editor. Not at the hosting control panel. At the raw email headers.

The moment I saw the headers

The email headers told a story that no DNS checker could reveal.

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of billing@clientdomain.com designates 198.186.128.0/24 as permitted sender) smtp.mailfrom=clientdomain.com;
       dkim=pass header.i=@clientdomain.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=clientdomain.com

All three checks passed. SPF pass. DKIM pass. DMARC pass. Yet Google still slapped a quarantine disposition. That should not happen. When all three pass, delivery is supposed to follow.

Unless something deeper is at play.

I compared the headers with known good email headers from a properly configured mail server. Four differences stood out. One of them was the smoking gun. But finding it required understanding three things most sysadmins never look at: shared IP reputation, SPF alignment vs header alignment, and Forward-Confirmed Reverse DNS.

The three hidden culprits

After hours of digging through headers, DNS records, and bounce logs, I traced the root cause to three distinct issues. No single one would have caused the problem alone. Together, they created a perfect storm against inbox delivery.

Shared IP reputation poisoning

InMotion Hosting uses shared IP addresses for outgoing mail on standard shared plans. This means the same IP that sends my client's invoices also sends emails from hundreds of other tenants.

Somewhere in that pool, one tenant runs a newsletter campaign with poor list hygiene. Another forwards spam. Another gets compromised and starts blasting phishing emails. This is the same class of problem I see in internal network attacks, where one compromised machine poisons the reputation of everything behind it. I covered a similar scenario in the Proxmox VM attack case study, where a single compromised VM threatened the entire hypervisor.

When enough abuse reports accumulate against that IP, Google and Microsoft add it to their reputation databases. My client's perfectly crafted emails then inherit that reputation by association. It does not matter how clean their domain is when the sending IP is flagged.

# Check IP reputation with DNSBL
dig +short 2.0.0.127.b.barracudacentral.org

# Check against Spamhaus
dig +short 2.0.0.127.zen.spamhaus.org

The response for our IP came back positive. The shared IP was listed on two DNS blocklists.

SPF alignment versus header from alignment

This one catches most people. SPF uses the smtp.mailfrom address, also called the envelope sender or return-path. This is often a different address than the From: header your recipient sees in their email client.

When a hosting provider sends email, the envelope sender might be something like bounce@inmotionhosting.com while the visible From: header shows billing@clientdomain.com. SPF checks the envelope sender. It does not check the visible from.

Even with SPF=pass, the alignment can fail because smtp.mailfrom domain and header.from domain do not match. This mismatch means SPF alignment fails. Google and Outlook use alignment as a signal, not just the raw pass or fail.

# Example of misaligned headers
smtp.mailfrom: bounce@inmotionhosting.com     ← SPF checks this
header.from: billing@clientdomain.com          ← User sees this

These domains must match for full alignment. When they do not, the email loses credibility in the eyes of the receiving MTA.

Missing Forward-Confirmed Reverse DNS

Forward-Confirmed Reverse DNS is a PTR record that maps the sending IP back to a hostname, and that hostname must resolve forward to the same IP.

This is the most overlooked DNS record for email deliverability. Gmail and Outlook both check it. If a PTR record is missing or does not match, the receiving server flags the email as potentially forged. You can verify all of these records (SPF, DKIM, DMARC, PTR, and MX) for any domain with the DNS health check tool.

My client's sending IP had no PTR record at all.

# Check PTR record for sending IP
dig +short -x 198.186.128.xxx

# Response: empty. No PTR record configured.

Without a valid PTR that matches the HELO/EHLO hostname, deliverability drops significantly.

The remediation roadmap

Fixing this required changes at three layers: DNS, hosting plan, and email configuration. Each step had to be sequenced carefully to avoid downtime or bounced emails.

Step one: dedicated IP and PTR record

The first call was to InMotion Hosting support. I requested a dedicated IP address for outgoing mail. This immediately isolated my client from the shared IP reputation pool.

Request: Dedicated IP for SMTP outbound
Provider: InMotion Hosting
Timeline: Activated within 4 hours
IP: 198.186.128.xxx (dedicated, not shared)

Once the dedicated IP was assigned, I submitted a reverse DNS request. The PTR record needed to match the hostname used in the HELO/EHLO handshake.

# PTR record requested
198.186.128.xxx → mail.clientdomain.com

# Verification after propagation
dig +short -x 198.186.128.xxx
# mail.clientdomain.com

dig +short mail.clientdomain.com
# 198.186.128.xxx

Forward and reverse matched. The first check passed.

Step two: IP warmup strategy

A brand new dedicated IP has no reputation at all. A cold IP sending legitimate email volume is suspicious. A sudden flood triggers rate limiting and spam placement.

"An IP with no history is treated the same as an IP with bad history. The receiving server does not know which one you are yet."

I planned a two-week warmup schedule.

Week 1: Send only transactional emails (invoices, receipts), 50-100 per day
         Delay non-urgent marketing emails
Week 2: Gradually increase volume, 300-500 per day
         Monitor delivery in postmaster tools
Week 3+: Resume full volume, monitor reputation

I used Google Postmaster Tools and Microsoft SNDS to track reputation daily. The first week showed neutral reputation. By the end of week two, the dedicated IP reached green status on both platforms.

Step three: header alignment fix

SPF alignment required that smtp.mailfrom and header.from share the same domain. I updated the mail server configuration to use the client's own domain in the envelope sender.

// Example PHP mailer configuration for alignment
$mail->setFrom('billing@clientdomain.com', 'Client Billing');
$mail->addReplyTo('support@clientdomain.com', 'Client Support');
// Ensure return-path matches the domain
$mail->Sender = 'bounce@clientdomain.com';

And added a dedicated SPF record for the new sending IP:

# Updated SPF record
clientdomain.com TXT "v=spf1 include:mx.inmotionhosting.com ip4:198.186.128.xxx -all"

The -all hard fail at the end is critical. Many hosting providers default to ~all (soft fail), which tells receiving servers to treat unauthenticated email as suspicious but not reject it outright. Hard fail forces strict enforcement.

Step four: DMARC reporting and monitoring

DMARC was already set to p=quarantine, which was part of the problem. With misalignment and low IP reputation, DMARC was dutifully enforcing quarantine. I switched it to p=none temporarily during the warmup period, then moved to p=quarantine once alignment was confirmed.

# Temporary monitoring mode
_dmarc.clientdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@clientdomain.com"

# After verification
_dmarc.clientdomain.com TXT "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@clientdomain.com"

DMARC aggregate reports came weekly. They confirmed SPF and DKIM pass rates above 99%, with alignment at 100% after the envelope sender fix.

The results

We measured deliverability before and after the changes. The improvement was immediate and sustained.

Metric	Before	After	Change
Inbox placement rate (Gmail)	12%	98%	+86pp
Inbox placement rate (Outlook)	8%	95%	+87pp
Spam complaint rate	0.2%	0.03%	-85%
Bounce rate	4.5%	0.8%	-82%
IP reputation (Google)	Neutral	Green	N/A
DNSBL listings	2 listings	0 listings	Clean

The client's finance team stopped getting calls about missing invoices within three days of the dedicated IP activation. By day five, all major providers delivered to inbox.

Lessons for sysadmins

This case reinforced three principles I now apply to every email deliverability engagement.

SPF, DKIM, and DMARC are table stakes, not guarantees. They are necessary but not sufficient. A shared IP with bad reputation bypasses all three. Always check the sending IP reputation before touching DNS records.

Headers do not lie. DNS checkers do. Online SPF and DKIM checkers only verify record syntax. They do not check alignment, PTR, or SMTP handshake configuration. The true story is in the email headers. Learn to read them.

A dedicated IP is not optional for transactional email. Shared hosting IPs are a gamble. If you send invoices, receipts, or any customer-facing email with authentication requirements, a dedicated IP is not a premium feature. It is the baseline.

"The authentication passed. The email still failed. That is the moment you stop trusting the checkboxes and start reading the headers. The same principle applies to server security. You can configure a firewall, disable root login, and set up fail2ban. But if you never check the logs, you are trusting checkboxes. I wrote about this in the Linux server hardening guide. A configuration you never verify is a configuration that might not work."

If you run into a similar issue, start with three commands: dig for PTR, dig for DNSBL, and a raw email header view. The answers are always in the protocol. You just have to look past the control panel.

Six months later, the client's deliverability is still above 97%. They moved to a dedicated IP permanently. The invoices land in inboxes. The finance team stopped calling me. That is the quietest outcome and the best one.

The hardest lesson in email deliverability is that doing everything right at the DNS level is only half the work. The other half is reputation, alignment, and infrastructure choices you cannot configure in a text record.

Every sysadmin should have a mental checklist for email deliverability that goes beyond SPF, DKIM, and DMARC. Shared IP, PTR record, alignment, warmup schedule. Check them all before you call a configuration complete.

Docker Complete Guide: From Beginner to Production

Dowithsudo — Fri, 14 Aug 2026 18:32:26 +0000

I have walked into too many server rooms where the answer to every problem was "reinstall it." I have also watched teams burn entire weekends because an application ran on the developer's laptop and nowhere else. Docker ended most of those conversations for me, and it can do the same for you.

This guide is the one I wish I had when I started. It covers the mental model first, then the commands, then the production habits that separate hobby containers from infrastructure you can sleep through the night with. It is long on purpose. Bookmark it and come back as you grow.

If you prefer a shorter, gentler first read, start with my beginner Docker tutorial and return here when you are ready for the full picture.

What Docker actually solves

Docker packages an application with everything it needs to run, libraries, config files, environment variables, and the runtime, into a single immutable unit called a container image. That image runs identically on a laptop, a test server, or a cloud VM. The "works on my machine" excuse dies the moment the same image produces the same behavior everywhere.

Under the hood, Docker is not magic. It relies on two Linux kernel features:

Namespaces isolate processes, networking, filesystems, users, and hostnames so each container believes it owns the machine.
Cgroups limit and account for CPU, memory, and I/O so one noisy container cannot starve its neighbors.

A container shares the host kernel. That is why it boots in seconds and weighs megabytes, while a virtual machine boots an entire guest operating system and weighs gigabytes. The trade-off is isolation strength. A VM boundary is harder to cross than a container boundary, which matters for security decisions we will revisit later.

How the engine is actually put together

When you type docker run, more than one piece of software is involved. Docker Engine is the client and daemon you interact with, but since Docker 1.11 the heavy lifting has been delegated to specialized components:

containerd manages the container lifecycle, image storage, and the container runtime interface.
runc is the OCI runtime that actually creates and starts the container processes using namespaces and cgroups.

This split matters because it is why Docker, containerd, and Kubernetes can coexist. Kubernetes removed the Docker daemon from its control plane years ago and talks to containerd directly. The images you build today still run there, because they follow the OCI image spec. Understanding that layers, images, and runtimes are standardized is what makes the whole ecosystem portable instead of proprietary.

Image versus container

This is the first mental model to lock in.

Image is the immutable blueprint. Read-only layers stacked on top of each other. Think of an installer ISO.
Container is a running instance of an image with a thin writable layer on top. Think of the machine you installed.

docker pull ubuntu          # download an image
docker images               # list local images
docker run ubuntu echo hi   # create + start a container from an image
docker ps                   # list running containers
docker ps -a                # list all containers, including stopped
docker stop <id>            # stop a running container
docker rm <id>              # delete a stopped container

Deleting a container removes its writable layer. Anything written inside it disappears unless it lives in a volume. We will get to volumes shortly, but remember this: containers are ephemeral by design.

The Dockerfile: how images are built

A Dockerfile is a recipe. Every instruction produces a layer, and layers are cached. That single fact drives most performance advice you will ever read about Dockerfiles.

FROM node:20-alpine

WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci

COPY . .

RUN npm run build

USER node

EXPOSE 3000

CMD ["node", "dist/server.js"]

The order above is deliberate. Dependencies are installed before the application code is copied, so a code change reuses the cached dependency layers. If you copy everything first and install second, every code change invalidates the entire dependency cache and turns every build into a full rebuild.

Base image choices

Alpine is tiny and popular for final images, but its musl libc can break native binaries compiled against glibc. Test before you trust it.
Distroless images contain only the runtime and your binary, no shell, no package manager. Excellent for security, painful for debugging, since you cannot exec into a shell easily.
Slim variants (node:20-slim, python:3.12-slim) are a pragmatic middle ground.

Build with a context, and keep it small. A .dockerignore file prevents your node_modules, .git, and build artifacts from being shipped into the build context.

# .dockerignore
node_modules
.git
dist
*.log

Multi-stage builds

Multi-stage builds let you compile in a fat image and copy only the artifacts into a slim final image.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80

The final image contains only Nginx and your static files. The entire Node toolchain never ships.

Slimming images down

Image size is not vanity. Smaller images pull faster, start faster, and expose a smaller attack surface. Beyond multi-stage builds, a few habits keep images lean:

Prefer slim bases. node:20-slim over node:20 saves hundreds of megabytes for a one-line change.
Compile in the builder stage, copy only the artifact. Build tools never belong in the final image.
Clean package caches in the same layer that creates them. RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* stops the layer from carrying dead weight.
Build with BuildKit. It is the default in modern Docker and enables --mount=type=cache, so package managers reuse caches across builds instead of downloading the world every time.
Build multi-architecture images with docker buildx build --platform linux/amd64,linux/arm64 so one tag works on x86 servers and ARM boxes alike.

A healthy habit: run docker system df once a week and prune what you no longer use. Old images and dangling layers accumulate silently, and on a busy CI server disk fills faster than anyone expects.

Running containers properly

docker run has flags you will use every day.

docker run -d --name web -p 8080:80 -v webdata:/data --restart unless-stopped nginx

-d runs in the background.
--name gives the container a stable name.
-p host:container maps ports.
-v name:/path attaches a named volume.
--restart unless-stopped brings it back after reboots and crashes.

Resource limits are not optional

An unlimited container on a shared host is an accident waiting to happen. A runaway process inside the container can exhaust host memory and trigger the OOM killer on other workloads. I wrote a full breakdown of exactly this failure mode in a Docker container crash case study, where a missing memory limit took down a production service at night.

docker run -d --name api \
  --memory 512m --memory-swap 512m \
  --cpus 0.5 \
  -p 3000:3000 \
  my-api:latest

Set limits in Compose too, and set reservations so the scheduler knows the floor.

Volumes: surviving container death

Containers are ephemeral. Volumes are the escape hatch. A volume is storage managed by Docker that outlives any container.

docker volume create dbdata
docker run -d -v dbdata:/var/lib/postgresql/data postgres:16

Named volumes are managed by Docker, stored in /var/lib/docker/volumes, and are the production default for databases.
Bind mounts map a host directory into the container. Great for development because your editor writes directly into the container's view. Dangerous in production because host filesystem quirks leak into the runtime.

Databases in containers are a defensible choice for small and medium workloads, provided the data lives in a named volume and backups run against that volume, not against the container. If you manage storage at the OS level, the LVM recovery case study shows what happens when the underlying disk layer misbehaves.

Backing up and restoring volumes

Backups run against the volume, not the container. The container is disposable, the data is not. The classic approach is a tar pipeline while the service is stopped or quiescent:

docker run --rm -v dbdata:/data -v /backup:/backup alpine \
  tar czf /backup/dbdata-$(date +%F).tar.gz -C /data .

To restore, reverse the pipeline:

docker run --rm -v dbdata:/data -v /backup:/backup alpine \
  tar xzf /backup/dbdata-2026-08-17.tar.gz -C /data

Two cautions. First, tar on a live database is at best a crash-consistent copy, so for Postgres and MySQL prefer their native dump tools, pg_dump or mysqldump, piped into the same pattern. Second, test the restore. A backup you have never restored is a rumor, not a backup.

Networking

By default, containers attach to a bridge network and reach each other by name. Compose creates one network per project automatically.

docker network ls
docker network inspect bridge
docker port web

Three network modes matter:

bridge: default. Isolated virtual network with port mapping to the host.
host: container shares the host network stack. Lower latency, but the container can bind any host port, which weakens isolation.
none: no networking. Useful for security-focused sidecar processes.

For inter-container communication, prefer service names over IP addresses. IPs change when containers restart.

Docker Compose: your everyday workflow

Once an application has more than one moving part, web, database, cache, you stop typing docker run repeatedly and start defining everything in docker-compose.yml.

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - dbdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  api:
    build: .
    environment:
      DATABASE_URL: postgres://postgres:${DB_PASSWORD}@db:5432/app
    ports:
      - "3000:3000"
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

volumes:
  dbdata:

Three details here prevent real incidents.

Environment via variables, not secrets in the file. Use an .env file for local development and a secret manager in production.
Healthchecks make depends_on meaningful. Without condition: service_healthy, the API starts before Postgres accepts connections and crashes during startup.
Restart policies (unless-stopped) keep services alive across host reboots.

The compose file in my MERN migration case study shows a full production stack, backend, frontend, managed database, and object storage, orchestrated with exactly these patterns.

CI/CD: build, scan, and ship on every push

Manual docker build on a server is a smell. The image you tested locally should be the image that runs in production, which means building once in a pipeline and promoting the same artifact. A minimal GitHub Actions workflow does the job:

name: build-image
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      # Build locally first, no push yet
      - uses: docker/build-push-action@v6
        with:
          load: true
          tags: my-api:scan
      # Scan the local image; exit-code 1 blocks the pipeline on HIGH/CRITICAL
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: my-api:scan
          severity: HIGH,CRITICAL
          exit-code: "1"
      # Only now push to the registry
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:latest

The scan step runs before the push, so a broken image never reaches the registry. Whether you use GitHub Actions, GitLab CI, or a self-hosted runner, the pattern is the same: build once, scan, tag, push, and let the deployment pull that exact digest.

Production hardening checklist

Move a containerized application to production and these become non-negotiable:

Healthchecks

Every service that serves traffic should expose a health endpoint, and Docker should probe it.

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

start_period matters. It gives slow-starting applications time to warm up before failures count.

Log rotation

By default, Docker writes container logs to JSON files without limits. A chatty application can fill the disk. The docker-crash case study above is exactly what happens when logs grow unchecked.

logging:
  driver: "json-file"
  options:
    max-size: "10m"
    max-file: "3"

Non-root user

Running as root inside a container is a common hardening gap. Add a dedicated user in your image.

RUN addgroup -S app && adduser -S app -G app
USER app

Read-only filesystem

Mark the filesystem read-only when the application does not need to write.

read_only: true
tmpfs:
  - /tmp

Scan images

Run vulnerability scanners on your images before deployment. Trivy and Grype are both free and can run in CI.

trivy image my-api:latest --severity HIGH,CRITICAL

For the broader security picture, the Linux server hardening best practices guide covers the host side, SSH, firewalls, and user management, which protects the Docker host itself.

Monitoring containers in production

Healthchecks tell you a service is alive, not that it is well. For the second part you need metrics. Start with the built-in tools, then graduate to a stack when the fleet grows.

docker stats gives instant CPU and memory per container. It is the first thing to run when something feels slow.
docker events streams lifecycle events, container started, stopped, killed. Invaluable when an automation script restarts things behind your back.
cAdvisor exposes per-container metrics in Prometheus format and is a ten-minute addition to any Compose stack.
Prometheus plus Grafana is the standard pairing once you want history, alerts, and dashboards. Set alerts on restart counts and memory pressure, not just uptime.

The principle is simple: you cannot fix what you cannot see, and you cannot see what you never measured. Install the dashboard before the incident, not after.

Debugging containers under pressure

When something breaks at 2 AM, these are the commands you reach for, in order.

docker ps -a                    # what is actually running?
docker logs --tail 200 api      # what did the app say before dying?
docker inspect api              # what does Docker think the state is?
docker stats                    # who is eating resources?
df -h                           # is the disk full?

The exit code is your first clue. Exit 137 usually means the kernel OOM killer terminated the container. Exit 1 means the application failed on its own. The full diagnostic workflow, including reading kernel OOM logs, is documented step by step in the Docker container crash case study.

docker inspect api --format '{{.State.Status}} OOMKilled={{.State.OOMKilled}} Exit={{.State.ExitCode}}'

Updating containers without downtime

Updating a container is not a mystery. Pull the new image, recreate the container, and verify. With Compose:

docker compose pull
docker compose up -d
docker compose ps

For a single container, docker pull followed by docker rm -f and docker run with the same flags does the same job, or docker compose up -d handles the recreation for you.

Three habits keep updates boring:

Always pull explicitly. docker run with :latest uses the cached image unless you pull first. A server that has not been updated in weeks runs a very old image while everyone assumes it is current.
Pin versions in production. :latest is a moving target. Use a specific tag or digest in your deployment so a rebuild does not silently change behavior.
Have a rollback. Keep the previous tag and know the one command to return to it. The five minutes spent writing down the rollback procedure will save you an hour at 3 AM.

Complete walkthrough: from a folder to production

Theory is cheap, so here is the shortest path from a bare repository to a running service, using everything above.

Write the Dockerfile with the dependency-first order and a non-root user.
Add a .dockerignore so the build context stays small.
Define the stack in Compose with a healthcheck, log limits, memory limits, and a named volume for anything persistent.
Test locally: docker compose up -d, hit the service, break it, watch the logs.
Build, scan, and push from CI so the artifact is reproducible and vetted.
Pull and run on the server with the same Compose file, or wire it into your orchestration of choice.
Verify with a health check from outside the host, then walk away.

Every step in this list appears in this guide, and every failure mode, missing healthcheck, unbounded logs, no memory limit, root user, shows up in the case studies linked above. Build the habit on a staging service first. When the process bores you, you are ready for production.

When Docker is not the answer

Docker is a tool, not a religion. Some workloads do not belong in containers.

GUI-heavy desktop applications gain little from containerization.
Stateful high-IO databases at large scale often perform better with dedicated instances and specialized storage.
Real-time kernels or specialized hardware drivers can fight container isolation.
Windows-only legacy applications need a Windows container host, which changes the whole cost equation.

For everything else, containers are the default answer. If you are still deciding whether containers or plain VMs fit a workload, think in terms of team velocity and isolation requirements, not fashion.

Where to go next in the Docker universe

Docker is the foundation. The ecosystem above it is where most of the career value lives.

Orchestration: when you have many containers across multiple hosts, you need a scheduler. Kubernetes is the industry standard, but start with Docker Swarm for learning the concepts on a smaller scale. Do not jump to Kubernetes until single-host Compose feels boring. If you are weighing the jump, my Docker vs Kubernetes comparison gives the honest criteria I use with clients.
CI/CD: build and scan images automatically on every push. GitHub Actions and GitLab CI both have first-class Docker support.
Registry: push images to Docker Hub or a private registry so deployments pull exactly the tested artifact.
Secrets: never bake secrets into images. Use Docker secrets, a vault, or your cloud provider's secret store.

If you are planning the learning path, my guide on how long it takes to learn Docker gives a realistic timeline, and my building a Docker container from scratch guide shows how to assemble an image layer by layer without a base OS.

For automation beyond containers, Ansible handles configuration management on the hosts themselves, and Terraform provisions the infrastructure those hosts run on. Containerize the app, automate the host, provision the cloud, and you have the complete modern stack.

Frequently asked questions

Is Docker a virtual machine? No. Containers share the host kernel and isolate processes, while VMs run a full guest operating system. That is why containers are lighter and faster to start, and why they are weaker at the kernel boundary.

Do I need Docker Desktop to run containers? On Windows and macOS, Docker Desktop is the easiest path because it runs a Linux VM behind the scenes. On Linux, install the Docker Engine directly, no desktop layer required.

Are containers safe to run untrusted code? Not by default. Treat a container as a lightweight process with a few extra walls, not as a sandbox. For untrusted code, use a dedicated VM or a gVisor-style runtime.

What is the difference between Docker and Kubernetes? Docker runs containers on a single host. Kubernetes schedules containers across many hosts and handles networking, storage, and self-healing. Learn Compose on one server before you touch Kubernetes.

Do I need Docker if I use serverless? Different problems. Serverless hides the server from you, Docker gives you full control over the server. Most real deployments use both at different layers.

Final words

Docker rewards boring discipline. Healthchecks, log limits, resource limits, non-root users, read-only filesystems, image scanning. None of these are glamorous, and all of them are what separates a demo from a service.

Start small. Containerize one unimportant service first, run it with Compose, break it, and fix it. When that becomes routine, the rest of the ecosystem stops looking intimidating.

I have been running containers in production for years. The containers themselves rarely cause incidents. The missing healthcheck, the unbounded log, the root user, the absent memory limit, those cause incidents. This guide exists so yours do not.

I hope this complete Docker guide helps you make better decisions in real-world situations.

helo everyone, im the new guy here

Dowithsudo — Fri, 14 Aug 2026 18:11:55 +0000