Daily micro-tips for C#, SQL, performance, and scalable backend engineering.
Running all services (database, cache, queue, monitoring) every time is slow. Profiles start only what you need. docker-compose.yml: services: app: build: . ports: – “3000:3000” db: image: postgres profiles: [“dev”, “test”] redis: image: redis profiles: [“dev”] monitoring: image: grafana profiles: [“monitoring”] mailhog: image: mailhog/mailhog profiles: [“dev”] Start Different Profiles: # Just the app (no extras) […]
Confusing ARG and ENV causes build issues. Know when to use each. ARG – Build-Time Only: FROM node:18 ARG NODE_ENV=production ARG API_URL=https://api.example.com RUN echo “Building for ${NODE_ENV}” RUN npm install –${NODE_ENV} # ARG values NOT available at runtime! Build with ARG: docker build –build-arg NODE_ENV=development -t myapp . ENV – Runtime Variables: FROM node:18 ENV […]
Writing Dockerfiles from scratch is error-prone. Docker init analyzes your project and generates optimized Dockerfile. Run in Project Directory: docker init # Detects project type (Node.js, Python, Go, etc.) # Asks questions about your app # Generates: # – Dockerfile # – .dockerignore # – docker-compose.yml Example Output for Node.js: Creates multi-stage build, sets up […]
Including build tools in final image wastes space. Multi-stage builds separate build and runtime. Single-Stage (Large): FROM node:18 WORKDIR /app COPY . . RUN npm install # Includes dev dependencies RUN npm run build CMD [“node”, “dist/server.js”] # Result: 1.2 GB (includes npm, build tools) Multi-Stage (Small): # Stage 1: Build FROM node:18 AS builder […]
Container running but app inside crashed? Add HEALTHCHECK to auto-detect and restart failed containers. Add to Dockerfile: FROM node:18 WORKDIR /app COPY . . # Check if app responds on port 3000 HEALTHCHECK –interval=30s –timeout=3s –retries=3 \ CMD curl -f http://localhost:3000/health || exit 1 CMD [“node”, “server.js”] What Happens: Every 30 seconds, Docker runs health […]
Copying node_modules, .git, and cache files into images wastes time and space. Exclude them with .dockerignore. Create .dockerignore in project root: node_modules npm-debug.log .git .gitignore *.md .env .vscode .idea **/*.log **/dist **/bin **/obj Impact: Without .dockerignore: – Build time: 45 seconds – Image size: 850 MB (includes node_modules) With .dockerignore: – Build time: 8 seconds […]
Manually rebuilding Docker containers after every code change? Docker Compose watch auto-rebuilds on file save. Add to docker-compose.yml: services: web: build: . develop: watch: – path: ./src action: rebuild Start with watch: docker compose watch Edit src/ files → Docker auto-rebuilds container. No manual restart needed! Actions: rebuild (full rebuild), sync (copy files), sync+restart (copy […]
Manually starting 5 different services for development? Docker Compose defines and runs multi-container apps. # docker-compose.yml version: ‘3.8’ services: # Node.js API api: build: ./api ports: – “3000:3000” environment: – NODE_ENV=development – REDIS_URL=redis://redis:6379 – DATABASE_URL=postgresql://user:pass@db:5432/mydb volumes: – ./api:/app – /app/node_modules depends_on: – redis – db command: npm run dev # React Frontend frontend: build: ./frontend […]
Docker eating 50GB of disk space? Old images, stopped containers, and dangling volumes pile up fast. One command reclaims it all. Check Current Disk Usage: docker system df # Output: TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 47 12 28.5GB 18.2GB (63%) Containers 89 5 10.2GB 9.8GB (96%) Local Volumes 23 8 2.3GB 1.1GB (47%) Build […]
Your Docker image is 1.2GB when it should be 120MB? Multi-stage builds eliminate build dependencies from your final image. The Problem – Single Stage Build: FROM node:18 WORKDIR /app COPY package*.json ./ RUN npm install # Installs 300MB of dev dependencies COPY . . RUN npm run build # Creates 10MB production build CMD [“node”, […]
Image size ≠ image performance. Hidden cause Layer invalidation. Most Dockerfiles are written like this: COPY . . RUN npm install Every small file change invalidates the cache. Correct approach COPY package.json package-lock.json ./ RUN npm install COPY . . Cause → Effect Stable dependency layers Faster rebuilds Lower CI/CD costs This is why two […]
If a container runs for days, performance can degrade without any load increase. What actually happens Linux page cache grows but isn’t reclaimed fast enough Log files inside containers expand silently OverlayFS layers fragment over time Golden principle Containers are ephemeral by design, not meant to be immortal. Fix Externalize logs Restart containers on a […]
A container runs fine at first… then slowly degrades. No spikes. No crashes. Just silent slowness. Root cause Layered filesystem (OverlayFS) grows Log files inside containers never rotate Memory fragmentation inside long-lived containers Golden rule Containers are not VMs. They are disposable. Fix Never log to disk inside containers Use external logging drivers Restart containers […]
FROM mcr.microsoft.com/dotnet/sdk AS build FROM mcr.microsoft.com/dotnet/aspnet Why it mattersFinal image contains only runtime → faster deploys, fewer vulnerabilities.
node_modules bin obj .git Why it mattersSmaller build context = faster builds, fewer leaks.
FROM node:18 AS build RUN npm run build FROM nginx:alpine COPY –from=build /app/dist /usr/share/nginx/html Why it mattersRemoves build junk → secure & tiny images.
The problem is usually the base image. # ❌ Heavy FROM mcr.microsoft.com/dotnet/sdk:8.0 # ✅ Lightweight FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine Why this mattersSmaller images = faster pull, faster start, lower memory pressure.
Most people say multi-stage builds are for smaller images.Wrong. They’re about attack surface. FROM mcr.microsoft.com/dotnet/sdk AS build WORKDIR /src COPY . . RUN dotnet publish -c Release -o /app FROM mcr.microsoft.com/dotnet/aspnet WORKDIR /app COPY –from=build /app . Why it matters: No SDK in production Fewer CVEs Faster cold starts Smaller image is just a side […]
Most “random” container crashes are not random at all — they’re OOM kills. By default, Docker containers have no memory awareness unless you explicitly define it. services: api: image: my-api deploy: resources: limits: memory: 512M Why this mattersWithout limits, the container can consume host memory freely.Linux kernel steps in → kills your container → zero […]
One line edit → full rebuild. Why it happensCOPY order invalidates cache. Why it mattersCI/CD pipelines slow down. Vital fix COPY *.csproj . RUN dotnet restore COPY . .
The Mystery: Your Docker image builds perfectly on Linux or CI/CD, but the moment you or a teammate tries to run it on Windows, the container exits instantly with a cryptic exec format error or standard_init_linux.go:211: exec user process caused “no such file or directory”. The Culprit: It’s not your code; it’s the invisible characters […]
Same app, bigger image. Why it happensLayer caching invalidated by COPY order. Why it mattersSlower builds, higher registry costs. Smart fixCopy dependency files first, source later.
Same image, different result. WhyMissing environment variables. TipExplicitly define ENV values in Dockerfile.
Same app, bigger image. WhyUnoptimized layer ordering. TipPlace rarely changed steps first in Dockerfile.
Local success, CI failure. WhyImplicit local file system assumptions. TipAlways build containers using clean contexts.
Builds succeed, debugging is painful. WhySingle-stage images mix runtime and build tools. TipSeparate build and runtime layers.
Same Dockerfile, slower builds. WhyLayer cache invalidation caused by small file changes. Tip Copy dependency files before source code.
Even after cleanup. WhyDangling layers and build cache accumulate. Maintenance Tip Schedule periodic build cache pruning.
First run is fast, restart is slow. WhyVolume mounts re-initialize filesystem state. Fix Avoid mounting large directories unless necessary.
Same app, bigger image. WhyLayer cache accumulates unused artifacts. Fix Use multi-stage builds and remove build-time dependencies.