DEV Community: Latchu@DevOps

GitHub Actions workflow to deploy the Next.js Application on Vercel Cloud

Latchu@DevOps — Tue, 24 Feb 2026 18:41:04 +0000

In this article, I’ll walk you through setting up a GitHub Actions workflow to automatically deploy a Next.js application to Vercel.
Continuous deployment helps streamline development and ensures every push is production-ready.
We’ll configure secrets, create a workflow file, and connect GitHub with Vercel for seamless deployments.
This setup enables automated builds and previews for every commit.
Let’s dive into building a simple CI/CD pipeline for your Next.js app.

What We'll Build

A complete Next.js application that:

✅ Runs on Ubuntu 24 on port 80 as a background service
✅ Uses TypeScript and Tailwind CSS
✅ Has automated testing with Jest
✅ Auto-deploys to Vercel on every push
✅ Includes GitHub Actions CI/CD pipeline

Tech Stack

Next.js 14 (App Router)
TypeScript
Tailwind CSS
PM2 (Process Manager)
GitHub Actions
Vercel

📋 Prerequisites

Ubuntu 24.04 server (local or cloud)
GitHub account
Vercel account (free)

STEP 1: Install Node.js and Required Tools on local machine

# Update system
sudo apt update && sudo apt upgrade -y

# Install Node.js 20.x (LTS)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

# Verify installation
node --version   # Should show v20.x.x
npm --version    # Should show 10.x.x

# Install additional tools
sudo apt install -y git curl build-essential

# Install PM2 (process manager for background running)
sudo npm install -g pm2

# Verify PM2
pm2 --version

STEP 2: Create Next.js Application

# Create project directory
mkdir -p ~/nextjs-app
cd ~/nextjs-app

# Create Next.js app structure
# We'll create all files manually for complete control

Create Project Structure

# Create directories
mkdir -p app/{api/hello,components,lib,styles}
mkdir -p public/images
mkdir -p .github/workflows

# Create files
touch next.config.js
touch package.json
touch tsconfig.json
touch .gitignore
touch .env.local
touch README.md
touch ecosystem.config.js

Now, let's create each file with content:

File 1: package.json

cat > package.json << 'EOF'
{
  "name": "nextjs-app",
  "version": "1.0.0",
  "description": "Complete Next.js application with CI/CD",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start -p 80",
    "lint": "next lint",
    "test": "jest",
    "test:watch": "jest --watch"
  },
  "dependencies": {
    "next": "14.1.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@testing-library/jest-dom": "^6.1.5",
    "@testing-library/react": "^14.1.2",
    "@types/node": "^20.10.6",
    "@types/react": "^18.2.46",
    "@types/react-dom": "^18.2.18",
    "autoprefixer": "^10.4.16",
    "eslint": "^8.56.0",
    "eslint-config-next": "14.1.0",
    "jest": "^29.7.0",
    "jest-environment-jsdom": "^29.7.0",
    "postcss": "^8.4.32",
    "tailwindcss": "^3.4.0",
    "typescript": "^5.3.3"
  }
}
EOF

File 2: next.config.js

cat > next.config.js << 'EOF'
/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
  output: 'standalone',
  poweredByHeader: false,

  // Environment variables
  env: {
    NEXT_PUBLIC_APP_NAME: process.env.NEXT_PUBLIC_APP_NAME || 'Next.js App',
    NEXT_PUBLIC_API_URL: process.env.NEXT_PUBLIC_API_URL || 'http://localhost:80',
  },

  // Image optimization
  images: {
    domains: ['localhost'],
    formats: ['image/avif', 'image/webp'],
  },

  // Headers
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'X-Frame-Options',
            value: 'DENY',
          },
          {
            key: 'X-Content-Type-Options',
            value: 'nosniff',
          },
          {
            key: 'Referrer-Policy',
            value: 'origin-when-cross-origin',
          },
        ],
      },
    ];
  },
};

module.exports = nextConfig;
EOF

File 3: tsconfig.json

cat > tsconfig.json << 'EOF'
{
  "compilerOptions": {
    "target": "ES2020",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "paths": {
      "@/*": ["./*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules"]
}
EOF

File 4: .gitignore

cat > .gitignore << 'EOF'
# Dependencies
node_modules/
/.pnp
.pnp.js

# Testing
/coverage

# Next.js
/.next/
/out/
.next

# Production
/build
dist

# Misc
.DS_Store
*.pem
.vercel

# Debug
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# Local env files
.env*.local
.env.production

# PM2
.pm2

# IDE
.idea/
.vscode/
*.swp
*.swo
*~

# Logs
logs
*.log
EOF

File 5: .env.local

cat > .env.local << 'EOF'
# Application
NEXT_PUBLIC_APP_NAME=My Next.js App
NEXT_PUBLIC_API_URL=http://localhost:80

# Environment
NODE_ENV=development
EOF

File 6: app/layout.tsx

cat > app/layout.tsx << 'EOF'
import type { Metadata } from 'next'
import './globals.css'

export const metadata: Metadata = {
  title: 'Next.js App',
  description: 'Complete Next.js application with CI/CD',
}

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}
EOF

File 7: app/page.tsx

cat > app/page.tsx << 'EOF'
import Link from 'next/link'

export default function Home() {
  return (
    <main className="min-h-screen flex flex-col items-center justify-center p-24 bg-gradient-to-br from-blue-50 to-indigo-100">
      <div className="max-w-4xl w-full space-y-8 text-center">
        <div className="space-y-4">
          <h1 className="text-6xl font-bold text-gray-900">
            Welcome to <span className="text-blue-600">Next.js</span>
          </h1>
          <p className="text-xl text-gray-600">
            A complete Next.js application with CI/CD pipeline
          </p>
        </div>

        <div className="grid grid-cols-1 md:grid-cols-3 gap-6 mt-12">
          <div className="p-6 border border-gray-200 rounded-lg bg-white shadow-sm hover:shadow-md transition-shadow">
            <h3 className="text-xl font-semibold mb-2">📦 Features</h3>
            <p className="text-gray-600">
              TypeScript, Tailwind CSS, API Routes
            </p>
          </div>

          <div className="p-6 border border-gray-200 rounded-lg bg-white shadow-sm hover:shadow-md transition-shadow">
            <h3 className="text-xl font-semibold mb-2">🚀 Deploy</h3>
            <p className="text-gray-600">
              Automated deployment to Vercel
            </p>
          </div>

          <div className="p-6 border border-gray-200 rounded-lg bg-white shadow-sm hover:shadow-md transition-shadow">
            <h3 className="text-xl font-semibold mb-2">🔧 CI/CD</h3>
            <p className="text-gray-600">
              GitHub Actions workflow included
            </p>
          </div>
        </div>

        <div className="mt-12 space-x-4">
          <Link
            href="/about"
            className="inline-block px-6 py-3 bg-blue-600 text-white rounded-lg hover:bg-blue-700 transition-colors"
          >
            About Page
          </Link>
          <Link
            href="/api/hello"
            className="inline-block px-6 py-3 bg-gray-800 text-white rounded-lg hover:bg-gray-900 transition-colors"
          >
            Test API
          </Link>
        </div>

        <div className="mt-8 text-sm text-gray-500">
          <p>Running on port 80 • Managed by PM2</p>
        </div>
      </div>
    </main>
  )
}
EOF

File 8: app/about/page.tsx

mkdir -p app/about
cat > app/about/page.tsx << 'EOF'
import Link from 'next/link'

export default function About() {
  return (
    <main className="min-h-screen flex flex-col items-center justify-center p-24 bg-gradient-to-br from-purple-50 to-pink-100">
      <div className="max-w-2xl w-full space-y-8">
        <h1 className="text-5xl font-bold text-gray-900 text-center">
          About This App
        </h1>

        <div className="bg-white p-8 rounded-lg shadow-md space-y-4">
          <h2 className="text-2xl font-semibold text-gray-800">Features</h2>
          <ul className="list-disc list-inside space-y-2 text-gray-600">
            <li>Next.js 14 with App Router</li>
            <li>TypeScript for type safety</li>
            <li>Tailwind CSS for styling</li>
            <li>API Routes for backend logic</li>
            <li>PM2 for process management</li>
            <li>GitHub Actions for CI/CD</li>
            <li>Vercel deployment ready</li>
          </ul>
        </div>

        <div className="text-center">
          <Link
            href="/"
            className="inline-block px-6 py-3 bg-purple-600 text-white rounded-lg hover:bg-purple-700 transition-colors"
          >
            ← Back to Home
          </Link>
        </div>
      </div>
    </main>
  )
}
EOF

File 9: app/api/hello/route.ts

cat > app/api/hello/route.ts << 'EOF'
import { NextResponse } from 'next/server'

export async function GET() {
  return NextResponse.json({
    message: 'Hello from Next.js API!',
    timestamp: new Date().toISOString(),
    status: 'success',
    environment: process.env.NODE_ENV,
  })
}

export async function POST(request: Request) {
  const body = await request.json()

  return NextResponse.json({
    message: 'Data received successfully',
    receivedData: body,
    timestamp: new Date().toISOString(),
  })
}
EOF

File 10: app/globals.css

cat > app/globals.css << 'EOF'
@tailwind base;
@tailwind components;
@tailwind utilities;

:root {
  --foreground-rgb: 0, 0, 0;
  --background-start-rgb: 214, 219, 220;
  --background-end-rgb: 255, 255, 255;
}

body {
  color: rgb(var(--foreground-rgb));
  background: linear-gradient(
      to bottom,
      transparent,
      rgb(var(--background-end-rgb))
    )
    rgb(var(--background-start-rgb));
}
EOF

File 11: tailwind.config.ts

cat > tailwind.config.ts << 'EOF'
import type { Config } from 'tailwindcss'

const config: Config = {
  content: [
    './pages/**/*.{js,ts,jsx,tsx,mdx}',
    './components/**/*.{js,ts,jsx,tsx,mdx}',
    './app/**/*.{js,ts,jsx,tsx,mdx}',
  ],
  theme: {
    extend: {
      backgroundImage: {
        'gradient-radial': 'radial-gradient(var(--tw-gradient-stops))',
        'gradient-conic':
          'conic-gradient(from 180deg at 50% 50%, var(--tw-gradient-stops))',
      },
    },
  },
  plugins: [],
}
export default config
EOF

File 12: postcss.config.js

cat > postcss.config.js << 'EOF'
module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
}
EOF

