DEV Community: Gravox

Auto Deploy Docker Compose Apps to AWS EC2 using GitHub Actions (Production-Style Guide)

Gravox — Tue, 02 Jun 2026 16:29:51 +0000

Manual deployment quickly becomes unsustainable once infrastructure complexity increases.

Repeated SSH sessions, manual git pull, rebuilding containers, restarting services, and validating application health introduce operational inconsistency and deployment risk.

This walkthrough documents a reproducible CI/CD deployment pipeline where every push to GitHub automatically rebuilds and redeploys Docker Compose services on AWS EC2.

The final deployment architecture consisted of:

GitHub Repository
│
▼
GitHub Actions
│
▼
SSH into AWS EC2
│
▼
Docker Compose Orchestration
│
┌──────┼────────┐
▼ ▼ ▼
Nginx Flask PostgreSQL
│
▼
Public Endpoint (:8080)

The implementation surfaced multiple real-world infrastructure issues:

workflow detection failures

missing YAML assumptions

Docker Compose context problems

healthy containers with inaccessible public services

AWS networking restrictions

Rather than omitting failures, this guide documents the actual debugging process and resolutions.

Prerequisites

Before starting, provision the following:

Infrastructure

AWS EC2 instance (Ubuntu 22.04 LTS)

GitHub repository

Docker

Docker Compose

SSH access

Skills

Basic familiarity with:

Linux terminal

Git

Docker

GitHub Actions

Step 1 — Provision AWS EC2

Launch an Ubuntu EC2 instance.

Recommended configuration:

Setting Value

OS Ubuntu 22.04 LTS
Instance t2.micro (lab)
Storage 20GB
Security Group SSH + App Port

Validate SSH Connectivity

Before touching CI/CD, validate server accessibility.

From local terminal:

nc -zv 22

Expected result:

Connection to port 22 succeeded

Then SSH into the instance:

ssh ubuntu@

Successful connection should display Ubuntu system information.

Verify SSH Service

Once connected:

sudo systemctl status ssh

Expected output:

Active: active (running)

This confirms remote deployment automation will be possible.

Step 2 — Configure Repository Structure

Repository structure matters for GitHub Actions detection.

Final structure:

devops-lab/
│
├── .github/
│ └── workflows/
│ └── compose-rebuild-test.yml
│
└── compose-rebuild-test/
├── app/
├── nginx/
├── docker-compose.yml
└── test.txt

A common failure occurs when workflow files are placed inside nested folders.

Incorrect:

project-folder/.github/workflows

Correct:

repository-root/.github/workflows

GitHub only detects workflows at repository root.

Step 3 — Create Docker Compose Stack

The stack consisted of:

Flask application

PostgreSQL database

Nginx reverse proxy

docker-compose.yml

version: "3.9"

services:

flask:
build: ./app
container_name: flask_app

environment:
  POSTGRES_HOST: postgres
  POSTGRES_DB: mydatabase
  POSTGRES_USER: myuser
  POSTGRES_PASSWORD: mypassword

depends_on:
  - postgres

restart: unless-stopped

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
  interval: 10s
  timeout: 3s
  retries: 3

postgres:
image: postgres:15
container_name: postgres_db

environment:
  POSTGRES_DB: mydatabase
  POSTGRES_USER: myuser
  POSTGRES_PASSWORD: mypassword

volumes:
  - postgres_data:/var/lib/postgresql/data

restart: unless-stopped

healthcheck:
  test: ["CMD-SHELL", "pg_isready -U myuser -d mydatabase"]
  interval: 10s
  timeout: 5s
  retries: 5

nginx:
image: nginx:latest
container_name: nginx_server

ports:
  - "8080:80"

volumes:
  - ./nginx/default.conf:/etc/nginx/conf.d/default.conf

depends_on:
  - flask

restart: unless-stopped

volumes:
postgres_data:

Why This Architecture?

Flask

Application runtime.

Responsibilities:

business logic

database communication

API handling

Health checks ensure unhealthy containers are detected:

healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5000/health"]

PostgreSQL

Persistent storage layer.

Volume mounting ensures state persistence:

volumes:

postgres_data:/var/lib/postgresql/data

This prevents data loss during redeployments.

Nginx

Acts as public ingress layer.

Traffic flow:

Internet
│
▼
Nginx (:8080)
│
▼
Flask (:5000)
│
▼
PostgreSQL (:5432)

Step 4 — Configure GitHub Secrets

GitHub Actions requires secure authentication to EC2.

Navigate to:

Repository Settings
→ Secrets and Variables
→ Actions

Add:

Secret Purpose

