
Docker Platform Guide
- 164 installs
- 50 repo stars
- Updated June 18, 2026
- josiahsiegel/claude-plugin-marketplace
Follow end-to-end Docker platform guidance—images, networks, volumes, compose, registries, and runtime ops—for teams standardizing container delivery across environments.
About
Comprehensive Claude skill for the Docker platform covering images, Compose stacks, networking, volumes, registries, and runtime operations. Gives teams a single reference for building reliable containerized integrations from laptop dev through CI/CD to deployed services.
- Image layering and Dockerfile best practices
- Compose-based multi-service stacks
- Registry push and tag strategies
- Networking, volumes, and secrets
- Local-to-production parity patterns
Docker Platform Guide by the numbers
- 164 all-time installs (skills.sh)
- +4 installs in the week ending Aug 2, 2026 (Skillselion tracking)
- Ranked #438 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
- Data as of Aug 3, 2026 (Skillselion catalog sync)
npx skills add https://github.com/josiahsiegel/claude-plugin-marketplace --skill docker-platform-guideAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 164 |
|---|---|
| repo stars | ★ 50 |
| Last updated | June 18, 2026 |
| Repository | josiahsiegel/claude-plugin-marketplace ↗ |
What it does
Follow end-to-end Docker platform guidance—images, networks, volumes, compose, registries, and runtime ops—for teams standardizing container delivery across environments.
Files
Docker Platform-Specific Guide
This skill provides detailed guidance on Docker differences, considerations, and optimizations for Windows, Linux, and macOS platforms.
Shell and path conventions used in this skill
Docker commands are mostly identical across platforms, but the surrounding shell utilities are not. This guide uses the following conventions:
- Inside `docker exec` / `docker run` containers — commands target a Linux shell regardless of host OS (containers run Linux).
- On the host (Linux / macOS / WSL2) — examples use bash with
/dev/null,grep,sed,awk, package managers (apt-get,brew). - On the host (Windows native PowerShell) — substitute:
/dev/null->$null,grep pattern->Select-String pattern,sed -i 's/a/b/' f->(Get-Content f) -replace 'a','b' | Set-Content f. Pipe object output rather than text. - Docker Desktop on Windows uses a WSL2 Linux VM — bash examples work inside WSL distros. PowerShell users can still run the
dockerCLI itself; only the supporting Unix tools need translation.
Path quoting: when bind-mounting Windows paths into Docker Desktop, use forward slashes or escaped backslashes (-v C:/Users/me/code:/app or -v "C:\Users\me\code:/app"). The PowerShell host path uses Windows separators; the container path is always Linux-style.
Linux
Advantages
- Native containers: No virtualization layer overhead
- Best performance: Direct kernel features (cgroups, namespaces)
- Full feature set: All Docker features available
- Production standard: Most production deployments run on Linux
- Flexibility: Multiple distributions supported
Platform Features
Container Technologies:
- Namespaces: PID, network, IPC, mount, UTS, user
- cgroups v1 and v2 for resource control
- Overlay2 storage driver (recommended)
- SELinux and AppArmor for mandatory access control
Storage Drivers:
# Check current driver
docker info | grep "Storage Driver"
# Recommended: overlay2
# /etc/docker/daemon.json
{
"storage-driver": "overlay2"
}Linux-Specific Configuration
Daemon Configuration (/etc/docker/daemon.json):
{
"storage-driver": "overlay2",
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
},
"live-restore": true,
"userland-proxy": false,
"userns-remap": "default",
"icc": false,
"default-ulimits": {
"nofile": {
"Name": "nofile",
"Hard": 64000,
"Soft": 64000
}
}
}User Namespace Remapping:
# Enable in daemon.json
{
"userns-remap": "default"
}
# Restart Docker
sudo systemctl restart docker
# Result: root in container = unprivileged user on hostSELinux Integration
# Check SELinux status
sestatus
# Run container with SELinux enabled
docker run --security-opt label=type:svirt_sandbox_file_t myimage
# Volume labels
docker run -v /host/path:/container/path:z myimage # Private label
docker run -v /host/path:/container/path:Z myimage # Shared labelAppArmor Integration
# Check AppArmor status
sudo aa-status
# Run with default Docker profile
docker run --security-opt apparmor=docker-default myimage
# Create custom profile
sudo aa-genprof docker run myimageSystemd Integration
# Check Docker service status
sudo systemctl status docker
# Enable on boot
sudo systemctl enable docker
# Restart Docker
sudo systemctl restart docker
# View logs
sudo journalctl -u docker -f
# Configure service
sudo systemctl edit dockercgroup v1 vs v2
# Check cgroup version
stat -fc %T /sys/fs/cgroup/
# If using cgroup v2, ensure Docker version >= 20.10
# /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"]
}Linux Distribution Specifics
Ubuntu/Debian:
# Install Docker
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
# Non-root user
sudo usermod -aG docker $USERRHEL/CentOS/Fedora:
# Install Docker
sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo
sudo dnf install docker-ce docker-ce-cli containerd.io
# Start Docker
sudo systemctl start docker
sudo systemctl enable docker
# Non-root user
sudo usermod -aG docker $USERAlpine:
# Install Docker
apk add docker docker-compose
# Start Docker
rc-update add docker boot
service docker startmacOS
Architecture
- Docker Desktop: Required (no native Docker on macOS)
- Virtualization: Uses HyperKit (Intel) or Virtualization.framework (Apple Silicon)
- Linux VM: Containers run in lightweight Linux VM
- File sharing: osxfs or VirtioFS for bind mounts
macOS-Specific Considerations
Resource Allocation:
Docker Desktop → Preferences → Resources → Advanced
- CPUs: Allocate based on workload (default: half available)
- Memory: Allocate generously (default: 2GB, recommend 4-8GB)
- Swap: 1GB minimum
- Disk image size: 60GB+ for developmentFile Sharing Performance:
Traditional osxfs is slow. Improvements: 1. VirtioFS: Enable in Docker Desktop settings (faster) 2. Delegated/Cached mounts:
volumes:
# Host writes delayed (best for source code)
- ./src:/app/src:delegated
# Container writes cached (best for build outputs)
- ./build:/app/build:cached
# Default consistency (slowest but safest)
- ./data:/app/data:consistentNetwork Access:
# Access host from container
host.docker.internal
# Example: Connect to host PostgreSQL
docker run -e DATABASE_URL=postgresql://host.docker.internal:5432/db myappApple Silicon (M1/M2/M3) Specifics
Architecture Considerations:
# Check image architecture
docker image inspect node:20-alpine | grep Architecture
# M-series Macs are ARM64
# Some images only available for AMD64
# Build multi-platform
docker buildx build --platform linux/amd64,linux/arm64 -t myapp .
# Run AMD64 image on ARM (via emulation)
docker run --platform linux/amd64 myimage # SlowerRosetta 2 Integration:
Docker Desktop → Features in development → Use Rosetta for x86/amd64 emulationFaster AMD64 emulation on Apple Silicon.
macOS Docker Desktop Settings
General:
- ✅ Start Docker Desktop when you log in
- ✅ Use VirtioFS (better performance)
- ✅ Use Virtualization framework (Apple Silicon)
Resources:
CPUs: 4-6 (for development)
Memory: 6-8 GB (for development)
Swap: 1-2 GB
Disk image size: 100+ GB (grows dynamically)Docker Engine:
{
"builder": {
"gc": {
"enabled": true,
"defaultKeepStorage": "20GB"
}
},
"experimental": false,
"features": {
"buildkit": true
}
}macOS File Permissions
# macOS user ID and group ID
id -u # Usually 501
id -g # Usually 20
# Match in container
docker run --user 501:20 myimage
# Or in Dockerfile
RUN adduser -u 501 -g 20 appuser
USER appusermacOS Development Workflow
# docker-compose.yml for development
version: '3.8'
services:
app:
build: .
volumes:
# Source code with delegated (better performance)
- ./src:/app/src:delegated
# node_modules in volume (much faster than bind mount)
- node_modules:/app/node_modules
ports:
- "3000:3000"
environment:
- NODE_ENV=development
volumes:
node_modules:Common macOS Issues
Problem: Slow file sync Solution:
- Use VirtioFS
- Use delegated/cached mounts
- Store dependencies in volumes (not bind mounts)
Problem: High CPU usage Solution:
- Reduce file watching
- Exclude large directories from file sharing
- Allocate more resources
Problem: Port already in use Solution:
# Find process using port
lsof -i :PORT
kill -9 PIDWindows
For Windows Docker specifics (container types, WSL2, image variants nanoserver / windowsservercore, licensing, networking, mount semantics, Visual Studio integration), see references/windows-platform-detail.md. Highlights:
- Container types: Windows Server Containers (process isolation) vs Hyper-V Containers (kernel isolation).
- WSL2 backend: Docker Desktop default; gives near-native Linux performance.
- Image variants:
mcr.microsoft.com/windows/nanoserver(smallest) vswindowsservercore(full API). - Mounts: convert
S: eposxto/s/repos/xin Git Bash or setMSYS_NO_PATHCONV=1.
Platform Comparison
| Feature | Linux | macOS | Windows |
|---|---|---|---|
| Performance | Excellent (native) | Good (VM overhead) | Good (WSL2) to Fair (Hyper-V) |
| File sharing | Native | Slow (improving with VirtioFS) | Slow (better in WSL2) |
| Resource efficiency | Best | Good | Good (WSL2) |
| Feature set | Complete | Complete | Complete (LCOW) |
| Production | Standard | Dev only | Dev only (LCOW) |
| Ease of use | Moderate | Easy (Docker Desktop) | Easy (Docker Desktop) |
| Cost | Free | Free (Docker Desktop Personal) | Free (Docker Desktop Personal) |
Cross-Platform Best Practices
Multi-Platform Images
# Create buildx builder
docker buildx create --name multiplatform --driver docker-container --use
# Build for multiple platforms
docker buildx build \
--platform linux/amd64,linux/arm64,linux/arm/v7 \
-t myimage:latest \
--push \
.Platform-Agnostic Dockerfiles
# Works on all platforms
FROM node:20-alpine
# Use COPY with --chmod (not RUN chmod, which is slower)
COPY --chmod=755 script.sh /usr/local/bin/
# Use environment variables for paths
ENV APP_HOME=/app
WORKDIR ${APP_HOME}
# Use exec form for CMD/ENTRYPOINT (works on Windows containers too)
CMD ["node", "server.js"]Cross-Platform Compose Files
version: '3.8'
services:
app:
build: .
volumes:
# Relative paths work everywhere
- ./src:/app/src
# Named volumes (platform-agnostic)
- data:/app/data
environment:
# Use environment variables
- NODE_ENV=${NODE_ENV:-development}
volumes:
data:Testing Across Platforms
# Test on different platforms with buildx
docker buildx build --platform linux/amd64 -t myapp:amd64 --load .
docker run --rm myapp:amd64
docker buildx build --platform linux/arm64 -t myapp:arm64 --load .
docker run --rm myapp:arm64Platform Selection Guide
Choose Linux for:
- Production deployments
- Maximum performance
- Full Docker feature set
- Minimal overhead
- CI/CD pipelines
Choose macOS for:
- Development on Mac hardware
- When you need macOS tools
- Docker Desktop ease of use
- M1/M2/M3 development
Choose Windows for:
- Development on Windows hardware
- Windows-specific applications
- When team uses Windows
- WSL2 for better Linux container support
This platform guide covers the major differences. Always test on your target deployment platform before going to production.
Windows Docker Platform (Detailed Reference)
Windows container types (Server containers, Hyper-V, process isolation), WSL2 integration, image variants (nanoserver, windowsservercore), licensing, networking peculiarities, mount semantics, and Visual Studio integration.
Windows
Windows Container Types
1. Linux Containers on Windows (LCOW):
- Most common for development
- Uses WSL2 or Hyper-V backend
- Runs Linux containers
- Good compatibility
2. Windows Containers:
- Native Windows containers
- For Windows-specific workloads
- Requires Windows Server base images
- Less common in development
Windows Backend Options
WSL2 Backend (Recommended):
- Faster
- Better resource usage
- Native Linux kernel
- Requires Windows 10/11 (recent versions)
Hyper-V Backend:
- Older option
- More resource intensive
- Works on older Windows versions
WSL2 Configuration
Enable WSL2:
# Run as Administrator
wsl --install
# Or manually
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
# Set WSL2 as default
wsl --set-default-version 2
# Install Ubuntu (or other distro)
wsl --install -d UbuntuDocker Desktop Integration:
Settings → Resources → WSL Integration
- Enable integration with default distro
- Select additional distrosWindows Path Considerations
Path Formats:
# Forward slashes (recommended, works everywhere)
docker run -v C:/Users/name/project:/app myimage
# Backslashes (need escaping in some contexts)
docker run -v C:\Users\name\project:/app myimage
# In docker-compose.yml (forward slashes)
volumes:
- C:/Users/name/project:/app
# Or relative paths
volumes:
- ./src:/app/srcGit Bash / MINGW Path Conversion Issues
CRITICAL ISSUE: When using Docker in Git Bash (MINGW) on Windows, automatic path conversion breaks volume mounts.
The Problem:
# What you type in Git Bash:
docker run -v $(pwd):/app myimage
# What Git Bash converts it to (BROKEN):
docker run -v C:\Program Files\Git\d\repos\project:/app myimageSolutions:
1. MSYS_NO_PATHCONV (Recommended):
# Per-command fix
MSYS_NO_PATHCONV=1 docker run -v $(pwd):/app myimage
# Session-wide fix (add to ~/.bashrc)
export MSYS_NO_PATHCONV=1
# Function wrapper (automatic for all Docker commands)
docker() {
(export MSYS_NO_PATHCONV=1; command docker.exe "$@")
}
export -f docker2. Double Slash Workaround:
# Use double leading slash to prevent conversion
docker run -v //c/Users/project:/app myimage
# Works with $(pwd) too
docker run -v //$(pwd):/app myimage3. Named Volumes (No Path Issues):
# Named volumes work without any fixes
docker run -v my-data:/data myimageWhat Works Without Modification:
- Docker Compose YAML files with relative paths
- Named volumes
- Network and image commands
- Container commands without volumes
What Needs MSYS_NO_PATHCONV:
- Bind mounts with
$(pwd) - Bind mounts with absolute Unix-style paths
- Volume mounts specified on command line
Shell Detection:
# Detect Git Bash/MINGW and auto-configure
if [ -n "$MSYSTEM" ] || [[ "$(uname -s)" == MINGW* ]]; then
export MSYS_NO_PATHCONV=1
echo "Git Bash detected - Docker path conversion fix enabled"
fiRecommended ~/.bashrc Configuration:
# Docker on Git Bash fix
if [ -n "$MSYSTEM" ]; then
export MSYS_NO_PATHCONV=1
fiSee the docker-git-bash-guide skill for comprehensive path conversion documentation, troubleshooting, and examples.
Windows File Sharing
Configure Shared Drives:
Docker Desktop → Settings → Resources → File Sharing
Add: C:\, D:\, etc.Performance Considerations:
- File sharing is slower than Linux/Mac
- Use WSL2 backend for better performance
- Store frequently accessed files in WSL2 filesystem
Windows Line Endings
Problem: CRLF vs LF line endings
Solution:
# Git configuration
git config --global core.autocrlf input
# Or per-repo (.gitattributes)
* text=auto
*.sh text eol=lf
*.bat text eol=crlf# In Dockerfile for scripts
FROM alpine
COPY --chmod=755 script.sh /
# Ensure LF endings
RUN dos2unix /script.sh || sed -i 's/\r$//' /script.shWindows Firewall
# Allow Docker Desktop
New-NetFirewallRule -DisplayName "Docker Desktop" -Direction Inbound -Program "C:\Program Files\Docker\Docker\Docker Desktop.exe" -Action Allow
# Check blocked ports
netstat -ano | findstr :PORTWindows-Specific Docker Commands
# Run PowerShell in container
docker run -it mcr.microsoft.com/powershell:lts-7.4-windowsservercore-ltsc2022
# Windows container example
docker run -it mcr.microsoft.com/windows/servercore:ltsc2022 cmd
# Check container type
docker info | Select-String "OSType"WSL2 Disk Management
Problem: WSL2 VHDX grows but doesn't shrink
Solution:
# Stop Docker Desktop and WSL
wsl --shutdown
# Compact disk image (run as Administrator)
# Method 1: Optimize-VHD (requires Hyper-V tools)
Optimize-VHD -Path "$env:LOCALAPPDATA\Docker\wsl\data\ext4.vhdx" -Mode Full
# Method 2: diskpart
diskpart
# In diskpart:
select vdisk file="C:\Users\YourName\AppData\Local\Docker\wsl\data\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exitWindows Development Workflow
# docker-compose.yml for Windows
version: '3.8'
services:
app:
build: .
volumes:
# Use forward slashes
- ./src:/app/src
# Named volumes for better performance
- node_modules:/app/node_modules
ports:
- "3000:3000"
environment:
- NODE_ENV=development
# Windows-specific: ensure proper line endings
command: sh -c "dos2unix /app/scripts/*.sh && npm start"
volumes:
node_modules:Common Windows Issues
Problem: Permission denied errors Solution:
# Run Docker Desktop as Administrator
# Or grant permissions to Docker Desktop
icacls "C:\ProgramData\DockerDesktop" /grant Users:F /TProblem: Slow performance Solution:
- Use WSL2 backend
- Store project in WSL2 filesystem (
\\wsl$\Ubuntu\home\user\project) - Use named volumes for node_modules, etc.
Problem: Path not found Solution:
- Use forward slashes
- Ensure drive is shared in Docker Desktop
- Use absolute paths or
${PWD}