File 13: jest.config.js

cat > jest.config.js << 'EOF'
const nextJest = require('next/jest')

const createJestConfig = nextJest({
  dir: './',
})

const customJestConfig = {
  setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
  testEnvironment: 'jest-environment-jsdom',
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/$1',
  },
  testMatch: [
    '**/__tests__/**/*.[jt]s?(x)',
    '**/?(*.)+(spec|test).[jt]s?(x)',
  ],
}

module.exports = createJestConfig(customJestConfig)
EOF

File 14: jest.setup.js

cat > jest.setup.js << 'EOF'
import '@testing-library/jest-dom'
EOF

File 15: tests/page.test.tsx

mkdir -p __tests__
cat > __tests__/page.test.tsx << 'EOF'
import { render, screen } from '@testing-library/react'
import Home from '@/app/page'

describe('Home Page', () => {
  it('renders the main heading', () => {
    render(<Home />)
    const heading = screen.getByRole('heading', { level: 1 })
    expect(heading).toBeInTheDocument()
  })

  it('contains welcome text', () => {
    render(<Home />)
    expect(screen.getByText(/Welcome to/i)).toBeInTheDocument()
  })
})
EOF

File 16: ecosystem.config.js (PM2 Configuration)

cat > ecosystem.config.js << 'EOF'
module.exports = {
  apps: [
    {
      name: 'nextjs-app',
      script: 'npm',
      args: 'start',
      cwd: './',
      instances: 1,
      autorestart: true,
      watch: false,
      max_memory_restart: '1G',
      env: {
        NODE_ENV: 'production',
        PORT: 80,
      },
      error_file: './logs/err.log',
      out_file: './logs/out.log',
      log_file: './logs/combined.log',
      time: true,
    },
  ],
}
EOF

# Create logs directory
mkdir -p logs

File 17: README.md

cat > README.md << 'EOF'
# Next.js Application

Complete Next.js application with CI/CD pipeline.

## Features

- ✅ Next.js 14 with App Router
- ✅ TypeScript
- ✅ Tailwind CSS
- ✅ API Routes
- ✅ Jest Testing
- ✅ PM2 Process Management
- ✅ GitHub Actions CI/CD
- ✅ Vercel Deployment

## Development

npm install
npm run dev


## Production

npm run build
npm start


## Testing

npm test


## Deployment

Automatically deploys to Vercel on push to main branch.
EOF

STEP 3: Install Dependencies

# Install all dependencies
npm install

# This will take a few minutes

STEP 4: Build the Application

# Build for production
npm run build

# Expected output:
# ✓ Compiled successfully
# ✓ Linting and checking validity of types
# ✓ Collecting page data
# ✓ Generating static pages

STEP 5: Run on Port 80 (Requires sudo)

Using PM2

# Build first
npm run build

# Give Node.js permission to bind to port 80
sudo setcap 'cap_net_bind_service=+ep' $(which node)

# Start with PM2
pm2 start ecosystem.config.js

# Check status
pm2 status

# View logs
pm2 logs nextjs-app

# Save PM2 process list
pm2 save

# Setup PM2 to start on system boot
pm2 startup
# Follow the command it outputs

STEP 6: Test the Application

# Test locally
curl http://localhost:80

# Or open in browser
# http://localhost:80

STEP 7: Push to GitHub

# Initialize git
git init

# Add all files
git add .

# Commit
git commit -m "Initial commit: Complete Next.js app with CI/CD"

# Add remote (replace with your repo)
git remote add origin git@github.com:YOUR_USERNAME/nextjs-app.git

# Push
git push -u origin main

STEP 8: Create GitHub Actions Workflow

# Create workflow file
cat > .github/workflows/deploy.yml << 'EOF'
name: CI/CD Pipeline

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

env:
  NODE_VERSION: '20.x'

jobs:
  test:
    name: Test
    runs-on: ubuntu-latest

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

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run tests
        run: npm test

  build:
    name: Build
    runs-on: ubuntu-latest
    needs: test

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

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build application
        run: npm run build

      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: nextjs-build
          path: .next
          retention-days: 7

  deploy:
    name: Deploy to Vercel
    runs-on: ubuntu-latest
    needs: [test, build]
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'

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

      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'