EC2_HOST EC2 Public IP
EC2_USER ubuntu
EC2_SSH_KEY private SSH key

Step 5 — Create GitHub Actions Workflow

Create:

.github/workflows/compose-rebuild-test.yml

Add:

name: Compose Rebuild Test Deploy

on:
push:
branches:
- main
paths:
- 'compose-rebuild-test/**'

jobs:
deploy:
runs-on: ubuntu-latest

steps:
  - name: Checkout repo
    uses: actions/checkout@v4

  - name: Deploy compose-rebuild-test
    uses: appleboy/ssh-action@v1.0.3
    with:
      host: ${{ secrets.EC2_HOST }}
      username: ${{ secrets.EC2_USER }}
      key: ${{ secrets.EC2_SSH_KEY }}
      script_stop: true
      timeout: 60s
      command_timeout: 20m

      script: |
        echo "Connected to EC2"

        cd /home/ubuntu/devops-lab

        git pull origin main

        cd compose-rebuild-test

        docker compose down || true
        docker compose up --build -d

        docker ps

Deployment Behavior

Every push to:

main

that modifies:

compose-rebuild-test/**

automatically triggers:

Workflow execution
SSH into EC2
Repository sync
Compose teardown
Image rebuild
Container restart

Deployment becomes deterministic.

Step 6 — Validate Containers

After workflow execution:

SSH into EC2:

ssh ubuntu@

Check containers:

docker ps -a

Expected:

nginx_server Up
flask_app Healthy
postgres_db Healthy

Step 7 — First Major Failure

At this stage, infrastructure appeared healthy.

Containers:

✅ running

Health checks:

✅ healthy

Application:

❌ inaccessible publicly

This created misleading signals.

Local validation succeeded:

curl http://localhost:8080

Response:

CI/CD Auto Deploy Working

Yet:

http://:8080

failed externally.

Root Cause Analysis

This was not an application issue.

This was not Docker failure.

This was not Nginx misconfiguration.

Root cause:

AWS Security Group ingress restrictions

Port 8080 was blocked.

Step 8 — Fix AWS Security Group

Navigate to:

EC2
→ Security Groups
→ Inbound Rules

Add:

Type Port Source

Custom TCP 8080 0.0.0.0/0

Save changes.

Retry:

http://:8080

Success:

CI/CD Auto Deploy Working

Deployment validated.

Common Errors Encountered

Error 1 — Missing deploy.yml

Attempt:

cat .github/workflows/deploy.yml

Error:

No such file or directory

Cause:

Incorrect workflow assumption.

Actual file:

compose-rebuild-test.yml

Error 2 — Docker Compose Failure

Attempt:

docker compose ps

Error:

no configuration file provided

Cause:

Executed outside compose directory.

Fix:

cd compose-rebuild-test
docker compose ps

Error 3 — Healthy Containers, Broken Access

Cause:

Cloud networking layer.

Fix:

Open security group ingress.

Final Deployment Flow

Final architecture:

git push
│
▼
GitHub Actions
│
▼
SSH into EC2
│
▼
git pull origin main
│
▼
docker compose down
docker compose up --build -d
│
▼
Health validation
│
▼
Public endpoint live

Key Engineering Lessons

Healthy containers do not guarantee reachable services

Application validation must include:

Container
Host
Firewall
Cloud Security Group
Public Access

Repository topology matters

GitHub workflows must exist at:

.github/workflows

Docker Compose is execution-context sensitive

Directory placement matters.

Cloud networking frequently masquerades as application failure

Infrastructure debugging should never stop at container health.

Closing Thoughts

CI/CD implementation rarely fails for a single reason.

The real complexity emerges from interactions between:

cloud networking

orchestration

repository topology

deployment automation

infrastructure permissions

Once validated, the result becomes a reproducible deployment system where every push automatically rebuilds and redeploys production-like workloads.

Not Every CI/CD Pipeline Failure Is a Regression

Gravox — Thu, 28 May 2026 00:53:15 +0000

A recent deployment validation cycle triggered a failure during a rebuild workflow running on GitHub Actions.
Pipeline metadata:

Workflow: compose-rebuild-test.yml
Trigger: push
Stage Failed: deploy
Runtime Duration: 17s
Status: failure

At surface level, this appears like a broken deployment.
From an engineering perspective, this is useful system behavior.
The workflow terminated early enough to prevent deeper infrastructure mutation while still exposing actionable runtime telemetry.
Observed annotation:

Node.js 20 actions are deprecated

This highlights a common issue in modern CI/CD systems:
Infrastructure tooling evolves continuously beneath deployment logic.
Even stable pipelines can fail when upstream runtimes, execution environments, or dependency expectations shift independently.
Key engineering takeaways from this deployment event:

Failure visibility is operational maturity

A failing workflow with observable telemetry is significantly better than silent drift inside production infrastructure.

Fast-fail pipelines reduce debugging complexity

A 17-second termination window drastically narrows investigation scope compared to delayed deployment failures.

CI/CD systems are living infrastructure

Pipelines require maintenance just like applications, APIs, and container workloads.

Runtime deprecations are early warning systems

Warnings today frequently become hard failures later.

Reproducibility matters more than temporary success

An unstable but reproducible failure can be analyzed, documented, automated, and resolved systematically.
The deployment stack involved:

GitHub Actions

Docker Compose rebuild orchestration

Push-triggered automation

Deployment-stage validation

Runtime dependency checks

Engineering labs should document failures as aggressively as successes.
Reliable systems are built from repeated exposure to unstable states, edge conditions, and operational inconsistencies.
Not every day is green pipelines.
Some days are dedicated to observing how systems fail under real execution conditions.
That is still platform progress.

devops #cicd #docker #githubactions #platformengineering #sre #cloudcomputing #infrastructure #automation

Building a Multi-Container Flask, PostgreSQL, and NGINX Stack Using Docker Compose — Including Every Failure Encountered.

Gravox — Sat, 16 May 2026 00:28:37 +0000

A production-style application deployment rarely succeeds on the first attempt.

This project implemented a containerized multi-service architecture using Docker Compose, integrating Flask as the application layer, PostgreSQL as the persistence layer, Gunicorn as the WSGI runtime, and NGINX as the reverse proxy ingress service.

The intended architecture was:

Client → NGINX → Flask → PostgreSQL

The objective extended beyond simply getting containers running.

The implementation focused on:

Multi-container orchestration
Reverse proxy traffic routing
Inter-service communication
Stateful persistence with Docker volumes
Environment variable injection
Runtime debugging and remediation
Container observability and diagnostics

Several deployment failures occurred during implementation, each requiring troubleshooting and root cause analysis.

Issues encountered included:

Docker Compose manifest discovery failure due to incorrect directory placement.
Docker image build failures caused by malformed Dockerfile syntax.
Gunicorn runtime crashes resulting from incorrect CMD formatting.
NGINX ingress failure caused by invalid directive syntax ("listens" instead of "listen").
Flask runtime exceptions caused by Python syntax, indentation, and environment variable errors.

Each failure required log inspection, iterative debugging, configuration correction, rebuild execution, and container redeployment.

Validation was performed using:

docker compose logs -f
docker ps
docker volume ls
curl endpoint verification

Final deployment confirmed successful end-to-end communication between NGINX, Flask, and PostgreSQL.

This article documents the complete deployment lifecycle, architecture decisions, failure analysis, remediation strategy, and operational lessons learned while building the stack.

Building a Multi-Container Backend System with Docker Compose

Gravox — Tue, 12 May 2026 20:38:46 +0000

Building a Multi-Container Backend System with Docker Compose
Modern backend systems rarely operate as a single process runtime. Most production-grade architectures depend on multiple isolated services communicating over internal networks with persistent state management and deterministic deployment workflows.

This implementation focused on building a reproducible multi-container backend stack using Docker Compose.

Stack Overview
Application Layer
Flask REST API

Python runtime containerization

Dockerfile-based image builds

Data Layer
PostgreSQL service container

Persistent named volumes

Stateful data durability

Infrastructure Layer
Docker Compose orchestration

Internal bridge networking

Service discovery

Port exposure and container isolation

System Architecture
Client Request
↓
Flask API Container
↓
Docker Internal Network
↓
PostgreSQL Container
↓
Persistent Docker Volume
The architecture separates application runtime concerns from data persistence concerns while maintaining deterministic service communication.

Core Engineering Concepts Implemented

Multi-Container Orchestration Docker Compose was used to declaratively define infrastructure topology:

Service definitions

Build instructions

Dependency ordering

Network configuration

Persistent storage bindings

This removes manual container lifecycle management and creates reproducible infrastructure provisioning.

Internal Container Networking Containers communicate through Docker-managed bridge networking.

Instead of hardcoded IP allocation:

services resolve through internal DNS

containers communicate using service identifiers

network isolation is maintained automatically

Example:

DATABASE_URL=postgresql://user:password@db:5432/app
Where db resolves through Docker Compose service discovery.

Persistent Volume Management PostgreSQL data persistence was implemented using named Docker volumes.

Without persistent storage:

container recreation destroys state

database durability becomes ephemeral

With named volumes:

database state survives container restarts

storage lifecycle becomes decoupled from runtime lifecycle

Image Build Pipeline The Flask service was containerized through a Dockerfile-based build pipeline:

dependency installation

runtime packaging

application bootstrap configuration

immutable image generation

This enables environment parity across development and deployment targets.

Operational Outcomes
Validated capabilities:

Inter-service communication

Stateful persistence

Isolated runtime execution

Deterministic environment recreation

Compose-driven infrastructure provisioning

Container lifecycle orchestration

Engineering Takeaways
This implementation clarified several production backend fundamentals:

Stateless vs Stateful Services
Application containers remain disposable while databases require persistence guarantees.

Infrastructure as Code
Compose manifests become executable infrastructure definitions.

Network Abstraction
Backend services communicate through virtualized network layers instead of host-bound coupling.

Deployment Reproducibility
Containerized systems eliminate “works on my machine” drift through environment standardization.

Next Technical Targets
Planned extensions:

NGINX reverse proxy layer

Healthcheck directives

Multi-stage image optimization

CI/CD automation pipelines

Secret injection strategies

Metrics and observability

Horizontal scaling workflows

Kubernetes orchestration migration

Container orchestration fundamentally changes how backend systems are modeled, deployed, and scaled. Multi-container architecture introduces clearer service boundaries, reproducibility, and operational consistency compared to monolithic local runtime setups.

Building a Complete DevOps Pipeline on AWS EC2 Using Linux, Git, Docker, and Docker Compose

Gravox — Fri, 01 May 2026 17:50:11 +0000

Overview

This implementation demonstrates a full DevOps workflow executed on an Ubuntu-based AWS EC2 instance. The objective was to construct a complete infrastructure pipeline from system-level operations to container orchestration.

Linux Environment Setup

EC2 Ubuntu provisioning
CLI-based system interaction
directory and file structure management
system-level validation via shell utilities

Git Workflow Implementation

feature branch-based development model
commit lifecycle management
remote repository synchronization
branch merging into mainline

Docker Containerization

Docker engine installation and validation
execution of base containers (hello-world)
custom image creation using Nginx
static web application containerization

Networking and Port Mapping

host-to-container port mapping configuration
resolution of port allocation conflicts
validation of container accessibility via HTTP interface

Docker Compose Orchestration

declarative service definition using YAML
elimination of manual container execution
infrastructure-as-code deployment model
multi-container lifecycle management

Result

A fully functional containerized web service deployed on AWS EC2 using Docker Compose.

DevOps Lab Update — Docker Deployment on Ubuntu

Gravox — Thu, 30 Apr 2026 18:52:25 +0000

This lab documents the successful installation and validation of Docker Engine within a Linux-based environment, targeting core competencies expected of a DevOps Engineer.

Technical Milestones

Provisioned and configured an Ubuntu-based system environment
Deployed Docker Engine with systemd service management
Validated container runtime and daemon operations
Performed image acquisition and management via Docker Hub registry
Executed a containerized workload ("hello-world") to verify runtime behavior
Inspected container lifecycle, including initialization and termination states

This lab establishes foundational experience in container runtime environments and image lifecycle management.

Next Phase

Building custom Docker images using Dockerfiles
Running multi-container workloads and simulating deployment pipelines

devops #docker #linux #cloud #containers #aws #learninginpublic

Building a Linux-Based DevOps Automation Environment on AWS EC2

Gravox — Wed, 29 Apr 2026 19:22:33 +0000

This is the hashnode version for a blog i want you to create the dev.to platform and tailor it for dev.to audience more shorter and more trimmed
"Building a Linux-Based DevOps Automation Environment on AWS EC2
Introduction
This project demonstrates the design and implementation of a Linux-based DevOps workspace deployed on an AWS EC2 Ubuntu instance. The objective was to build a structured environment capable of supporting system automation, version control workflows, and scalable DevOps practices.
Infrastructure Setup
The environment was provisioned on an Ubuntu-based EC2 instance, providing a persistent Linux system for hands-on DevOps operations.
Key setup steps included:
SSH-based remote access
Directory-based workspace structuring
Persistent development environment configuration
Working directory:

/home/ubuntu/devops-lab
Workspace Architecture
A structured directory layout was created to separate responsibilities:

devops-lab/
├── scripts/
├── notes/
├── logs/
├── projects/
├── backups/
This structure enables modular development and operational clarity.
System Automation Scripts
System Information Script
A diagnostic script was developed to extract system-level information:
Capabilities:
User identification
Host information
System uptime
Memory usage
Disk usage
CPU information
This provides a lightweight system observability tool.
Backup Automation Script
A backup automation script was implemented using tar compression and timestamping.
Features:
Automatic directory backup
Timestamp-based versioning
Compressed archive generation
This simulates basic infrastructure backup operations used in production environments.
Git Workflow Implementation
Version control was managed using Git with a structured branching strategy:
Feature branches for development
Main branch for stable state
Merge-based integration workflow
Key operations:
Branch creation
Commit tracking
Remote synchronization
Feature-to-main merging
Outcome
The final system represents a fully functional DevOps lab environment capable of:
System monitoring via scripts
Automated backup generation
Version-controlled development lifecycle
Structured Linux workspace management
Conclusion
This project establishes a practical DevOps learning environment by combining Linux system administration, shell scripting, and Git-based workflow management in a cloud-hosted infrastructure."

Here’s a tighter, more dev.to–style version—cleaner, more direct, and easier to skim:

Building a Linux DevOps Lab on AWS EC2
Overview
I set up a lightweight DevOps lab on an Ubuntu EC2 instance to practice automation, system monitoring, and Git workflows in a real Linux environment.

⚙️ Infrastructure Setup
Ubuntu EC2 instance

SSH remote access

Persistent workspace

Working directory:

/home/ubuntu/devops-lab
📁 Project Structure
A simple, modular layout:

devops-lab/
├── scripts/
├── notes/
├── logs/
├── projects/
├── backups/
Keeps things organized and scalable as the lab grows.

🛠️ Automation Scripts
System Info Script
Quick system diagnostics:

Current user & hostname

Uptime

Memory & disk usage

CPU info

Backup Script
Basic automation using tar:

Compresses directories

Uses timestamps for versioning

Simulates real-world backup workflows

🌿 Git Workflow
Used a simple branching strategy:

main → stable code

feature branches → development

Core workflow:

Create branches

Commit changes

Merge into main

Sync with remote

✅ What This Achieves
Script-based system monitoring

Automated backups

Clean Git workflow

Structured Linux environment

Final Thoughts
This setup is a solid hands-on DevOps sandbox—combining Linux, scripting, and version control in a cloud environment. Simple, but very practical for learning real workflows.

If you want, I can make it even more “dev.to viral style” (with storytelling + hooks) or add diagrams/screenshots sections.

No man no such thing as "i" this is operating as a lab as a strict tone professional no emojis no personalization no allat just strict prpfessional tone and heavy use of tech jargon words

Understood. Here is a revised version with a strict, professional tone, no personalization, and more technical language:

Building a Linux-Based DevOps Automation Environment on AWS EC2
Overview
This project implements a Linux-based DevOps environment on an Ubuntu EC2 instance, designed to support infrastructure automation, system observability, and version-controlled workflows. The setup emphasizes modularity, reproducibility, and operational efficiency within a cloud-hosted context.

Infrastructure Configuration
The environment is provisioned on an Ubuntu-based Amazon EC2 instance, enabling persistent compute resources for DevOps operations.

Key configuration components include:

Secure Shell (SSH) for remote administration

Persistent filesystem configuration

Structured workspace initialization

Working directory:

/home/ubuntu/devops-lab
Workspace Architecture
A hierarchical directory structure is implemented to enforce separation of concerns and maintain operational clarity:

devops-lab/
├── scripts/
├── notes/
├── logs/
├── projects/
├── backups/
This layout facilitates modular script development, log aggregation, artifact storage, and project isolation.

Automation and Scripting
System Diagnostics Module
A shell-based diagnostic script is implemented to provide system-level telemetry, including:

User and host identification

System uptime metrics

Memory utilization statistics

Disk usage analysis

CPU information extraction

This module functions as a lightweight observability mechanism for runtime inspection.

Backup Automation Module
A backup routine is developed using tar for archival and compression.

Core capabilities:

Recursive directory backup

Timestamp-based versioning for snapshot differentiation

Generation of compressed archives for storage optimization

This approach models foundational backup strategies used in production-grade environments.

Version Control Workflow
Source control is managed using Git with a structured branching model to support parallel development and controlled integration.

Workflow characteristics:

Feature branch isolation for incremental development

Stable main branch for production-ready state

Merge-based integration strategy

Core operations include branch creation, commit tracking, remote synchronization, and controlled merges.

Outcome
The resulting environment delivers:

Script-driven system monitoring and diagnostics

Automated backup and archival processes

Version-controlled development lifecycle management

Structured and scalable Linux workspace organization

Conclusion
This implementation establishes a foundational DevOps lab environment by integrating Linux system administration, shell scripting, and Git-based workflow orchestration within a cloud infrastructure. The architecture supports extensibility and serves as a baseline for advanced DevOps practices such as CI/CD integration, configuration management, and infrastructure as code.