DEV Community: Alex Boguslavets

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.