EOF

# Commit and push
git add .github/workflows/deploy.yml
git commit -m "Add GitHub Actions CI/CD workflow"
git push origin main

STEP 9: Setup Vercel

9.1: Install Vercel CLI

npm install -g vercel

9.2: Login to Vercel

vercel login

1. Select "Continue with GitHub"
2. Vercel will open a browser window
3. Browser URL: https://vercel.com/auth/github
4. Click "Authorize Vercel"
5. You'll see: "Successfully logged in!"
6. Return to terminal
7. Terminal shows: ✅ Success! GitHub authentication complete

9.3: Link Project to Vercel

vercel link

## Follow These Prompts Exactly:


### Prompt 1:

? Set up "~/nextjs-app"? (Y/n)


**Answer:** Type `y` or just press **Enter** (default is Yes)

### Prompt 2

? Which scope should contain your project?
  ❯ yourname (Personal Account)
    your-team (Team Account)


**Answer:** Use arrow keys to select your account, then press **Enter**


### Prompt 3

? Link to existing project? (y/N)


**Answer:** Type `n` or just press **Enter** (we're creating new project)



### Prompt 4

? What's your project's name? (nextjs-app)


**Answer:** Press **Enter** (keep default name) or type a custom name



### Prompt 5

? In which directory is your code located? (./)


**Answer:** Press **Enter** (keep default `./`)



## Expected Success Output

✅ Linked to yourname/nextjs-app (created .vercel and added it to .gitignore)

9.4: Get Vercel Credentials

# Get Vercel Token
# Go to: https://vercel.com/account/tokens
# Click "Create Token"
# Name: GitHub Actions
# Scope: Full Account
# Copy the token

# Get Project ID and Org ID
cat .vercel/project.json

Output will look like:

{
  "projectId": "prj_abc123xyz",
  "orgId": "team_xyz789abc"
}

STEP 10: Add GitHub Secrets

Go to: https://github.com/YOUR_USERNAME/nextjs-app
Click: Settings → Secrets and variables → Actions
Click: "New repository secret"
Add three secrets:

| Secret Name        | Value Description            | Where to Get It                              |
|--------------------|-----------------------------|----------------------------------------------|
| VERCEL_TOKEN       | Your Vercel personal token  | https://vercel.com/account/tokens            |
| VERCEL_ORG_ID      | Vercel Organization ID      | From `.vercel/project.json` → `cat .vercel/project.json` |
| VERCEL_PROJECT_ID  | Vercel Project ID           | From `.vercel/project.json` → `cat .vercel/project.json` |

STEP 11: Test Full Pipeline

# Make a change
echo "# Test deployment" >> README.md

# Commit and push
git add README.md
git commit -m "Test CI/CD pipeline"
git push origin main

# Watch workflow
# Go to: GitHub → Actions tab
# Watch the pipeline run:
#   ✅ Test
#   ✅ Build  
#   ✅ Deploy to Vercel

🎨 How to Make Changes and See Automatic Deployment

Understanding the Workflow

Local Machine (Ubuntu)
    ↓ (make changes)
    ↓ (git commit)
    ↓ (git push)
    ↓
GitHub Repository
    ↓ (triggers)
    ↓
GitHub Actions (if configured)
    ↓ (or directly)
    ↓
Vercel Deployment
    ↓ (automatic)
    ↓
Live Website Updated ✅

🚀 Quick Test: Make Your First Change

Change Homepage Text (Easiest)

# Navigate to project
cd ~/nextjs-app

# Edit the home page
nano app/page.tsx

📤 Push Changes to GitHub

# Check what changed
git status

# Stage the changes
git add app/page.tsx

# Commit with a message
git commit -m "Update homepage: Changed title and description"

# Push to GitHub
git push origin main

🔍 Watch the Automatic Deployment

Method 1: Watch on Vercel Dashboard

1. Open browser
2. Go to: https://vercel.com/dashboard
3. Click on your project: sowmiya-next-js-app
4. You'll see: "Building..." 
5. Wait 30-60 seconds
6. Status changes to: "Ready" ✅
7. Click "Visit" to see your changes live!

🌐 View Your Changes

🚀 Build, Push, and Deploy a Python App image to Cloud Run Using Google Cloud Build Triggers

Latchu@DevOps — Fri, 09 Jan 2026 12:07:35 +0000

In this guide, we will build a Python Flask application, containerize it using Docker, push the image to Google Artifact Registry, and deploy it automatically to Cloud Run using Google Cloud Build Triggers.

1️⃣ Create a Private Repository in GitHub

Create a private GitHub repository and add the following files.

📄 app.py

from flask import Flask
import os

app = Flask(__name__)

@app.route("/")
def wish():
    message = "Happy birthday {name}"
    return message.format(name=os.getenv("NAME", "Latchu"))

if __name__ == "__main__":
    app.run(host='0.0.0.0', port=8080)

📄 Dockerfile

FROM python:3.8.0-slim
WORKDIR /app
ADD . /app
RUN pip install --trusted-host pypi.python.org Flask
ENV NAME Mark
CMD ["python", "app.py"]

2️⃣ Create an Artifact Registry Repository

Navigate to:

Artifact Registry → Repositories → Create Repository

Configure the repository as follows:

Name: pyapprepo-artifact
Format: Docker
Mode: Standard
Location type: Region
Region: asia-south2 (Delhi)
Cleanup policies: Dry run
Vulnerability scanning: Enabled

Click Create to create the repository.

3️⃣ Connect GitHub Repository to Cloud Build

Navigate to:

Cloud Build → Triggers → Connect repository

Steps:

Select Source Code Management Provider
Choose Region: asia-south2 (Delhi)
Select GitHub (Cloud Build GitHub App) → Continue
Authenticate with GitHub
Select your account and repository
Click Connect → Done

Your repository should now be connected successfully.

4️⃣ Create cloudbuild.yaml

Add the following cloudbuild.yaml file to your repository.

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build','-t','asia-south2-docker.pkg.dev/latchu/pyapprepo-artifact/pyappimage:latest','.']

- name: 'gcr.io/cloud-builders/docker'
  args: ['push','asia-south2-docker.pkg.dev/latchu/pyapprepo-artifact/pyappimage:latest']

- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: gcloud
  args:
  - 'run'
  - 'deploy'
  - 'pyflaskapp'
  - '--image'
  - 'asia-south2-docker.pkg.dev/latchu/pyapprepo-artifact/pyappimage:latest'
  - '--region'
  - 'asia-south2'
  - '--allow-unauthenticated'

options:
  defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET

5️⃣ Create a Cloud Build Trigger

Navigate to:

Cloud Build → Triggers → Create Trigger

Configure the trigger:

Name: mypyapptrigger
Region: asia-south2 (Delhi)
Event: Push to a branch
Source: Repository service → Cloud Build repositories
Repository generation: 1st gen
Repository: Select your repo
Branch: .* (any branch)
Configuration: Autodetected (cloudbuild.yaml will be detected)
Location: Repository
Service account: Choose your service account
Leave other options as default
Click Create

6️⃣ Commit Code and Trigger the Pipeline

Make a small change in the code
Commit and push to GitHub
Cloud Build trigger will start automatically

7️⃣ Verify Deployment

Click on the running build in Cloud Build
View detailed logs for build, push, and deployment
Click the Cloud Run service URL
You should see the deployed Flask application running 🎉

✅ Summary

This setup enables a complete CI/CD pipeline using:

GitHub (source code)
Cloud Build Triggers (automation)
Artifact Registry (Docker images)
Cloud Run (serverless deployment)

Every push to the repository automatically builds, pushes, and deploys your application.

Docker Kanvas Challenges Helm and Kustomize for Kubernetes Dominance

Latchu@DevOps — Fri, 09 Jan 2026 06:25:56 +0000

🚀 What Is Docker Kanvas and Why Does It Matter for Kubernetes?

Docker recently introduced Docker Kanvas, a new platform aimed at simplifying one of the hardest problems in cloud-native development:

Moving from local development to production Kubernetes — without drowning in YAML.

This move signals a strategic shift for Docker: from being just a container runtime to becoming a deployment and platform orchestration layer.

Let’s break it down.

🧩 The Problem Docker Kanvas Is Solving

Most developers are comfortable with:

docker compose up

But production looks very different.

To deploy the same app on Kubernetes, teams usually need to:
Rewrite the application using Kubernetes manifests
Learn Helm or Kustomize
Create Terraform or Pulumi scripts
Manage clusters, networking, storage, and scaling
Maintain two sources of truth:

Docker Compose (local)
Kubernetes YAML (production)

This transition is:

Slow
Error-prone
DevOps-heavy
A major cognitive burden for developers

🧠 What Is Docker Kanvas?

Docker Kanvas is a Docker Desktop extension that allows developers to:

Use Docker Compose as the source of truth
Automatically generate:

Kubernetes deployment artifacts
Infrastructure-as-Code (Terraform / Pulumi)

Deploy applications to:

Managed Kubernetes (GKE, EKS, AKS)
Serverless platforms

Visualize application architecture and service dependencies

All without manually writing Kubernetes YAML.

🔁 How Docker Kanvas Works (Conceptually)

Traditional flow

Docker Compose
     ↓
Manual Kubernetes YAML
     ↓
Helm / Kustomize
     ↓
Terraform
     ↓
Kubernetes

With Docker Kanvas

Docker Compose
     ↓
Docker Kanvas
     ↓
Cloud-ready Kubernetes deployment

Compose remains the single source of truth.

🧪 Simple Example

Docker Compose (what developers already write)

services:
  web:
    image: nginx
    ports:
      - "8080:80"

With Kanvas:

This Compose file is interpreted
Kubernetes Deployments, Services, and networking are generated
Infrastructure is provisioned automatically
The app is deployed to the cloud

Developers never touch Kubernetes YAML directly.

🧭 Why Docker Kanvas Challenges Helm and Kustomize

Helm and Kustomize are powerful tools — but they assume:

You already understand Kubernetes
You’re comfortable managing YAML
You accept Kubernetes as the primary interface

Docker Kanvas challenges that assumption.

Key differences

| Aspect            | Helm / Kustomize        | Docker Kanvas          |
| ----------------- | ----------------------- | ---------------------- |
| Entry point       | Kubernetes YAML         | Docker Compose         |
| Target user       | DevOps / Platform teams | Application developers |
| Learning curve    | High                    | Low                    |
| Source of truth   | YAML manifests          | Compose file           |
| Visualization     | No                      | Yes                    |
| Abstraction level | Low                     | High                   |

Kanvas doesn’t replace Helm in complex enterprises — it bypasses Helm for many teams entirely.

🧠 Why Docker Kanvas Is Needed

1️⃣ Developers don’t want to learn Kubernetes internals

Most developers want to:

Build features
Ship faster
Avoid infrastructure complexity

Kanvas lets them stay productive without becoming Kubernetes experts.

2️⃣ Platform engineering is rising

Modern teams are building:

Internal developer platforms
Golden paths
Opinionated workflows

Docker Kanvas fits naturally into this model by:

Standardizing deployments
Reducing decision fatigue
Enforcing consistency

3️⃣ Visual architecture matters

Kanvas generates:

Service dependency graphs
Application topology views

This helps with:

Debugging
Security reviews
Onboarding
Architecture discussions

⚠️ What Docker Kanvas Is NOT

❌ Not a replacement for Kubernetes

❌ Not a replacement for Helm in advanced setups

❌ Not designed for headless servers (Desktop-only today)

It’s a developer-experience tool, not a low-level infrastructure engine.

🔮 What This Means for the Kubernetes Ecosystem

Docker Kanvas represents a shift toward:

Higher-level abstractions
Fewer infrastructure tools per team
Kubernetes becoming an invisible runtime

Kubernetes still runs everything — developers just don’t have to think about it.

🏁 Final Thoughts

Docker Kanvas is not trying to win Kubernetes feature wars.

It’s trying to win developer mindshare.

By making Docker Compose a valid path to production, Docker is redefining how applications move from laptops to the cloud — and that’s why tools like Helm and Kustomize are being challenged, not replaced.

🧱Understanding Artifacts and Artifact Repositories in Google Cloud CI/CD

Latchu@DevOps — Fri, 12 Dec 2025 07:50:29 +0000

In every modern CI/CD pipeline, there is one element that quietly powers the entire automation process — artifacts.
They play a crucial role in how software moves from code → build → deployment.
If you’re new to DevOps or Google Cloud, this guide will help you clearly understand:

✔ What artifacts are
✔ Why they matter in CI/CD
✔ How they are stored and managed
✔ Artifact Repository vs Container Registry
✔ Why Google recommends Artifact Registry

Let’s break it down in simple terms.

🔍 What Are Artifacts?

When your CI pipeline builds code, it produces output files.
These files — called artifacts — are the deliverables used later during deployment.

🧩 Artifacts include:

Jar files
Packages
Binaries
Docker images
Configuration files
Documents or reports
Any compiled or generated output

Think of artifacts as the results of your build stage (CI), which are then consumed by the deployment stage (CD).

⚙️ Types of Artifacts

Artifacts generally fall into two categories:

1️⃣ Container Artifacts

These are container images — typically Docker images — used to deploy applications in Kubernetes, Cloud Run, Cloud Functions, etc.

2️⃣ Non-Container Artifacts

These include:

Java .jar files
Node/npm packages
Python wheels
Terraform modules
Helm charts
Config files

Both types need reliable storage and versioning.

📦 Why Do We Need Artifact Management?

Once the CI pipeline generates artifacts, they must be:

✔ Stored in a central place
✔ Versioned properly
✔ Made accessible to CD pipelines
✔ Secure and scanned for vulnerabilities
✔ Managed consistently

An Artifact Management System solves these challenges by acting as the single source of truth for all build outputs.

🏛 Artifact Repositories Explained

An Artifact Repository is a centralized storage system specifically designed for storing and managing artifacts in CI/CD workflows.

Key benefits:

Acts as the single source of truth
Supports version management
Scans artifacts for vulnerabilities
Helps apply approval workflows
Ensures consistency across build and deploy stages
Enhances DevOps efficiency and organizational performance

Artifact repositories are essential for both monolithic and microservices architectures.

🗂 Options for Storing Artifacts in Google Cloud

Google Cloud offers two main services for storing artifacts:

🏗️ 1. Artifact Registry (Recommended)

Artifact Registry is the next generation of Google’s artifact storage solution.
It replaces Container Registry and supports more artifact types.

⭐ Key Features:

Stores container and non-container artifacts
Native support for multiple formats (Docker, npm, Maven, Python, etc.)
Fully integrated with Google Cloud Build, GKE, Cloud Run
Allows creation of regional or multi-regional repositories
Offers vulnerability scanning
Provides fine-grained IAM control
Charges based on usage (storage + network egress)

Artifact Registry is now the default and recommended option.

🚢 2. Container Registry (Legacy)

Container Registry was Google's original solution for storing Docker images.

📌 Features:

Stores Docker images in private repositories
Supports Docker Image Manifest V2 & OCI formats
Vulnerability scanning for early detection
Compatible with standard Docker CLI (docker push, docker pull)
Charges for underlying Cloud Storage usage
Still works — but Google Cloud is migrating users to Artifact Registry

If you're starting new, always choose Artifact Registry.

🎯 Final Thoughts

Artifacts form the backbone of any CI/CD pipeline.
They ensure that:

Code is transformed into deployable assets
Build outputs remain consistent and traceable
Deployment workflows are reliable and secure

Google Cloud’s Artifact Registry provides a modern, unified, secure, and scalable way to manage container and non-container artifacts — making it the ideal choice for DevOps teams.

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions

🚀How to Create Your First GitHub Trigger & Connections in Google Cloud Build

Latchu@DevOps — Fri, 12 Dec 2025 07:10:32 +0000

Google Cloud Build makes it incredibly simple to automate your CI/CD pipeline. One of the most common setups is connecting GitHub → Cloud Build so that every commit automatically triggers a build.
If you're new to Cloud Build, follow this step-by-step guide to create your first trigger successfully.

🔗 Step 1: Connect GitHub Repository to Cloud Build

Open Google Cloud Console → Search for Cloud Build.
Go to the Triggers section.
Click “Connect Repository”.
Select your source provider: → GitHub (Cloud Build GitHub App)

Click Continue to Authenticate.

You’ll be redirected to GitHub to install the Cloud Build GitHub App.
After installation, return to Cloud Build.
Select the GitHub account and repository you want to connect.
Click Connect → Done.

Your GitHub repo is now officially linked with Google Cloud Build.

⚙️ Step 2: Create Your First Cloud Build Trigger

In Cloud Build → Go to Triggers → Create Trigger.
Fill in the fields:

Basic Settings

Name: first-trigger
Region: global
Tags: dev_team

Event Type

Event: Push to a branch

Source Configuration

Source: Cloud Build Repositories
Repository type: 1st generation
Repository: Select your GitHub repo
Branch: ^main$ (This ensures the trigger runs only for main branch pushes)

Build Configuration

Configuration: Autodetected
Location: Repository (Cloud Build will search for your cloudbuild.yaml inside the repo)

Service Account

Select your Cloud Build service account
Click Create Trigger

Your first CI pipeline is now ready!

📝 Step 3: Commit Changes in GitHub

Open your GitHub repository.
Make a small change (add a print statement, update a README, etc.).
Commit and push the changes.

This action will automatically trigger Cloud Build.

📊 Step 4: View Build History & Logs

Go to Cloud Build → History.
You’ll see your recent builds.
Click any build to open the Build Summary:

You can view:

Build logs
Execution details
Artifact outputs
Build duration & steps

📈 Step 5: Monitor Overall Build Activity

Open the Cloud Build Dashboard to get a high-level view of:

Recent build status
Success/failure rate
Build durations
Trigger usage

This helps track the health of your CI pipeline easily.

🎉 Final Thoughts

You’ve now successfully set up:

✔ GitHub connected to Cloud Build
✔ A working build trigger
✔ Automated builds on every commit
✔ Build logs and dashboard monitoring

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions

🚀Getting Started With Google Cloud Build

Latchu@DevOps — Fri, 12 Dec 2025 05:01:30 +0000

Modern applications need fast, reliable, and automated ways to build, test, and deploy code. Google Cloud Build is one such powerful service that helps developers automate their entire CI/CD process — without managing any servers.

In this article, let’s understand what Cloud Build is, why it’s useful, and how build configuration files work, in the simplest possible way.

🌥️ What is Google Cloud Build?

Cloud Build is a serverless CI/CD platform from Google Cloud that automates the process of building, testing, and deploying your applications.

🔥 Key advantages:

⭐ 1. Serverless

No need to provision or manage build servers.
Cloud Build handles compute resources automatically.

⭐ 2. Auto-Scaling

Whether you run 1 build or 100 builds, Cloud Build scales up and down as needed.
You only pay for the build time you use.

⭐ 3. Single Configuration File

You define all your build steps (build, test, package, push images, deploy, etc.) inside one YAML or JSON file.

This file tells Cloud Build exactly what to do.

⭐ 4. Built-in Vulnerability Scanning

Cloud Build can scan container images for security vulnerabilities as part of the CI/CD workflow.
Security is automated!

⭐ 5. Supports Multiple Source Code Providers

Cloud Build can fetch your code from:

Google Cloud Storage
Cloud Source Repositories
GitHub
Bitbucket
And more

You can trigger builds automatically when you push code.

⭐ 6. Deploy Anywhere

Cloud Build can deploy your application to multiple environments:

VM instances
Cloud Run (serverless)
Google Kubernetes Engine (GKE)
Firebase
Or even other clouds

⭐ 7. Cloud Builders

Cloud Build uses "builders" — pre-built images with common tools (like Docker, Maven, Node, Go, Python, etc.)
They allow you to run commands like docker build, npm install, mvn package, etc.

🧩 Build Configuration (cloudbuild.yaml)

The core of Cloud Build is the build configuration file.

You provide this file along with your source code, and Cloud Build uses it to understand what steps to execute.

📌 What is it?

A YAML/JSON file that defines:

The steps of your build
Which tools or builder images to use
What commands to run
What to deploy
Where to store logs and artifacts

📌 What does it contain?

✔️ Instructions for Cloud Build
✔️ Step-by-step tasks
✔️ Runtime environment
✔️ Docker image definitions
✔️ Artifact locations
✔️ Deploy settings

The file is usually named cloudbuild.yaml.

🧱 Example: A Very Simple Cloud Build File

Here’s a basic cloudbuild.yaml that builds a Docker image and pushes it to Google Container Registry:

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/myapp', '.']

  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/myapp']

images:
  - 'gcr.io/$PROJECT_ID/myapp'

🔍 What this file does:

Uses Docker builder to build an image
Tags the image
Pushes it to Google Container Registry
Marks the image as a final output

Simple, clean, and fully automated.

🎯 Why Developers Love Cloud Build

✔️ No servers to manage
✔️ Fast and scalable
✔️ Works for both monoliths and microservices
✔️ Supports Docker, Kubernetes, Cloud Run, and more
✔️ Easy integrations with GitHub/GitLab
✔️ Secure by design

You can go from code → container → deployment in minutes!

🏁 Final Thoughts

If you want a low-maintenance, scalable, and secure CI/CD solution, Google Cloud Build is one of the best options available today.

It works for beginners because it is simple and works for experts because it is powerful.

All you need is a cloudbuild.yaml file — and Cloud Build takes care of the rest.

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions

🟩How to Route DB Connections to Multiple Database Servers Using HAProxy Port Forwarding

Latchu@DevOps — Sat, 06 Dec 2025 09:16:57 +0000

Managing multiple MySQL databases across several servers can be challenging—especially when you want users to connect seamlessly without needing to know which server hosts which database.

In this guide, I’ll walk you through a clean, production-friendly setup where:

You have 3 MySQL servers (each hosting one database)
You have 1 client server
You install HAProxy on the client server
Users connect to different ports, and HAProxy forwards them to the correct MySQL server

This approach is simple, scalable, and ideal for separating workloads or multi-tenant MySQL environments.

🟦 What is HAProxy?

HAProxy (High Availability Proxy) is a fast, open-source TCP and HTTP load balancer widely used in production environments.

Key features:

Load Balancing
Reverse Proxying
Health Checks
High Availability
SSL Termination
TCP/UDP routing

For MySQL, HAProxy acts as a TCP proxy, routing database connections based on rules you define.

🟦 What is HAProxy Port Forwarding?

HAProxy port forwarding means:

You expose different ports on the HAProxy server
Each port forwards traffic to a specific backend server

In our case:

Port	Goes To	Database
3301	MySQL Server 1	db1
3302	MySQL Server 2	db2
3303	MySQL Server 3	db3

So, when a user connects to:

mysql -h haproxy-server -P 3302 -u dbuser -p

They are transparently forwarded to MySQL Server 2.

This method keeps things simple and avoids complex routing logic.

🟩 Architecture Diagram

                +---------------------+
                |     Client User     |
                +----------+----------+
                           |
                           | MySQL request on port 3301/3302/3303
                           |
                     +-----+------+
                     |  HAProxy   |
                     |  (10.0.0.14)|
                     +-----+------+
         3301 -----------| |------------- 3302
                         | |
        +----------------+ +----------------+
        |                                   |
+-------+--------+                 +--------+-------+
| MySQL Server 1 |                 | MySQL Server 2 |
|  (10.0.0.11)   |                 |  (10.0.0.12)   |
|     db1        |                 |     db2        |
+----------------+                 +----------------+

                    +-----------------------+
                    |   MySQL Server 3      |
                    |     (10.0.0.13)       |
                    |         db3           |
                    +-----------------------+

🟩 Server Setup Overview

| Server Role            | Example IP  |
| ---------------------- | ----------- |
| MySQL Server 1 (db1)   | `10.0.0.11` |
| MySQL Server 2 (db2)   | `10.0.0.12` |
| MySQL Server 3 (db3)   | `10.0.0.13` |
| HAProxy + MySQL client | `10.0.0.14` |

Replace IPs with your own.

🟦 Step 1 — Install MySQL on Each Server

Run on all three MySQL servers:

sudo apt update
sudo apt install mysql-server -y
sudo systemctl enable mysql
sudo systemctl start mysql

🟦 Step 2 — Secure MySQL Installation

sudo mysql_secure_installation

🟦 Step 3 — Create Databases and MySQL User

✔ Server 1 (10.0.0.11)

sudo mysql

CREATE DATABASE db1;
CREATE USER 'dbuser'@'%' IDENTIFIED BY 'StrongPass@123';
GRANT ALL PRIVILEGES ON db1.* TO 'dbuser'@'%';
FLUSH PRIVILEGES;

✔ Server 2 (10.0.0.12)

CREATE DATABASE db2;
CREATE USER 'dbuser'@'%' IDENTIFIED BY 'StrongPass@123';
GRANT ALL PRIVILEGES ON db2.* TO 'dbuser'@'%';

✔ Server 3 (10.0.0.13)

CREATE DATABASE db3;
CREATE USER 'dbuser'@'%' IDENTIFIED BY 'StrongPass@123';
GRANT ALL PRIVILEGES ON db3.* TO 'dbuser'@'%';

🟦 Step 4 — Allow Remote Connections

Edit MySQL config on each database server:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Change:

bind-address = 127.0.0.1

To:

bind-address = 0.0.0.0

Restart:

sudo systemctl restart mysql

🟦 Step 5 — Install HAProxy on the Client Server

Run on 10.0.0.14:

sudo apt update
sudo apt install haproxy -y

🟦 Step 6 — Configure HAProxy for MySQL Port Forwarding

Edit config:

global
    log /dev/log local0
    maxconn 4096
    daemon

defaults
    mode tcp
    option tcplog
    timeout connect 5s
    timeout client  1m
    timeout server  1m

# -----------------
# FRONTENDS
# -----------------

frontend mysql_db1
    bind *:3301
    default_backend backend_db1

frontend mysql_db2
    bind *:3302
    default_backend backend_db2

frontend mysql_db3
    bind *:3303
    default_backend backend_db3

# -----------------
# BACKENDS
# -----------------

backend backend_db1
    server db1 10.0.0.11:3306 check

backend backend_db2
    server db2 10.0.0.12:3306 check

backend backend_db3
    server db3 10.0.0.13:3306 check

Restart HAProxy:

sudo systemctl restart haproxy
sudo systemctl enable haproxy

🟦 Step 7 — Test HAProxy Routing

✔ Test DB1

mysql -u dbuser -p -h 127.0.0.1 -P 3301 db1

✔ Test DB2

mysql -u dbuser -p -h 127.0.0.1 -P 3302 db2

✔ Test DB3

mysql -u dbuser -p -h 127.0.0.1 -P 3303 db3

If it connects successfully, HAProxy routing works!

🟩 How Users Will Connect

Tell users:

| Database | Port     |
| -------- | -------- |
| db1      | **3301** |
| db2      | **3302** |
| db3      | **3303** |

Example:

mysql -h <haproxy-ip> -P 3302 -u dbuser -p db2

🟩 Why This Architecture Works Well

✔ Simple — no need for DNS tricks or MySQL router
✔ Easy to scale — add more ports/backends anytime
✔ Secure — MySQL servers are never exposed directly
✔ Transparent to users — they just pick a port
✔ Good for multi-tenant setups

🟩 Conclusion

Using HAProxy as a port-based MySQL router is one of the cleanest and most maintainable setups for environments where different databases reside on different servers.

By forwarding unique ports to unique backend servers, you avoid complexity while providing a flexible system that users can easily interact with.

🔐Secure AWS Access Using Client VPN Endpoint — A Step-by-Step Guide (EasyRSA + ACM)

Latchu@DevOps — Sat, 06 Dec 2025 06:20:32 +0000

Managing secure access to your AWS resources—without juggling IP whitelisting or exposing your infrastructure—is easier than you think. In this guide, you’ll learn how to create your own certificates using EasyRSA, upload them to AWS Certificate Manager (ACM), and configure a fully functional AWS Client VPN Endpoint.

By the end, you’ll be able to connect securely to your VPC with a simple VPN client.

⭐ What We’ll Cover

Generating server & client certificates using EasyRSA

Uploading certificates to AWS ACM
Creating and configuring an AWS Client VPN Endpoint
Associating networks & setting authorization rules
Downloading the .ovpn file and connecting securely

Let’s get started!

🛠️ Step 1: Install EasyRSA & Generate Certificates

1. Download EasyRSA

Download the ZIP for your Windows version from:

👉 Download EasyRSA

2. Open EasyRSA Shell

C:\Program Files\EasyRSA-3.x> .\EasyRSA-Start.bat

3. Initialize a New PKI

./easyrsa init-pki

4. Build Your Certificate Authority (CA)

./easyrsa build-ca nopass

5. Generate Server Certificate & Key

./easyrsa --san=DNS:server build-server-full server nopass

6. Generate Client Certificate & Key

./easyrsa build-client-full client1.domain.tld nopass

Repeat as needed for additional users.

7. Exit the EasyRSA Shell

exit

📁 Step 2: Organize Certificates for Upload

Create a custom folder and copy the required files:

mkdir C:\custom_folder
copy pki\ca.crt C:\custom_folder
copy pki\issued\server.crt C:\custom_folder
copy pki\private\server.key C:\custom_folder
copy pki\issued\client1.domain.tld.crt C:\custom_folder
copy pki\private\client1.domain.tld.key C:\custom_folder
cd C:\custom_folder

☁️ Step 3: Upload Certificates to AWS ACM

Go to AWS Certificate Manager (ACM) and upload:

server.crt
ca.crt
server.key

Once uploaded, your certificates will be ready to attach to the Client VPN Endpoint.

🔧 Step 4: Create the AWS Client VPN Endpoint

Navigate to:

AWS Console → VPC → Client VPN Endpoints → Create Client VPN Endpoint

Fill in the details:

| Setting                | Value                             |
| ---------------------- | --------------------------------- |
| Name                   | `my-client`                       |
| Endpoint IP type       | IPv4                              |
| Client IPv4 CIDR       | `20.0.0.0/22`                     |
| Server certificate ARN | select from ACM                   |
| Authentication         | Mutual authentication             |
| Client certificate ARN | select from ACM                   |
| DNS servers            | `10.0.0.2`, `8.8.8.8`             |
| Protocol               | UDP                               |
| VPN Port               | 443                               |
| VPC                    | Select your VPC                   |
| Security Group         | Any SG that allows needed traffic |

Click Create.

🌐 Step 5: Associate a Target Network

Go to your Client VPN endpoint:

Target network associations → Associate network

Select:

Your VPC
The subnet you want users to access

🔑 Step 6: Add Authorization Rules

Go to Authorization rules → Add new rule:

Destination network: 10.0.0.0/26 (your VPC CIDR)
Access: Allow access to all users

Add the rule.

📥 Step 7: Download & Update VPN Config

Download the client configuration (.ovpn) from your Client VPN endpoint.
Add your client certificate and key inside the .ovpn file:

<cert>
  (contents of client1.domain.tld.crt)
</cert>

<key>
  (contents of client1.domain.tld.key)
</key>

💻 Step 8: Install AWS Client VPN

Download here:

👉 Download AWS Client VPN

Install and open the client.

Add a new profile using the updated .ovpn file and connect.

🎉 You're In!

You are now connected to your AWS VPC securely via Client VPN Endpoint.
No more IP whitelisting. No exposing SSH ports. Just clean, encrypted access.

You can now SSH into your servers safely from your local machine.

💬 Final Thoughts

AWS Client VPN Endpoint is a powerful way to centralize, secure, and simplify access to your private networks. By generating your own certificates, you stay fully in control of your security setup.

🚀 Task #4 — GitHub Actions with CI + Docker + GitOps ArgoCD + GKE Cluster (CICD)

Latchu@DevOps — Fri, 28 Nov 2025 06:08:51 +0000

📌 How CI/CD Works

Step-by-Step Flow

1️⃣ Developer pushes code to GitHub

Push changes inside app/main.go
Push new Dockerfile changes
Push manifest updates

2️⃣ GitHub Actions Runs

Builds Docker image
Pushes new image to GHCR
Updates deployment YAML
Commits YAML back to the repo

3️⃣ ArgoCD Observes Git State

ArgoCD continuously watches repo
Repo changed ➝ ArgoCD detects new commit

4️⃣ ArgoCD Performs Deployment

Applies updated YAML to Kubernetes
Deploys the new version
Ensures cluster matches Git (self-heal)

5️⃣ Result

✅ Fully automated CI/CD
🔥 No kubectl required
⚡ Zero manual deployments
🎯 Pull-based GitOps workflow (secure + stable)

📁 Project Structure

argocd-demo-app/
  ├── app/
  │    └── main.go
  ├── k8s/
  │    └── deployment.yaml
  ├── .github/
  │    └── workflows/
  │         └── ci-cd.yaml
  ├── Dockerfile
  ├── README.md

📌 Part 1 — Application Code

app/main.go

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "This is Latchu! Hello from ArgoCD + GitHub Actions + GitOps!")
    })

    fmt.Println("Server running on port 80")
    http.ListenAndServe(":80", nil)
}

