DEV Community: Alex Boguslavets

Docker for Beginners: Containerize Your App in 30 Minutes

Alex Boguslavets — Thu, 23 Apr 2026 08:12:36 +0000

I remember the first time I heard "it works on my machine." Three developers, three different environments, one broken deploy. Docker solves exactly this problem.

In this guide you'll go from zero to a running containerized app in 30 minutes.

What is Docker, actually?

Docker packages your app + its dependencies + runtime into a single image. That image runs the same way everywhere — your laptop, a teammate's Mac, AWS EC2.

Think of it like a shipping container: standardized box, works on any ship.

Prerequisites

Docker Desktop installed (docs.docker.com)
Basic terminal knowledge
Any web app (we'll use a simple Node.js example)

Step 1: Create a simple app

// app.js
const http = require('http');

const server = http.createServer((req, res) => {
  res.end('Hello from Docker! 🐳');
});

server.listen(3000, () => console.log('Running on port 3000'));

// package.json
{
  "name": "docker-demo",
  "version": "1.0.0",
  "scripts": { "start": "node app.js" }
}

Step 2: Write a Dockerfile

# Start from official Node image
FROM node:20-alpine

# Set working directory inside container
WORKDIR /app

# Copy dependency files first (layer caching)
COPY package*.json ./
RUN npm install

# Copy the rest of the app
COPY . .

# Expose the port
EXPOSE 3000

# Start command
CMD ["node", "app.js"]

Step 3: Build and run

# Build the image
docker build -t my-app .

# Run a container from it
docker run -p 3000:3000 my-app

Open http://localhost:3000 — you'll see "Hello from Docker! 🐳"

Step 4: Add Docker Compose

For real apps you need a database too. Docker Compose manages multiple containers:

# docker-compose.yml
version: '3.8'

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:password@db:5432/myapp    depends_on:
      - db

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: myapp
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

docker compose up -d

One command — app + database, both running.

Key concepts to remember

Concept	What it is
Image	Blueprint (like a class)
Container	Running instance (like an object)
Dockerfile	Recipe to build an image
Docker Compose	Tool to run multiple containers
Volume	Persistent storage for containers

Common mistakes beginners make

1. Copying node_modules into the image

Add a .dockerignore file:

node_modules
.git
.env

2. Running as root

Add this to your Dockerfile before CMD:

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

3. Not using layer caching

Always copy package.json and run npm install BEFORE copying your source code. Docker caches each layer — if your code changes but dependencies don't, it won't reinstall everything.

What's next?

Once you're comfortable with basics:

Multi-stage builds — smaller production images
Health checks — Docker restarts unhealthy containers
Docker secrets — secure way to pass credentials
Kubernetes — when you need to scale beyond one server

Real talk

Docker has a learning curve. The first Dockerfile feels weird. But after a week you won't be able to imagine developing without it.

No more "works on my machine." No more dependency conflicts. No more manual server setup.

I use Docker daily running a Rails + PostgreSQL + Nginx stack on AWS EC2. If you have questions about specific setups — drop them in the comments.

5 Security Mistakes I See on Every Server Audit

Alex Boguslavets — Wed, 22 Apr 2026 10:55:00 +0000

Every server I audit has at least three of these issues. They're simple to fix, yet consistently overlooked. A single breach can cost a small business thousands of dollars in downtime, data loss, and reputation damage.

1. SSH with Password Authentication

If your server accepts SSH passwords, it's being brute-forced right now. Check your /var/log/auth.log — you'll see hundreds of failed login attempts daily from bots around the world.

Fix: Switch to SSH key authentication and disable password login:

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

This single change eliminates 99% of brute-force attacks. Takes 5 minutes.

2. No Firewall Rules

I regularly find servers with all ports open to the internet. Database ports (3306, 5432), Redis (6379), admin panels — all accessible from anywhere.

Fix: Use ufw to allow only what's needed:

ufw default deny incoming
ufw allow 22/tcp    # SSH
ufw allow 80/tcp    # HTTP
ufw allow 443/tcp   # HTTPS
ufw enable

3. Unattended Upgrades Disabled

Security patches are released weekly. If your server isn't automatically installing them, you're running known-vulnerable software. The Equifax breach happened because of an unpatched vulnerability — the fix had been available for months.

Fix: Enable automatic security updates on Ubuntu:

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

4. Running Services as Root

If your web application runs as root and gets compromised, the attacker has full control of your server. Running services as unprivileged users limits the blast radius of any vulnerability.

Fix: Create dedicated users for each service. With Docker, don't run containers with --privileged unless absolutely necessary.

5. No Backups (or Untested Backups)

Having backups is step one. Testing them is step two — and most people skip it. I've seen companies discover their backups were corrupted only when they needed to restore.

Fix: Automate daily backups to an external location (S3, another server). Set up a monthly restore test. If you can't restore it, it's not a backup — it's a hope.

Take Action Today

These five fixes take less than an hour total and dramatically improve your security posture.

Not sure about your server's security? I offer comprehensive server audits with a detailed report and remediation plan. Contact me for a security review.

Monitoring 101: Grafana + Prometheus for Your Infrastructure

Alex Boguslavets — Tue, 21 Apr 2026 07:14:00 +0000

How do you know your server is healthy right now? Is CPU at 90%? Is the disk almost full? Are response times increasing? If you can't answer these questions instantly, you need monitoring.

Most businesses discover problems the worst way possible: customers complain. By then, you've already lost revenue and trust. Good monitoring means you know about issues before your users do.

The Monitoring Stack

Prometheus collects metrics from your servers and applications. It scrapes data every 15 seconds and stores it in a time-series database.

Grafana visualizes those metrics in beautiful, customizable dashboards. CPU usage over time, memory trends, request rates — all in real-time.

Alertmanager sends notifications when things go wrong. Email, Slack, Telegram, PagerDuty — choose your channel.

What to Monitor

Start with the "USE" method:

Utilization — CPU, memory, disk usage percentage
Saturation — queue lengths, swap usage, I/O wait
Errors — 5xx responses, failed requests, connection timeouts

For web applications, add:

Response time (p50, p95, p99)
Request rate (requests per second)
Error rate (percentage of failed requests)
Database query time

Alerting Done Right

The biggest mistake in monitoring is too many alerts. If everything is "critical," nothing is.

Alert on symptoms, not causes — "website is slow" is better than "CPU is high"
Set meaningful thresholds — 80% disk usage is a warning, 95% is critical
Include runbook links — every alert should tell you what to do next
Avoid alert fatigue — if you're ignoring alerts, your thresholds are wrong

Getting Started

The easiest way to start is with Docker Compose. Prometheus, Grafana, and node_exporter can be running in under 10 minutes. There are also excellent community dashboards for common setups — no need to build from scratch.

If your infrastructure runs without monitoring, you're flying blind.

I can set up a complete monitoring stack for your infrastructure in a day. Reach out and stop guessing.

How AI Tools Are Changing DevOps: My Real Experience

Alex Boguslavets — Mon, 20 Apr 2026 14:00:00 +0000

When ChatGPT launched, many people panicked. "AI will replace developers!" In reality, after using AI tools daily for over a year: AI doesn't replace engineers — it amplifies them. I'm 2-3x more productive, not because AI writes my code, but because it eliminates the boring parts.

What I Actually Use AI For

1. Writing Ansible Playbooks and Scripts

Instead of spending 30 minutes writing a playbook from scratch, I describe what I need: "Create an Ansible playbook that installs Docker on Ubuntu 22.04, adds the current user to the docker group, and enables the service." I get a working draft in seconds, then review and customize it.

2. Debugging Configuration Issues

Nginx returning 502? Paste the error log into Claude, describe your setup, and get targeted suggestions. AI is excellent at pattern-matching common misconfigurations that would take 45 minutes of Stack Overflow browsing.

3. Writing Documentation

Nobody likes writing runbooks. I describe the procedure, AI generates clean structured documentation. I review it, add context — done in a quarter of the time.

4. Learning New Tools

"Explain Prometheus alerting rules with examples" gives you a personalized tutorial instantly. Like having a senior engineer available 24/7.

What AI Is Bad At

Architecture decisions — AI doesn't understand your business context, budget, or team capabilities
Security-critical configurations — always verify against official documentation
Debugging production issues — AI can help analyze logs, but it can't access your systems
Novel problems — if it's not in the training data, AI will confidently give you wrong answers

My AI Toolkit

Claude — my go-to for complex tasks, long documents, and code review. Excellent reasoning.

ChatGPT — great for quick questions and brainstorming.

GitHub Copilot — autocomplete on steroids. Saves time on repetitive patterns.

Claude Code — this entire website was built with AI assistance. Blog, payments, SEO — all developed faster thanks to AI pair programming.

The Bottom Line

AI tools are not magic — they're power tools. A chainsaw doesn't make you a lumberjack, but a lumberjack with a chainsaw is 10x more productive than one with an axe.

Want to learn how AI can speed up your infrastructure work? Book a free consultation.

Docker for Beginners: Containerize Your App in 30 Minutes

Alex Boguslavets — Mon, 20 Apr 2026 05:30:10 +0000

"It works on my machine" — the most dreaded phrase in software development. Docker eliminates this problem entirely. When your app runs in a Docker container, it runs the same way everywhere: on your laptop, on your colleague's Mac, on a Linux server in AWS.

Key Concepts in Plain Language

Image — a blueprint (recipe) for your container. Think of it as a snapshot of a configured system.

Container — a running instance of an image. You can run multiple containers from the same image.

Dockerfile — a text file with instructions on how to build your image.

Docker Compose — a tool for running multiple containers together (e.g., your app + database + Redis).

A Real Dockerfile Example

Here's a Dockerfile for a Rails application:

FROM ruby:3.3

WORKDIR /app

COPY Gemfile Gemfile.lock ./

RUN bundle install

COPY . .

EXPOSE 3000

CMD ["rails", "server", "-b", "0.0.0.0"]

Six lines that package your entire application into a portable container.

Docker Compose: The Real Power

Most applications need more than one service. Docker Compose lets you define everything in one file:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data

Run docker compose up and your entire stack starts in seconds.

When to Use Docker

Your team works on different operating systems
You need consistent environments across dev, staging, and production
You want to simplify deployment and scaling
You're setting up a CI/CD pipeline

If you're still installing dependencies manually on each server, Docker will change your workflow forever.

Need help containerizing your application? Let's talk.

Why Every Small Business Needs a CI/CD Pipeline in 2026

Alex Boguslavets — Thu, 16 Apr 2026 07:00:00 +0000

If you're still deploying your application by SSHing into a server and running commands manually, you're not alone — but you're losing money. Every manual deployment is a risk: a forgotten step, a typo in a command, or a missing environment variable can bring your site down.

I've seen teams spend 2-3 hours on each deployment, doing the same repetitive steps every time. That's 2-3 hours of skilled developer time wasted on something a machine can do in 2 minutes.

What Is CI/CD and Why Should You Care?

CI (Continuous Integration) means every code change is automatically tested. CD (Continuous Deployment) means every tested change is automatically deployed to your server. Together, they form a pipeline that takes your code from a Git push to a live website — without human intervention.

Here's what a typical pipeline looks like:

Developer pushes code to GitHub
Automated tests run (unit tests, linting, security checks)
If tests pass, code is deployed to staging
After approval, code goes to production

Real Example: A Self-Hosted Pipeline

This website uses GitHub Actions with a self-hosted runner. When I push to master:

on:
  push:
    branches: [master]

jobs:
  deploy:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4      - name: Sync files
        run: rsync -av --exclude='.git' . ubuntu@server:/app      - name: Restart app
        run: ssh ubuntu@server "cd /app && docker compose restart web"

Total deploy time: under 60 seconds. Zero manual steps.

The ROI Is Obvious

	Manual deployment	CI/CD pipeline
Time per deploy	30-120 min	1-2 min
Human error risk	High	Near zero
Deploy frequency	Weekly (fear-driven)	Daily or more
Rollback time	30-60 min	1 click

Teams with CI/CD deploy 10-20x more frequently and have 5x fewer incidents according to the DORA metrics report.

You Don't Need to Start Big

You don't need a complex setup on day one. Start with:

GitHub Actions — free for public repos, 2,000 min/month free for private
One job — just run tests on every push
Add deploy step — rsync + restart when tests pass

That's it. You can add staging environments, approval gates, and notifications later.

Common Objections

"Our app is too simple for CI/CD." No app is too simple. Even a static website benefits from automated deploys.

"It takes too long to set up." A basic pipeline takes 1-2 hours. You'll recover that time on the first deployment.

"Our team is too small." Solo developers benefit the most — you have no one to catch your mistakes.

The Bottom Line

CI/CD isn't a luxury for big tech companies. It's a basic hygiene practice that any team of any size can implement in an afternoon.

Want a CI/CD pipeline set up for your project? Browse our automation services or book a free call.

Docker Compose in Production: Is It a Good Idea?

Alex Boguslavets — Wed, 15 Apr 2026 11:10:58 +0000

"Use Kubernetes in production, Docker Compose is just for development." You've probably heard this. It's not wrong — but it's also not the whole story. For small teams, single-server setups, and projects that don't need horizontal scaling, Docker Compose in production is a completely valid choice.

This very website runs on Docker Compose in production — on a single AWS t3.micro instance. Here's what I've learned.

When Docker Compose in Production Makes Sense

Single server setup — your app fits on one machine (most small businesses do)
Low traffic — under ~1,000 concurrent users
Small team — 1-5 developers who don't want Kubernetes complexity
Predictable load — no need for auto-scaling
Budget constraints — one EC2 instance costs $15-30/month vs $150+ for managed Kubernetes

The Real Limitations

No auto-healing — if a container crashes, you need a restart policy to bring it back
No horizontal scaling — you can't easily add more web servers
No rolling deployments — deploys cause a brief downtime window
Single point of failure — if the server goes down, everything goes down

Making It Production-Ready

With a few additions, Docker Compose becomes quite robust:

services:
  web:
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      retries: 3
  nginx:
    restart: unless-stopped
  db:
    restart: unless-stopped
    volumes:
      - postgres_data:/var/lib/postgresql/data

Add restart: unless-stopped to every service. It ensures containers come back up after a server reboot or crash.

Deployment Without Downtime

Zero-downtime deploys with Docker Compose require a bit of creativity:

Sync new code to the server (rsync)
Build the new image: docker compose build web
Run migrations: docker compose exec web rails db:migrate
Reload: docker compose up -d --no-deps web

Nginx continues serving the old container while the new one starts. The gap is typically under 5 seconds.

When to Move to Kubernetes

Graduate to Kubernetes when you need: multiple servers, auto-scaling, canary deployments, or if your team grows beyond 10 engineers. For everything else, Docker Compose is fast, simple, and reliable enough.

Need help containerizing your application? Browse our containerization services.

GitHub Actions vs GitLab CI: Which One Should You Use in 2026?

Alex Boguslavets — Wed, 15 Apr 2026 09:05:08 +0000

GitHub Actions and GitLab CI are the two dominant CI/CD platforms in 2026. If your code is already on one platform, the answer is usually obvious. But for new projects — or migrations — the choice matters.

Here's what I've learned running both in production.

GitHub Actions: Strengths

Ecosystem is unmatched. The GitHub Marketplace has thousands of pre-built actions for everything from deploying to AWS to sending Slack notifications. Most open-source projects use GitHub Actions, so finding examples is easy.

Self-hosted runners are simple to set up. Add a runner to your server in 10 minutes. This is how I deploy this website — a macOS runner on my own machine handles all deployments for free.

Tight GitHub integration. Branch protection rules, required status checks, environment protection rules, and deployment history are all first-class features.

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4      - run: ./deploy.sh

GitLab CI: Strengths

All-in-one platform. GitLab includes built-in container registry, package registry, security scanning, dependency scanning, and infrastructure management. With GitHub you need to integrate these separately.

Better for private infrastructure. GitLab's self-hosted option (GitLab CE/EE) gives you full control — useful for enterprises with strict compliance requirements.

Pipeline visualization is superior. GitLab's pipeline UI shows stages, job dependencies, and artifacts more clearly than GitHub Actions' linear view.

stages:
  - test
  - build
  - deploy

deploy:
  stage: deploy
  script:
    - rsync -av . user@server:/app  only:
    - main

The Honest Comparison

Feature	GitHub Actions	GitLab CI
Free minutes (public repos)	Unlimited	400/month
Free minutes (private repos)	2,000/month	400/month
Marketplace/integrations	Excellent	Good
Self-hosted	Good	Excellent
Built-in security scanning	Basic (paid)	Included
Pipeline UI	Good	Excellent

My Recommendation

Choose GitHub Actions if: your team lives in GitHub, you work with open-source, or you want the largest ecosystem of ready-made integrations.

Choose GitLab CI if: you need a self-hosted all-in-one platform, work in an enterprise with compliance requirements, or value built-in security scanning.

For most small-to-medium teams in 2026: GitHub Actions wins on convenience. For enterprises needing full control: GitLab CI wins on completeness.

Need help setting up a CI/CD pipeline? Browse our DevOps services or contact us directly.

GitHub Actions vs GitLab CI: Which One Should You Use in 2026? delete

Alex Boguslavets — Wed, 15 Apr 2026 09:01:06 +0000

Here's what I've learned running both in production.

GitHub Actions: Strengths

Self-hosted runners are simple to set up. Add a runner to your server in 10 minutes. This is how I deploy this website — a macOS runner on my own machine handles all deployments for free.

Tight GitHub integration. Branch protection rules, required status checks, environment protection rules, and deployment history are all first-class features.

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4      - run: ./deploy.sh

GitLab CI: Strengths

Better for private infrastructure. GitLab's self-hosted option (GitLab CE/EE) gives you full control — useful for enterprises with strict compliance requirements.

Pipeline visualization is superior. GitLab's pipeline UI shows stages, job dependencies, and artifacts more clearly than GitHub Actions' linear view.

stages:
  - test
  - build
  - deploy

deploy:
  stage: deploy
  script:
    - rsync -av . user@server:/app  only:
    - main

The Honest Comparison

Feature	GitHub Actions	GitLab CI
Free minutes (public repos)	Unlimited	400/month
Free minutes (private repos)	2,000/month	400/month
Marketplace/integrations	Excellent	Good
Self-hosted	Good	Excellent
Built-in security scanning	Basic (paid)	Included
Pipeline UI	Good	Excellent

My Recommendation

Choose GitHub Actions if: your team lives in GitHub, you work with open-source, or you want the largest ecosystem of ready-made integrations.

Choose GitLab CI if: you need a self-hosted all-in-one platform, work in an enterprise with compliance requirements, or value built-in security scanning.

For most small-to-medium teams in 2026: GitHub Actions wins on convenience. For enterprises needing full control: GitLab CI wins on completeness.

Need help setting up a CI/CD pipeline? Browse our DevOps services or contact us directly.

AWS Cost Optimization: 7 Things You're Probably Overpaying For

Alex Boguslavets — Wed, 15 Apr 2026 08:54:47 +0000

Most AWS bills have hidden waste. I've audited dozens of AWS accounts and the same patterns appear every time. Companies pay 30-50% more than they need to — not because AWS is expensive, but because the defaults are not optimized for cost.

1. Oversized EC2 Instances

That t3.large running at 5% CPU? You're paying for capacity you don't use. AWS Cost Explorer shows CPU and memory utilization history. Check it. Most workloads can run on a size smaller than what was originally provisioned "just to be safe."

Fix: Enable AWS Compute Optimizer. It analyzes 14 days of metrics and recommends right-sized instances. Potential savings: 30-60% on compute.

2. Unattached EBS Volumes

Every time you terminate an EC2 instance without deleting its storage volume, the volume keeps charging you. These "orphan" volumes accumulate silently.

Fix: Run this to find them:

aws ec2 describe-volumes --filters Name=status,Values=available

Delete what you don't need. Set "Delete on termination" to true for new instances.

3. Old Snapshots Nobody Deleted

EBS snapshots cost $0.05/GB/month. A 100GB snapshot taken daily for a year = $1,825/year in snapshots alone.

Fix: Use AWS Backup with lifecycle policies to automatically expire snapshots after 30-90 days.

4. NAT Gateway Data Transfer

NAT Gateways charge $0.045 per GB processed. If your EC2 instances pull large Docker images through a NAT Gateway, costs add up fast.

Fix: Use VPC endpoints for S3 and ECR (free data transfer). Cache Docker layers locally.

5. On-Demand Instances for Stable Workloads

On-Demand is the most expensive pricing model. If your production server runs 24/7, you're overpaying by 30-60% compared to Reserved Instances or Savings Plans.

Fix: Buy a 1-year Compute Savings Plan for your baseline capacity. Keep On-Demand only for burst workloads.

6. Unused Elastic IPs

Elastic IPs are free when attached to a running instance. When unattached: $0.005/hour = $3.60/month each.

Fix: Audit your EIPs monthly. Release any that aren't attached to a running instance.

7. CloudWatch Logs Retention Set to "Never Expire"

CloudWatch Logs storage costs $0.03/GB/month with no expiry by default. Application logs grow quickly.

Fix: Set retention to 30-90 days on all log groups. Export older logs to S3 where storage costs 80% less.

The Bottom Line

AWS cost optimization isn't a one-time task — it's an ongoing practice. Set up a monthly cost review, use AWS Cost Anomaly Detection for alerts, and tag everything so you know what each service costs.

Most clients I work with save 25-40% within the first month of a cloud audit.

Need a cloud cost audit for your AWS account? Get in touch.