My CI Pipeline Failed on the First Push. Here's What I Learned.

Tanay Jain — Sun, 03 May 2026 12:59:58 +0000

My CI pipeline failed on the first push.

Not because of a big mistake.
Because of a layer conflict in my Dockerfile that
only showed up in a clean environment.

Locally — everything worked.
CI — red on the first run.

That one failure taught me more about Docker
than a week of tutorials.

Here's exactly what I built and what happened.

The Project

A Flask + PostgreSQL app running in Docker Compose.

It tracks page visits and stores the count
in a real PostgreSQL database.
Browser → Flask Container → PostgreSQL → pgdata Volume

Multi-container setup. Persistent storage.
Environment variables via .env.
Health checks and restart policies.

Every decision is production-style —
even though it's a learning project.

Why I Added CI

Before CI, my workflow looked like this:
Make a change
↓
docker compose down
↓
docker compose build
↓
docker compose up -d
↓
Open browser, check manually
↓
Repeat

This works for one or two changes.

But when you're pushing regularly —
manually checking every time is not sustainable.

I wanted the system to tell me if something broke.
Not discover it later.

What I Built

.github/workflows/docker-build.yml

name: Docker Build CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Setup Docker Buildx
      uses: docker/setup-buildx-action@v2

    - name: Build Docker image
      run: docker build -t flask-app:test .

    - name: Verify image exists
      run: docker images | grep flask-app

    - name: Run container test
      run: |
        docker run --rm flask-app:test python -c "
        import flask
        import psycopg2
        print('Flask:', flask.__version__)
        print('All imports OK')
        "

    - name: Check image size
      run: |
        SIZE=$(docker image inspect flask-app:test \
        --format='{{.Size}}')
        echo "Image size: $SIZE bytes"
        echo "Build verified"

What Each Step Does

Checkout — GitHub's server downloads my code

Docker Buildx setup — Prepares build tools on the runner

Build image — Runs my Dockerfile from scratch,
clean environment every time

Verify image — Confirms image was actually created

Container test — Runs the container,
checks Flask and psycopg2 import correctly

Size check — Tracks image size on every build

The First Run Failed

Pushed the code. Opened Actions tab. Red.

The error was in my Dockerfile.

I had this:

RUN apt-get update && apt-get install -y curl \
    && rm -rf /var/lib/apt/lists/*

The layer order was causing a conflict
in the clean CI environment that
didn't show up on my machine.

Reordered the layers. Pushed again. Green.

This is the whole point of CI.

Your local machine has cached layers,
existing images, leftover containers.
CI starts completely fresh every time.

It catches what you miss.

The Health Endpoint

I also added a /health route to Flask:

@app.route("/health")
def health():
    try:
        conn = get_connection()
        conn.close()
        return {"status": "healthy", "database": "connected"}, 200
    except Exception as e:
        return {"status": "unhealthy", "error": str(e)}, 500

A running container doesn't mean a working app.

This endpoint checks actual database connectivity.
200 = Flask is up and DB is reachable.
500 = Something broke inside.

Real monitoring tools and load balancers
use exactly this kind of endpoint.

Architecture

GitHub Actions CI:
Code Push → Build → Test → Validate
↓
Docker Hub (image stored)
↓
AWS EC2 (deployed)
↓
Flask Container ←→ PostgreSQL Container
↓
pgdata Volume

Project Versioning

v1.0 — Flask + PostgreSQL + Docker + EC2 deploy
v1.1 — CI pipeline + /health endpoint added

Tagging versions made me treat this
like a real product — not just practice code.

What Actually Changed

Before:
Push code → manually test → hope for the best.

After:
Push code → pipeline runs in ~2 minutes → green or red.

No guessing. No "I think it should work."
The pipeline knows.

Three Things CI Taught Me Practically

1. Clean environment matters

Your machine lies to you.
Cached layers, existing images, leftover state —
none of that exists in CI.

If it works locally but fails in CI,
the CI is right.

2. The pipeline is documentation

Anyone reading the workflow file
understands exactly how the project builds.
No README needed for that part.

3. Start CI early

Adding it to an existing project is harder
than starting with it.

Next project — pipeline goes in on day one.

Links

GitHub: https://github.com/tj2905

Docker Hub: docker pull tanayjain29/flask-devops-app:v1.0

Learning by building real things.

Turning ideas into working projects.
Sharing everything on GitHub.

From Zero to Deployment: Dockerizing a Flask + PostgreSQL App on AWS

Tanay Jain — Sun, 29 Mar 2026 18:56:16 +0000

When I started learning Docker, I had no idea I’d end up deploying a real application on a cloud server within the same month.

It ended up changing how I think about building software.

The Idea

I didn’t want to build just another static project.

I wanted:

A real backend
A real database
A real deployment

So I built a simple web app that tracks page visits and stores them in PostgreSQL.

Tech Stack

Python Flask (backend)
PostgreSQL (database)
Docker & Docker Compose
AWS EC2 (deployment)

Architecture

User (Internet)
   ↓
AWS EC2 Server
   ↓
Docker Engine
   ↓
Flask Container (Port 80)
   ↓ psycopg2
PostgreSQL Container
   ↓
Persistent Volume (pgdata)

Key Concepts I Implemented

🔹 Multi-container system

Instead of running containers manually, I used Docker Compose.

docker compose up -d

This starts the entire system in one command.

🔹 Environment variables (.env)

No secrets inside the code.

Cleaner
Safer
Production-ready

🔹 Health checks

Docker monitors the application continuously.

If Flask stops responding, the container is marked as unhealthy.

🔹 Auto-restart

Using:

restart: always

If a container crashes, Docker automatically restarts it.

🔹 Optimized Dockerfile

Used python:3.10-slim
Cleared apt cache after install
Used --no-cache-dir for pip
Optimized layer ordering

Result: Image size reduced significantly (~300MB → ~160MB)

Biggest Challenge

Connecting Flask to PostgreSQL inside Docker.

The key realization:

Containers communicate using service names, not IP addresses.

DB_HOST=db

Docker internally resolves db to the PostgreSQL container.

Once this clicked, the setup became much clearer.

Deployment

I deployed the app on AWS EC2.

Steps:

Launch EC2 instance
Install Docker
Clone project
Run Docker Compose

The application was then accessible via a public IP.

What I Learned

Docker is not just about containers.

It’s about building systems that are:

Reproducible
Isolated
Self-healing
Easy to deploy

Final Thoughts

This project was my first real experience combining backend, database, and deployment into one system.

If you're learning Docker, building and deploying even a small project like this gives much more clarity than just following tutorials.

DEV Community: Tanay Jain

My CI Pipeline Failed on the First Push. Here's What I Learned.

The Project

Why I Added CI

What I Built

What Each Step Does

The First Run Failed

The Health Endpoint

Architecture

Project Versioning

What Actually Changed

Three Things CI Taught Me Practically

Links

From Zero to Deployment: Dockerizing a Flask + PostgreSQL App on AWS

The Idea

Tech Stack

Architecture

Key Concepts I Implemented

🔹 Multi-container system

🔹 Environment variables (.env)

🔹 Health checks

🔹 Auto-restart

🔹 Optimized Dockerfile

Biggest Challenge

Deployment

What I Learned

Links

Final Thoughts