📌 Part 2 — Dockerfile

FROM golang:1.22 AS builder
WORKDIR /app
COPY app/ .
RUN go build -o server main.go

FROM debian:stable-slim
COPY --from=builder /app/server /usr/local/bin/server
CMD ["server"]
EXPOSE 80

📌 Part 3 — Kubernetes Deployment

k8s/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  labels:
    app: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: demo-app
        image: latchudevops/argocd-demo-app:780e0f9bf323810e2acbbb60b8414b5e34b16af6
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: demo-app
spec:
  type: LoadBalancer
  selector:
    app: demo-app
  ports:
    - port: 80
      targetPort: 80

📌 Part 4 — GitHub Actions CI/CD Pipeline

.github/workflows/ci-cd.yaml

name: CI-CD Pipeline

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Login to DockerHub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Build & Push Docker Image
        run: |
          IMAGE=latchudevops/argocd-demo-app:${{ github.sha }}
          docker build -t $IMAGE .
          docker push $IMAGE
          echo "IMAGE_NAME=$IMAGE" >> $GITHUB_ENV

      - name: Update Kubernetes Manifest
        run: |
          sed -i "s|image: .*|image: $IMAGE_NAME|g" k8s/deployment.yaml

      - name: Commit Updated Manifest
        run: |
          git config --global user.email "actions@github.com"
          git config --global user.name "GitHub Actions"
          git add k8s/deployment.yaml
          git commit -m "Update image to $IMAGE_NAME" || echo "No changes to commit"
          git push

