DEV Community: Alex Boguslavets

If Your Infrastructure Exists Only as a Series of Clicks, You Have a Problem

Alex Boguslavets — Fri, 10 Jul 2026 08:10:56 +0000

You set up a server in the AWS Console. You click through security groups, configure load balancers, set up RDS. Everything works. Two months later, you need an identical staging environment. Can you reproduce it exactly?

Probably not. Because your infrastructure exists only as a series of clicks you've long forgotten. No documentation, no version history, no way to roll back. This is the core problem Infrastructure as Code (IaC) solves.

I've seen this pattern dozens of times with clients: a critical server goes down, and the person who set it up left the company six months ago. Nobody knows exactly how it was configured. Recovery takes days instead of minutes.

Terraform: your infrastructure blueprint

Instead of clicking through the AWS Console, you describe your infrastructure in code:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  vpc_security_group_ids = [aws_security_group.web.id]
  subnet_id              = aws_subnet.public.id

  tags = {
    Name        = "production-web"
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

resource "aws_security_group" "web" {
  name = "web-server-sg"

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Run terraform plan to see what will change. Run terraform apply and it creates everything. Need to change instance type? Edit the file, apply again. Terraform figures out what changed and updates only what's necessary.

The beauty of this approach: your .tf files become the single source of truth. New team member joins? They read the Terraform code and understand the entire infrastructure in an hour.

Ansible: configuration management

Terraform creates infrastructure — servers, databases, networks. But who installs Docker on that server? Who configures Nginx? Who deploys the application? That's where Ansible comes in.

- name: Configure web server
  hosts: web_servers
  become: yes
  tasks:
    - name: Install Docker
      apt:
        name: docker.io
        state: present

    - name: Install Nginx
      apt:
        name: nginx
        state: present

    - name: Copy Nginx config
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/sites-available/default
      notify: restart nginx

    - name: Deploy application
      docker_container:
        name: myapp
        image: "ghcr.io/myorg/myapp:latest"
        ports:
          - "8080:3000"
        restart_policy: always

  handlers:
    - name: restart nginx
      service:
        name: nginx
        state: restarted

Ansible connects via SSH — no agents to install, no daemons to manage. You write what you want the server to look like, and Ansible makes it happen. Run it once or a hundred times — the result is the same (idempotency).

The power combo: Terraform + Ansible + Git

Here's how these tools work together in a real production workflow:

Terraform provisions cloud resources — EC2 instances, RDS databases, VPCs, S3 buckets, load balancers, DNS records
Ansible configures those resources — installs software, deploys applications, manages configs, sets up monitoring
Git versions everything — every change is tracked, reviewed via pull requests, and reversible with git revert

This means you can spin up an identical environment in minutes. Disaster recovery goes from "days of panic" to "run two commands."

A real-world example

One of my clients had a setup where everything was configured manually in AWS Console over two years. When their primary server had a disk failure:

Before IaC: 3 days of downtime, 2 engineers working around the clock, several misconfigurations discovered only after launch, $15,000+ in lost revenue
After IaC migration: We recreated the entire infrastructure in 47 minutes from Terraform + Ansible code. Zero misconfigurations. The app was back online before most users noticed.

The migration to IaC took 3 weeks. It paid for itself on the first incident.

Real benefits I've seen with clients

Reproducibility — "works on my environment" is no longer a problem. Staging = Production, always.
Speed — new environments go from days to minutes.
Documentation — your Terraform files ARE your documentation. No more outdated Confluence pages.
Disaster recovery — server died? Terraform recreates it, Ansible reconfigures it. Under an hour.
Cost control — see exactly what resources you're paying for in a single file.
Audit trail — every infrastructure change goes through a pull request.

How to start (without breaking everything)

Step 1: Pick one resource. Start with something non-critical — maybe a dev server or an S3 bucket. Define it in Terraform.

Step 2: Use terraform import to bring existing resources under Terraform management without recreating them.

Step 3: Write an Ansible playbook for something you do regularly — like deploying a new version of your app.

Step 4: Put everything in Git. Set up a CI/CD pipeline that runs terraform plan on pull requests.

Step 5: Expand gradually. Each week, bring one more manually managed resource under IaC control.

If your infrastructure is still managed by clicking through cloud consoles, you're one bad day away from a disaster you can't recover from. The good news? You can start fixing this today.

Full article: alexxdevops.com
Book a free consultation: calendly.com/oleksii-bohuslavets/30min

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.

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.

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.