DEV Community: Folashade Oluwaseun Oroge

Automating Kubernetes Image Updates with FluxCD, Amazon ECR, and GitHub

Folashade Oluwaseun Oroge — Wed, 17 Jun 2026 16:59:30 +0000

Learn how to automatically deploy new container images to Kubernetes using FluxCD Image Automation, Amazon ECR, GitHub Apps, and GitOps principles.

Introduction

One of the challenges platform engineers face in Kubernetes environments is keeping application deployments synchronized with newly built container images.

In many organizations, the deployment process looks something like this:

A developer merges code.
A CI/CD pipeline builds a Docker image.
The image is pushed to a container registry.
Someone manually updates the image tag in Kubernetes manifests.
The changes are committed and deployed.

While this works, it introduces unnecessary manual effort and increases the risk of deploying the wrong image version.

FluxCD's Image Automation Toolkit solves this problem by automatically:

Detecting newly published container images
Selecting the correct image based on defined policies
Updating Kubernetes manifests in Git
Committing the changes back to the repository
Allowing Flux to reconcile and deploy the new version

This creates a fully automated GitOps workflow where Git remains the single source of truth.

The Problem We're Solving

Imagine your CI/CD pipeline generates image tags like:

branch-dev-1715555000-a12b34c
branch-dev-1715556000-b45d67e
branch-dev-1715557000-f12a34b

Without automation, someone must:

Identify the latest image
Update deployment manifests
Create a pull request
Merge the change
Wait for deployment

As the number of applications grows, this quickly becomes difficult to manage.

Flux Image Automation removes this operational overhead entirely.

Solution Architecture

The deployment workflow looks like this:

┌──────────────────────┐
│ Developer Pushes Code│
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ CI/CD Pipeline       │
│ Builds Docker Image  │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Amazon ECR           │
│ Stores New Image     │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Flux ImageRepository │
│ Scans Registry       │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Flux ImagePolicy     │
│ Selects Latest Tag   │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ ImageUpdateAutomation│
│ Updates Git          │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Git Repository       │
│ Receives Commit      │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Flux Reconciliation  │
│ Deploys New Version  │
└──────────────────────┘

Prerequisites

Before implementing this solution, ensure you have:

A Kubernetes cluster
FluxCD installed
GitOps repository containing Kubernetes manifests
Amazon ECR repository
GitHub repository
GitHub App configured for write access
AWS permissions configured for Flux

Required Flux controllers:

source-controller
helm-controller
image-reflector-controller
image-automation-controller

Verify Flux installation:

flux check

Expected output:

► checking prerequisites
✔ Kubernetes 1.29.0 >=1.28.0
✔ prerequisites checks passed

► checking controllers
✔ source-controller
✔ helm-controller
✔ image-reflector-controller
✔ image-automation-controller

Step 1: Create a Write-Capable Git Repository

Unlike a standard Flux GitRepository resource, Image Automation requires write access because Flux must commit updated image tags back to Git.

Create a dedicated repository source:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: flux-system-write
  namespace: flux-system
spec:
  interval: 1m
  provider: github

  ref:
    branch: dev

  secretRef:
    name: flux-system-write

  url: https://github.com/<organization>/<repository>.git

What This Resource Does

This repository allows Flux to:

Clone the repository
Modify files
Create commits
Push updates

Without write access, Image Automation cannot function.

Step 2: Configure GitHub App Authentication

Flux recommends using GitHub Apps instead of Personal Access Tokens (PATs).

Create the authentication secret:

flux create secret githubapp flux-system-write \
  --app-id=<app-id> \
  --app-installation-owner=<organization> \
  --app-private-key=<path-to-private-key.pem>

The GitHub App should have:

Repository Permissions

Contents: Read & Write
Metadata: Read

Benefits of GitHub Apps:

More secure than PATs
Easier rotation
Granular permissions
Better auditing

Step 3: Configure an Image Repository

The ImageRepository resource tells Flux where images are stored.

Example using Amazon ECR:

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageRepository
metadata:
  name: testservice
  namespace: flux-system
spec:
  image: <account-id>.dkr.ecr.us-east-1.amazonaws.com/testservice
  interval: 5m
  provider: aws

What Happens Behind the Scenes?

Every five minutes Flux:

Authenticates to AWS
Queries the ECR repository
Retrieves available tags
Stores the results internally

Check the repository status:

flux get image repository

Example:

NAME          LAST SCAN              READY
testservice   2025-05-23T14:20:00Z  True

Step 4: Create an Image Policy

An Image Policy determines which image Flux should deploy.