📌 Part 5 — GitHub Secrets

GitHub repo -> Settings -> Secrets and Variables -> Actions -> Add new repository secret

📌 Part 6 — ArgoCD Setup (GKE)

To install and configure ArgoCD on Google Kubernetes Engine Cluster using below this link

ArgoCD Setup

📌 Part 7 — To start CICD

Push any changes inside app/main.go
GitHub Action Workflow CICD pipeline start the build docker image, push the docker image to the docker hub and update the deployment yaml file inside k8s
ArgoCD continuously watches the k8s mainfest yaml
Manifests changed -> ArgoCD detects new commit
Applies updated YAML to Kubernetes
Deploys the new version into GKE cluster

If you check with GitHub Actions workflow,

If you can check with ArgoCD UI

If you have a look at the GKE Cluster

The new version has been deployed in Kubernetes

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions

🎯 Task #3 — Enable AutoSync + Health Checks + Self-Heal in ArgoCD

Latchu@DevOps — Thu, 27 Nov 2025 12:49:52 +0000

ArgoCD is powerful because it continuously watches Git and your cluster, and keeps them in sync.
This task enables:

✅ Auto-Sync

Automatically apply changes from Git to the cluster.

✅ Self-Heal

If someone manually edits or deletes a Kubernetes object, ArgoCD restores it from Git.