Example:

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImagePolicy
metadata:
  name: testservice
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: testservice

  filterTags:
    pattern: "^branch-dev-(?P<ts>[0-9]+)-[0-9a-f]+$"
    extract: "$ts"

  policy:
    numerical:
      order: asc

Understanding the Tag Strategy

Suppose ECR contains:

branch-dev-1715555000-a12b34c
branch-dev-1715556000-b45d67e
branch-dev-1715557000-f12a34b

The regex:

^branch-dev-(?P<ts>[0-9]+)-[0-9a-f]+$

breaks down as:

Component	Meaning
`branch-dev`	Environment identifier
`(?P<ts>[0-9]+)`	Captures timestamp
`[0-9a-f]+`	Commit SHA
`$`	End of tag

For:

branch-dev-1715557000-f12a34b

Flux extracts:

1715557000

and uses it for comparison.

Why Use Numerical Policies?

Numerical policies are ideal when image tags contain:

Build numbers
Unix timestamps
Sequential releases

This allows Flux to determine the newest image without relying on semantic versioning.

Step 5: Configure Image Update Automation

Now we tell Flux how to update Git.

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
  name: dev
  namespace: flux-system
spec:
  interval: 5m

  sourceRef:
    kind: GitRepository
    name: flux-system-write

  git:
    checkout:
      ref:
        branch: dev

    commit:
      author:
        name: FluxBot
        email: flux@example.com

      messageTemplate: |
        Automated image update

        Automation name: {{ .AutomationObject }}

        Files:
        {{ range $filename, $_ := .Changed.FileChanges -}}
        - {{ $filename }}
        {{ end -}}

    push:
      branch: image-update-dev

  update:
    path: ./apps/dev

How Image Update Automation Works

Every five minutes:

Clone repository
Scan manifests under ./apps/dev
Locate image policy markers
Update image tags
Commit changes
Push changes to GitHub

This completely removes the need for manual image version updates.

Step 6: Configure HelmRelease for Automation

Flux requires a marker showing where image updates should occur.

Example:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: core

spec:
  values:

    testservice:
      image:
        tag: branch-dev # {"$imagepolicy": "flux-system:testservice:tag"}

The comment is critical:

# {"$imagepolicy": "flux-system:testservice:tag"}

This tells Flux:

"Update this value whenever the ImagePolicy selects a newer tag."

What Happens During an Update?

Current manifest:

tag: branch-dev-1715555000-a12b34c

New image pushed:

branch-dev-1715557000-f12a34b

Flux updates the file automatically:

tag: branch-dev-1715557000-f12a34b

and commits the change.

Real-World Deployment Example

Let's walk through a deployment.

Step 1

Developer merges code into the development branch.

Step 2

CI/CD builds:

branch-dev-1715557000-f12a34b

Step 3

Image is pushed to ECR.

Step 4

ImageRepository detects the new tag.

Step 5

ImagePolicy determines it is the newest valid image.

Step 6

ImageUpdateAutomation updates Git.

Step 7

Flux detects the Git commit.

Step 8

HelmRelease deploys the updated image.

The application is now running the latest version without any engineer modifying a deployment manifest.

Multi-Environment Strategy

One of the biggest advantages of Flux Image Automation is environment separation.

Example:

Development
branch-dev-*

Staging
branch-staging-*

Production
release-*

You can create separate:

ImageRepositories
ImagePolicies
ImageUpdateAutomations

for each environment.

This allows:

Developers to deploy rapidly in Development
QA teams to validate releases in Staging
Production deployments to remain tightly controlled

Monitoring and Troubleshooting

View Image Repositories

flux get image repository

View Image Policies

flux get image policy

Example:

NAME          LATEST IMAGE
testservice   branch-dev-1715557000-f12a34b

View Image Automations

flux get image update

Force a Repository Scan

flux reconcile image repository testservice

Force Image Automation

flux reconcile image update core-us-dev

Check Automation Logs

kubectl logs \
-n flux-system \
deployment/image-automation-controller

Benefits of Flux Image Automation

GitOps Compliant

All deployment changes remain in Git.

Fully Auditable

Every image promotion becomes a commit.

Reduced Operational Overhead

No more manual image tag updates.

Faster Deployments

New images reach Kubernetes automatically.

Environment Control

Different environments can follow different promotion strategies.

Conclusion

FluxCD Image Automation provides a powerful GitOps-native approach to continuous deployment. By combining Amazon ECR, GitHub Apps, ImageRepository, ImagePolicy, ImageUpdateAutomation, and HelmRelease resources, teams can automatically promote container images while keeping Git as the single source of truth.

The result is a deployment workflow that is:

Automated
Auditable
Scalable
Secure
GitOps compliant

For organizations running multiple Kubernetes environments, this pattern significantly reduces operational effort while improving deployment consistency and reliability.

DevOps vs SRE vs Platform Engineering: What’s the Difference?

Folashade Oluwaseun Oroge — Mon, 26 Jan 2026 08:15:27 +0000

In this guide, I will walk you through the distinctions among DevOps, Site Reliability Engineering (SRE), and Platform Engineering.

As the software systems to be worked on get bigger, the teams will have to deliver faster and still be able to maintain the system's stability. Each of the DevOps, SRE, and Platform Engineering will have its unique way of solving this issue.

DevOps

DevOps can be considered as a culture and a collection of methods that are directed to improving the compatibility between the development and operations teams.
It puts a major emphasis on automation, continuous integration and continuous delivery pipelines, infrastructure as code, and monitoring as it helps the teams to ship software faster and more reliably.
👉 DevOps is all about speed and teamwork.

Site Reliability Engineering (SRE)

SRE entails the application of software engineering principles to operations with a strong focus on reliability.
SRE, through activities such as monitoring, incident management, SLIs, SLOs, and error budgets to keep the systems stable, allowing the teams to work fast.
👉 SRE is concerned with reliability and system stability.

Platform Engineering

Platform Engineering is about the creation of internal platforms that make the developer's job of building, deploying, and operating software easier.
Continuous self-service tools and the provision of standardized infrastructure by the platform teams lead to the reduction of complexity and the simultaneous improvement of developer experience at scale.
👉 Platform Engineering mainly targets developer experience and scalability.

Differences at the Core

The main difference between the three approaches is that each one of them has its own priority.

DevOps is concerned with the removal of barriers and speeding up the delivery process through cooperation and automation.
SRE does the opposite by securing production through the specification and enforcement of reliability targets.
Platform Engineering goes the long road of building reusable platforms that give the teams the onward march of speed without the headache of infrastructure management.

To put it simply:

DevOps is the one that inquires, “How can we give out the product faster?”
SRE is the one that inquires, “What is the level of reliability of the system?”
Platform Engineering is the one that inquires, “How friendly is this for developers?”

Conclusion

DevOps provides the benefit of speed.
SRE maintains the drawback of being able to produce only stable versions.
Platform Engineering overlays both processes with the proper infrastructure.

They are the best when they are collaborating and not when they are working separately. The real benefit comes from understanding when and how to use each approach as your systems and teams grow.

How I Deployed WordPress on an Azure VM with Nginx and PHP – With a Custom Welcome Page

Folashade Oluwaseun Oroge — Sat, 17 May 2025 01:21:09 +0000

In this guide, I’ll walk you through how I set up WordPress on an Ubuntu server on Azure using Nginx and added a custom welcome page to make the site more personal.

Architectural Diagram

Below are the steps I Took:

1. Installed Nginx, PHP, and MySQL

I installed the core components needed to serve WordPress:

sudo apt update
sudo apt install nginx php php-mysql mysql-server -y

2. Downloaded and Set Up WordPress

I downloaded WordPress and extracted it into /var/www/html:

wget https://wordpress.org/latest.tar.gz
tar -xvzf latest.tar.gz
sudo mv wordpress/* /var/www/html/

3. Configured Nginx

I edited the Nginx default configuration to support PHP and WordPress:

sudo nano /etc/nginx/sites-available/default

I made sure to set the index directive like this:

index index.html index.htm index.php;

This ensures my custom index.html is shown before WordPress’s index.php

4. Created a Custom Welcome Page

Inside /var/www/html/, I created an index.html file:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Welcome</title>
</head>
<body style="text-align: center; font-family: sans-serif; padding: 50px;">
    <h1>Welcome to Folashade's Core Dev Test!</h1>
    <p>This is a personal test environment where WordPress is installed.</p>
    <a href="/wp-login.php" style="display: inline-block; padding: 10px 20px; background: #0073aa; color: white; text-decoration: none; border-radius: 5px;">Login to WordPress</a>
</body>
</html>

5. Restarted Nginx

To apply the changes:

sudo systemctl restart nginx

Then I go to http://<server-ip> , I see a clean, welcoming landing page.

Clicking the link takes me to the full WordPress setup.

This setup gives me a simple branded homepage while keeping full access to WordPress in the background.

From FastAPI to Render: Building a Number Classification API with Docker.

Folashade Oluwaseun Oroge — Sat, 08 Feb 2025 00:04:32 +0000

In this article, I'll show you how to build a Number Classification API using FastAPI, Docker, and Render. The API classifies numbers based on mathematical properties (prime, perfect, Armstrong, odd/even) and fetches fun facts from the Numbers API.

GIF by Augustus

Tools Used

FastAPI – for building the API.
Docker – for containerization.
Render – for deployment.

Step 1: Setting Up the Project

Clone the project and install dependencies:

git clone https://github.com/Fola-Git/number-classification-api.git
cd number-classification-api
pip install -r requirements.txt

Step 2: Building the API with FastApi

Create the API Endpoint

The core of our API is a single route /api/classify-number?number=<num> that checks whether a number is prime, perfect, Armstrong, or odd/even. Additionally, it fetches a fun fact about the number from the Numbers API.

Here’s the core logic in app.py:

from fastapi import FastAPI
import requests

app = FastAPI()

@app.get("/classify-number")
def classify_number(number: int):
    result = {"number": number, "classification": classify(number)}
    result['fact'] = fetch_number_fact(number)
    return result

def classify(number):
    """Determine if a number is prime, perfect, Armstrong, and odd/even."""
    return {
        "is_prime": is_prime(number),
        "is_perfect": is_perfect(number),
        "is_armstrong": is_armstrong(number),
        "is_even": number % 2 == 0
    }

def fetch_number_fact(number):
    response = requests.get(f"http://numbersapi.com/{number}")
    return response.text if response.status_code == 200 else "No fact found."

# Helper functions (is_prime, is_perfect, is_armstrong) defined in the repo

Step 3: Dockerizing the Application

Creating a Dockerfile

We will containerize the application to ensure it runs in a consistent environment.

FROM python:3.10

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

EXPOSE 8000

CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

🔄 Creating `docker-compose.yml`

To manage the container easily, we use Docker Compose:

version: '3'
services:
  web:
    build: .
    ports:
      - "8000:8000"

To build and run the container, use:

docker-compose up --build

🚀 Step 4: Deploying with Render

📌 Push Your Code to GitHub

Run the following commands to commit and push your project:

git add .
git commit -m "Initial commit"
git push origin main

🚀 Deploy on Render

Sign in to Render.
Create a New Web Service.
Connect your GitHub repository.
Select FastAPI as the framework.
Set the start command:

  uvicorn app:app --host 0.0.0.0 --port 8000

Click Deploy and Your API will be live!.

🎯 Conclusion

In this guide, we built a FastAPI Number Classification API, containerized it with Docker, and deployed it on Render.

Feel free to explore and enhance the project with additional features. Check out my repository for the full structure: Fola-Git.

You can also modify online templates to improve the design and functionality. Happy coding!

How I Configured NGINX to Serve My Custom HTML Page: A First-Timer's Guide

Folashade Oluwaseun Oroge — Fri, 31 Jan 2025 14:02:31 +0000

Configuring NGINX to serve applications is a fundamental skill for anyone starting their DevOps journey. Whether you're setting up a web server for a personal project or diving into Cloud Infrastructure, it's a rewarding challenge. Recently, I decided to deploy a custom HTML page on an Ubuntu VM in Azure using NGINX. To keep things smooth and effortless, I tweaked a template online to give my site a personalized touch. In this article, I’ll take you through my setup process, the obstacles I encountered, and the valuable lessons I learned along the way.

My first step was to search online for free templates, and I came across FreeCSS. After browsing through the options, I found one that I liked—Browny. You can check it out too!

I then modified the code to suit my taste, updating the content and styling to match my vision. It was a fun way to personalize the site without starting from scratch! 🚀

Next, I created a new Ubuntu VM on Azure, but feel free to choose any cloud platform you prefer. During the setup, I customized the settings to suit my needs and ensured that port 80 was enabled to allow web traffic, as this was a test environment and not for production. For a production setup, I would recommend implementing additional security measures.

Once the VM was up and running, I ssh to it using MobaXterm to access the terminal. You can also use SSH or any other terminal tool of your choice.

Installing NGINX on Ubuntu

With the VM up and running, I first ran an update on it before installing NGINX, a powerful and lightweight web server that can handle traffic loads efficiently. Here's how you do it:

sudo apt update             # Updates the package list to ensure you're installing the latest versions of Ubuntu
sudo apt install nginx -y   # Installs NGINX and automatically confirms the installation without further prompts
sudo systemctl status nginx #To confirm if NGINX is running

You should see a result like below:

File Structure Overview

Below is the file structure of the application I used to better understand how everything fits together:

/var/www/html/Folashade_HNG0/
│── index.html
│── assets/
│   ├── css/
│   ├── js/
│   ├── images/
│   ├── fonts/
│   ├── download/
│   ├── logo/

Next, I navigated to the directory where my application files are stored using the following command:

cd /var/www/html/Folashade_HNG0  # Moves to this directory
sudo nano index.html             # Where to place your `index.html` code

To save the changes, I pressed Ctrl + O (to write the changes), then Enter to confirm. Finally, I exited by pressing Ctrl + X.

Configuring NGINX to Serve My Custom Page

With the HTML files and other necessary assets placed in the appropriate folder, it was time to configure NGINX to serve the custom page.

I navigated to the NGINX directory:

cd /etc/nginx
sudo nano sites-enabled/default  # where to modify the defauly NGINX configuration

I edited the default NGINX configuration file located at /etc/nginx/sites-available/default to point to the directory where I uploaded my files.

Here’s how I updated the configuration:

server {
    listen 80;
    server_name <your-server-ip>;

    # Root directory for your site
    root /var/www/html/Folashade_HNG0;

    # Default index file
    index index.html;

    # Serve the main site content
    location / {
        try_files $uri $uri/ =404;
    }

    # Serve static assets (CSS, JS, images, fonts, logos)
    location /assets/ {
        root /var/www/html/Folashade_HNG0;
    }
}

After saving the changes, I ran the following commands:

sudo nginx -t                 # Check if configuration is successful or give error if any issues found
sudo systemctl restart nginx  # Restart NGINX

At this point, my custom page was live! By visiting the VM’s IP address, I could see the page I had set up.

Challenges Faced

At first, I couldn’t access my HTML files because the NGINX configuration pointed to the wrong directory. NGINX couldn’t find the files, leading to errors when trying to load the page. Once I identified the issue, I updated the NGINX config to correctly point to the folder where my HTML files were located. After making this change, everything worked as expected, and my custom page was live!
Writing this article was a bit tricky, I had to explain technical details in a way that would be easy for beginners to understand, while still covering all the important steps. However, it helped me better understand troubleshooting and thinking critically about each step.
As the demand for cloud computing and automation grows, skills like these are becoming essential for professionals looking to work in roles such as DevOps Engineers and Cloud Engineers.

Completing this project was an excellent learning experience. It helped me get hands-on experience with server configuration and troubleshooting, which are key skills in web hosting and DevOps.

I hope this guide helps you on your path to mastering web server setup, and I encourage you to explore further as you expand your knowledge in Cloud and DevOps technologies.

DEV Community: Folashade Oluwaseun Oroge

Automating Kubernetes Image Updates with FluxCD, Amazon ECR, and GitHub

Introduction

The Problem We're Solving

Solution Architecture

Prerequisites

Step 1: Create a Write-Capable Git Repository

What This Resource Does

Step 2: Configure GitHub App Authentication

Step 3: Configure an Image Repository

What Happens Behind the Scenes?

Step 4: Create an Image Policy

Understanding the Tag Strategy

Why Use Numerical Policies?

Step 5: Configure Image Update Automation

How Image Update Automation Works

Step 6: Configure HelmRelease for Automation

What Happens During an Update?

Real-World Deployment Example

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Multi-Environment Strategy

Monitoring and Troubleshooting

View Image Repositories

View Image Policies

View Image Automations

Force a Repository Scan

Force Image Automation

Check Automation Logs

Benefits of Flux Image Automation

GitOps Compliant

Fully Auditable

Reduced Operational Overhead

Faster Deployments

Environment Control

Conclusion

DevOps vs SRE vs Platform Engineering: What’s the Difference?

DevOps

Site Reliability Engineering (SRE)

Platform Engineering

Differences at the Core

Conclusion

How I Deployed WordPress on an Azure VM with Nginx and PHP – With a Custom Welcome Page

Architectural Diagram

Below are the steps I Took:

1. Installed Nginx, PHP, and MySQL

2. Downloaded and Set Up WordPress

3. Configured Nginx

4. Created a Custom Welcome Page

5. Restarted Nginx

From FastAPI to Render: Building a Number Classification API with Docker.

Tools Used

Step 1: Setting Up the Project

Step 2: Building the API with FastApi

Create the API Endpoint

Step 3: Dockerizing the Application

Creating a Dockerfile

🔄 Creating docker-compose.yml

🚀 Step 4: Deploying with Render

🚀 Deploy on Render

🎯 Conclusion

How I Configured NGINX to Serve My Custom HTML Page: A First-Timer's Guide

Installing NGINX on Ubuntu

File Structure Overview

Configuring NGINX to Serve My Custom Page

Challenges Faced

🔄 Creating `docker-compose.yml`