✅ Auto-Prune

Remove Kubernetes resources that were removed from Git.

✅ Rollbacks

If a sync fails, ArgoCD will automatically roll back to a good version.

⭐ Step 1 — Enable AutoSync in ArgoCD UI

Go to:

Applications → Select your app → App Details → Sync Policy

Turn ON:

Auto-Sync
Prune Resources
Self Heal

These correspond to:

Setting	Meaning
Auto-Sync	If Git changes, ArgoCD automatically applies the changes to the cluster.
Prune	If a file (resource) is deleted from Git, ArgoCD deletes that resource from the cluster.
Self-Heal	If someone manually changes something in the cluster (via kubectl), ArgoCD restores it back to match Git.

⭐ Step 2 — Verify AutoSync is Working

(1) Update something in Git

Edit your deployment.yaml image tag:

image: nginx:1.27

Push it:

git add .
git commit -m "Update version"
git push

Expected result:

ArgoCD UI shows "OutOfSync → Syncing → Healthy"
New image deployed automatically

If you check with pods,

⭐ Step 3 — Test Self-Heal (Drift Correction)

Modify something manually in the cluster:

kubectl edit deploy demo-app

Change replicas from 2 to 5 and save.

➡️ ArgoCD will detect drift
➡️ ArgoCD will automatically revert replicas back to the Git value (e.g. 2)

This proves self-heal is working.

⭐ Step 4 — Test Auto-Rollback

Break the deployment:

Edit your deployment.yaml and use a fake image:

image: nginx:does-not-exist

Push it.

Expected:

ArgoCD tries to sync
Sync fails
ArgoCD rollback mechanism applies the last healthy version automatically (using retry + failure detection)

Your app will remain healthy 👌

⭐ Step 5 — Test Auto-Prune

Delete the service from GitHub:

rm service.yaml
git add .
git commit -m "Remove service"
git push

➡️ ArgoCD will detect the file removed
➡️ It will delete the Service in Kubernetes automatically

🎉 Final Result — What You Achieved

With Task #3 completed, your app now has:

| Feature                                     | Status    |
| ------------------------------------------- | --------- |
| Automatic Git → Cluster sync                | ✅ Enabled |
| Automatically revert manual kubectl changes | ✅ Enabled |
| Automatically delete removed resources      | ✅ Enabled |
| Automatic rollback to last good version     | ✅ Enabled |
| Continuous health monitoring                | ✅ Enabled |

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions

✅ Task #2 — Deploy Your First GitOps Application on GKE Cluster Using ArgoCD

Latchu@DevOps — Thu, 27 Nov 2025 11:11:33 +0000

In this task you will:

Create a simple Kubernetes manifest
Push it to a GitHub repo
Connect ArgoCD to that repo
Deploy your app automatically
Test GitOps Sync (manual + auto)

⭐ STEP 1 — Create a GitHub Repo

Create a new GitHub repo:

argocd-demo-app

Add this structure:

argocd-demo-app/
 └── deployment.yaml
 └── service.yaml

⭐ STEP 2 — Add a Simple NGINX App

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  labels:
    app: demo-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: demo-app
spec:
  type: LoadBalancer
  selector:
    app: demo-app
  ports:
    - port: 80
      targetPort: 80

Push to GitHub:

git add .
git commit -m "first argocd app"
git push origin main

⭐ STEP 3 — Create ArgoCD Application

🎨 Create application using UI (Beginner-friendly)

Open ArgoCD UI
Click NEW APP
Fill:

| Field               | Value            |
| ------------------- | ---------------- |
| Application Name    | `demo-app`       |
| Project             | default          |
| Sync Policy         | Manual (for now) |
| Repository URL      | Your GitHub repo |
| Revision            | main             |
| Path                | `.`              |
| Destination Cluster | in-cluster       |
| Namespace           | default          |

Click create

⭐ STEP 4 — Sync Application

In UI:

👉 Select demo-app
👉 Click SYNC → SYNCHRONIZE

ArgoCD will:

Pull manifests from GitHub
Deploy them into your GKE cluster
Show pods, services, health status graphically

Check app in cluster:

kubectl get pods
kubectl get svc demo-app

Wait for service external IP:

kubectl get svc demo-app -w

Open in browser:

http://<EXTERNAL-IP>

You will see default NGINX page.

⭐ STEP 5 — Test GitOps (VERY IMPORTANT)

Now edit repo:

Edit deployment.yaml:

Change image:

image: nginx:1.27 -> nginx:1.26

Push:

git commit -am "downgrade image"
git push

In ArgoCD:

You will see the app becomes OutOfSync

Click SYNC

ArgoCD will deploy the new version

If you check with ArgoCD,

🎉 This is GitOps!

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions

✅ Task #1 — Introduction to ArgoCD + Installation on GKE Cluster

Latchu@DevOps — Thu, 27 Nov 2025 10:19:06 +0000

1. What is ArgoCD? (Easy Explanation)

ArgoCD is a GitOps-based Continuous Delivery (CD) tool for Kubernetes.

🔥 In simple words:

ArgoCD automatically deploys apps to your Kubernetes cluster from GitHub/GitLab, and keeps them in sync.

If your cluster changes → ArgoCD fixes it
If Git changes → ArgoCD deploys the new version
If someone deletes a pod → ArgoCD recreates it

2. Why do we need ArgoCD? (Easy-to-understand)

✅ 1. GitOps Automation

Anything you push to Git will be auto-deployed to Kubernetes.

✅ 2. No manual kubectl apply

ArgoCD replaces kubectl commands with automation.

✅ 3. Application rollback

One click → rollback to any previous Git commit.

✅ 4. Full visibility

A UI dashboard shows:

Pods
Services
Events
Health status
Sync status

✅ 5. Secure

Your cluster never needs to pull code from CI.
ArgoCD runs inside the cluster → it pulls manifests securely.

✅ 6. Multi-cluster support

One ArgoCD can deploy apps to many clusters.

⭐ 3. Install ArgoCD on GKE — Step-by-Step (Task)

Make sure kubectl is connected to your GKE cluster:

gcloud container clusters get-credentials mycluster --region us-central1-a

Step 1 — Create the namespace

kubectl create namespace argocd

Step 2 — Install ArgoCD core components

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Step 3 — Install ArgoCD CLI (optional but useful)

Linux:

sudo curl -sSL -o /usr/local/bin/argocd \
https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64

sudo chmod +x /usr/local/bin/argocd

Step 4 — Expose ArgoCD UI using LoadBalancer

By default, ArgoCD creates a ClusterIP service.
You need a LoadBalancer for browser login.

kubectl patch svc argocd-server -n argocd \
  -p '{"spec": {"type": "LoadBalancer"}}'

Wait for the external IP:

kubectl get svc -n argocd

Look for:

argocd-server   LoadBalancer   EXTERNAL-IP: x.x.x.x

Step 5 — Get the initial admin password

kubectl get secret argocd-initial-admin-secret -n argocd \
  -o jsonpath="{.data.password}" | base64 -d

Step 6 — Login to ArgoCD (CLI)

argocd login <EXTERNAL-IP> --username admin --password <PASSWORD> --insecure

Step 7 — Open ArgoCD UI

Open in browser:

https://<EXTERNAL-IP>

Username: admin
Password: (the decoded password above)

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions